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 18:46, Mike D. Day wrote:
> 
>>> 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.
> 
> Not sure I understand your answer, but if you have root on domain0 
> there's nothing to stop you circumventing xend entirely. The problem 
> here is that dom0 is in the TCB: solutions might be either to lock down 

Eventually we need to make authorization role-based instead of just the 
superuser and everyone else. In addition the hypervisor should not 
automatically trust dom0. Also, running domains should not automatically 
trust dom0. I realize that this is a lot of evolution from now 
(including changes to the dom0 hypercalls) but putting access control 
hooks into the hypervisor and its drivers is a small step in this 
direction. Not arguing for accepting the patch today, just suggesting we 
start to think about a different approach.

Mike

> domain0 (very restricted remote access) to reduce risk of privilege 
> escalation, or move the core control logic elsewhere (a mini-domain of 
> some sort) and reduce the privileges of domain0 (the biggest part of the 
> TCB). In the current situation with dom0: you show me a 'hack proof' set 
> of access-control checks and I'm sure I can describe a workaround for a 
> privileged attacker in dom0. For example, dom0 can map any other 
> domain's memory, so it's trivial for an attacker to steal secrets.