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

To: "Mike D. Day" <ncmike@xxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH][ACM] kernel enforcement of vbd policies via blkback driver
From: "Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>
Date: Wed, 26 Jul 2006 11:50:10 -0700
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx, Reiner Sailer <sailer@xxxxxxxxxx>, Bryan D Payne <bdpayne@xxxxxxxxxx>
Delivery-date: Wed, 26 Jul 2006 11:50:34 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=rndkpXCh2zZaFJmzykMIk+ffZi/iH2RKq59YPENM2M25DwhFyJigo53uUkzX19ewrpAk4IvY7Vgs8SXRfsZa0SKzLZS6xDw4usIaHJ2QxxUeER+nFzjtK01Xgc6tQgTvKMpJJpuwy7Cx239n1Iv0WWsLaP/FKUwO+/ynDwu2srY=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <44C7B346.60801@xxxxxxxxxx>
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> <44C7AA5A.3070700@xxxxxxxxxx> <72656fa47f41a0522b47af0ad9496741@xxxxxxxxxxxx> <44C7B346.60801@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
I'm unconvinced that access control checks in the drivers are really a
good, or even a necessarily low-level solution.  From a security
perspective, I think that we should then of xenstore to be a
lower-level entity than drivers, which are effectively just
applications that use interdomain comms mechanisms offered by the

You're got in-hypervisor checks for primitives like grant tables and
event channels.  These on their own let you enforce very general
policy, e.g. "domain a isn't allowed to communicate with domain b".
The checks that you want to put into the block drivers aim to do a
more specific thing: specifically check that dom a and dom b are
allowed to communicate for block devices.  The problem is that (as
keir mentioned) failing an access control check here certainly doesn't
stop me from building an alternate comms driver that
does block and doesn't have the AC check.  The lack of hooks in
blocktap in the patch are an illustration of this.

I think that the correct way to tackle this one is to treat XenStore
as having a high-level-semantic understanding of inter-VM comms, and
that it is the place where a lot of this sort of fine-grained AC
should be driven.  A security policy for block devices integrated with
xenstore would be able to (a) aprove split block drivers for use in
the first place by allowing /vbd subdirectories to be created and
watches to be attached to them, (b) enforce that the block protocol
met a security-policy, potentially even validating messages to avoid
things like buffer overflow, and (c) drive lower-level access control,
for instance by triggering access clearance to the specific granted
shared emeory page to be used for block comms.

Disagregating the store from the rest of dom0 is also an obvious step
along this path.

The current in-hypervisor AC checks make sense as the hypervisor
interfaces are narrow.  Using the store as the next level of AC allows
us to still do things in a os- and tools- agnostic manner.  Hacking AC
checks piecemeal into drivers seems like a harder thing to make


On 7/26/06, Mike D. Day <ncmike@xxxxxxxxxx> wrote:
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.


> 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 mailing list

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