WARNING - OLD ARCHIVES

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/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

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

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