Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver

["Mike D. Day" <ncmike@xxxxxxxxxx>]

Keir Fraser wrote:
> On 26 Jul 2006, at 14:25, Mike D. Day wrote:
>
> > > The tools hook is not just a usability/conformity check. The check 
> > > ensures that the tools will not set up entries in xenstore that would 
> > > allow blkback to create a non-conformant vbd. So there is no way for 
> > > a guest to trick blkback into creating a non-conformant vbd: it can 
> > > only connect to vbds specified in its config file or added later via 
> > > the vbd-add xm hotplug command. The tools stack should perform its 
> > > compiance checks on both 'xm create' and 'xm vbd-add', and that 
> > > should be sufficient.
> > Yes, but that relies on the tools being correct and invulnerable to 
> > attacks like buffer overflow. Further, it does not disallow an 
> > alternative tool from bypassing or corrupting the conformance and 
> > authorization policy. Any program with the ability to open a socket to 
> > xenstore can open the way. Allowing the checks within the hypervisor 
> > is much safer against these types of attacks or errors.
> If an attacker has access to the control plane (essentially anything 
> with root privileges in domain0) what is to stop him from creating his 
> own domain, with security credentials allowing it to communicate with 
> domains A and B, and with its own proxy comms driver for circumventing 
> any Xen checks that are intended to prevent communication between A and B?
It's all about defense in depth. It shouldn't be possible for a 
privilege escalation on dom0 to automatically compromise all the running 
domains. There should be hypervisor-level access control that authorizes 
changes to the access policy of a running domU. With the ability to 
store domain configuration remotely (coming in xend) we can then prevent 
a privilege escalation and a restart from compromising user domains.
Mike


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