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

["Andrew Warfield" <andrew.warfield@xxxxxxxxxxxx>]

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
hypervisor.

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
comprehensive.

a.

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.
>
> 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
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel