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: Kurt Garloff <garloff@xxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/3] domUloader
From: Anthony Liguori <aliguori@xxxxxxxxxx>
Date: Tue, 17 Jan 2006 15:41:57 -0600
Cc: Xen development list <xen-devel@xxxxxxxxxxxxxxxxxxx>
Delivery-date: Tue, 17 Jan 2006 21:49:44 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <20060117143403.GB16322@xxxxxxxxxxxxxxxxxxxxxx>
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>
References: <20060116234330.GC17087@xxxxxxxxxxxxxxxxxxxxxx> <43CCDA6E.5040608@xxxxxxxxxx> <20060117143403.GB16322@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)
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