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

[Kurt Garloff <garloff@xxxxxxx>]

Hi Anthony,

On Tue, Jan 17, 2006 at 05:52:14AM -0600, Anthony Liguori wrote:
> Just to clarify, this means that domU filesystems are being mounted in 
> dom0?

Correct.
 
> 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?
-- 
Kurt Garloff, Head Architect, Director SUSE Labs (act.), Novell Inc.

Attachment: pgpVIuhgBcjXL.pgp
Description: PGP signature

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel