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 14:24:06 -0400 Message-ID: <44C7B346.60801@us.ibm.com> References: <2cc990ff2952dde0f8d12469f9417168@cl.cam.ac.uk> <44C76D5E.2040606@us.ibm.com> <44C7AA5A.3070700@us.ibm.com> <72656fa47f41a0522b47af0ad9496741@cl.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <72656fa47f41a0522b47af0ad9496741@cl.cam.ac.uk> 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 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.