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

["Mike D. Day" <ncmike@us.ibm.com>]

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