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

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 01/12/2012 05:33 AM, Joanna Rutkowska 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.html
>>
> 
> 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...?
> 
> joanna.
> 

Splitting xenstored into its own domain (rather than keeping it in dom0)
means that it does not need to be privileged, so a compromise of xenstore
does not automatically give you full access to all other domains on the
system.

While it is possible to attack domains by sending them bad commands from
xenstore (device unplug/domain changes), it is also possible for a guest
VM to detect this and it becomes a denial-of-service instead of a way to
compromise the system. This is most easily done if guests use their own
full-disk encryption and run integrity checks on the unencrypted parts
(kernel/initrd; using a vTPM to unlock the guest-based FDE would work).

This split also prevents xenstored from being attacked from dom0, but this
is currently not as important security-wise since dom0 has superuser access
to the xenstore database. However, it does allow for future changes to
xenstore's security model that do not include a fully-privileged domain.

-- 
Daniel De Graaf
National Security Agency