From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mike D. Day" Subject: Re: [PATCH][ACM] kernel enforcement of vbd policies via blkback driver Date: Wed, 26 Jul 2006 13:46:02 -0400 Message-ID: <44C7AA5A.3070700@us.ibm.com> References: <2cc990ff2952dde0f8d12469f9417168@cl.cam.ac.uk> <44C76D5E.2040606@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: xen-devel@lists.xensource.com, Bryan D Payne , Reiner Sailer List-Id: xen-devel@lists.xenproject.org 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