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

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
From: "Mike D. Day" <ncmike@xxxxxxxxxx>
Date: Wed, 26 Jul 2006 13:46:02 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Bryan D Payne <bdpayne@xxxxxxxxxx>, Reiner Sailer <sailer@xxxxxxxxxx>
Delivery-date: Wed, 26 Jul 2006 10:46:32 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <d11c610112f6dc4ee355f7090e4615df@xxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <OFBCD03923.2A3751C2-ON852571B6.0000084B-852571B6.0001F1C1@xxxxxxxxxx> <2cc990ff2952dde0f8d12469f9417168@xxxxxxxxxxxx> <44C76D5E.2040606@xxxxxxxxxx> <d11c610112f6dc4ee355f7090e4615df@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Thunderbird 1.5.0.4 (Macintosh/20060530)
Keir Fraser wrote:

On 26 Jul 2006, at 14:25, Mike D. Day wrote:

The tools hook is not just a usability/conformity check. The check ensures that the tools will not set up entries in xenstore that would allow blkback to create a non-conformant vbd. So there is no way for a guest to trick blkback into creating a non-conformant vbd: it can only connect to vbds specified in its config file or added later via the vbd-add xm hotplug command. The tools stack should perform its compiance checks on both 'xm create' and 'xm vbd-add', and that should be sufficient.

Yes, but that relies on the tools being correct and invulnerable to attacks like buffer overflow. Further, it does not disallow an alternative tool from bypassing or corrupting the conformance and authorization policy. Any program with the ability to open a socket to xenstore can open the way. Allowing the checks within the hypervisor is much safer against these types of attacks or errors.

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.

Mike


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

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