Re: [Xen-devel] [RFC PATCH 0/18] Xenstore stub domain

[Keir Fraser <keir@xxxxxxx>]

On 12/01/2012 10:33, "Joanna Rutkowska" <joanna@xxxxxxxxxxxxxxxxxxxxxx>
wrote:

> On 01/11/12 18:21, Daniel De Graaf wrote:
>> This patch series allows xenstored to run in a stub domian started by
>> dom0. It is based on a patch series posted by Alex Zeffertt in 2009 -
>> 
http://old-list-archives.xen.org/archives/html/xen-devel/2009-03/msg01488.htm>>
l
>> 
> 
> Daniel,
> 
> Can you explain what is the rationale for moving the xenstored into a
> stubdom? After all, if an attacker is able to compromise the xenstored,
> there should be many ways now how to compromise other VMs in the system?
> And it shouldn't matter whether the xenstored is in stubdom or whether
> in Dom0. E.g. the attacker might redirect the block fronts to us some
> false block backends, so that the VMs get compromised fs. One could
> probably think of other attacks as well...?

As you point out it's a critical component in itself, so I suppose this work
is mainly about isolating it from the big attack surfaces in dom0. It's of
questionable value unless dom0 itself can be deprivileged, or the big attack
surfaces themselves shuffled off into lesser-privileged domains. In a well
locked down dom0 I would say that the biggest attack surfaces are via things
like domain build, save/restore, and qemu, being intrinsic (ie unavoidable)
components of a Xen system which consume complex inputs. We can already do
qemu stubdoms, perhaps with some features missing still. Launching isolated,
de-privileged (eg can only act on the one specified domain),
domain-builder/saver/restorer stubdoms would be an interesting direction
imo. It's easy to be impressed with any disaggregation effort almost for its
own sake, and lose sight of the importance of basic security analysis as a
starting point.

 -- Keir

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



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