This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


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

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

<Prev in Thread] Current Thread [Next in Thread>