[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH 0/3] domUloader

Kurt Garloff wrote:

Hi Anthony,
I knew there was some security concerns voiced about this many months ago. I think one of the advantages to using libext2 was that it theoritically allowed the filesystem parsing to be done as a non-privileged user.

I can see your point.

There's two concerns you could have:

1. When the domU fs gets mounted in dom0, a local user there could
  get (read-only) access to data that he shouldn't have access to.
  This can be prevented by mounting under a directory that's not
readable to anyone but root. I didn't do this in my patch set, but it's certainly a good idea.
  (And dom0 root you need to trust anyway, such is the trust model
   in a hybrid virtualization model without encrypting everything.)

2. The filesystem in the domU could be prepared such that the kernel
  trips over a bug in its filesystem code.
  The same can happen if you read the FS with a userspace library
  of course, but the effects would be less bad -- at least if you
  would do it with non-root euid.
  The downside is that need to use a secondary source for filesystem
  code, which needs to be maintained and kept in sync, audited, ...
  And you are limited to the filesystems where you have userspace
  libraries for.
  In a paranoid scenario, you would not load any data from the domU
filesystem in any way :-) But I can see why you would choose pygrub over domUloader in a sensitive environment, where you
  can't trust the domU admins. Point taken.
  I still think that in many use scenarios, you would be perfectly
  fine with domUloader.
Did I catch your concerns?
Yup, just wanted to make sure it was considered :-)


Anthony Liguori

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.