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 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.


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