From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 0/3] domUloader Date: Tue, 17 Jan 2006 15:41:57 -0600 Message-ID: <43CD64A5.8040301@us.ibm.com> References: <20060116234330.GC17087@tpkurt.wlan.garloff.de> <43CCDA6E.5040608@us.ibm.com> <20060117143403.GB16322@tpkurt.wlan.garloff.de> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20060117143403.GB16322@tpkurt.wlan.garloff.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Kurt Garloff Cc: Xen development list List-Id: xen-devel@lists.xenproject.org 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