This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

To: Anthony Liguori <aliguori@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] domUloader
From: Kurt Garloff <garloff@xxxxxxx>
Date: Tue, 17 Jan 2006 15:34:03 +0100
Cc: Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 Jan 2006 14:42:08 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <43CCDA6E.5040608@xxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Mail-followup-to: Kurt Garloff <garloff@xxxxxxx>, Anthony Liguori <aliguori@xxxxxxxxxx>, Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Organization: SUSE/Novell
References: <20060116234330.GC17087@xxxxxxxxxxxxxxxxxxxxxx> <43CCDA6E.5040608@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.9i
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?

> 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: pgpyxtJTqMcIi.pgp
Description: PGP signature

Xen-devel mailing list