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

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

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


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