Re: [PATCH 0/3] domUloader

[Anthony Liguori <aliguori@us.ibm.com>]

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 :-)

Regards,

Anthony Liguori