[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


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



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.