On Wed, 2006-07-26 at 11:50 -0700, Andrew Warfield wrote:
> 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.
Agree.
>
> 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.
Agree.
>
> 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 memory page to be used for block comms.
Mostly agree.
I think it ought to be possible to create a machine description of any
interdomain protocol including the guarantees provided by all the
parties. The combination of xenstore, xen and the parties involved can
then police that the protocol is observed.
The policing has to be designed such that it can't be subverted so xen
must provide the foundation but as little as possible. Xenstore
provides the trusted configuration information to xen to configure the
primitives (for example, xenstore holds the reference to the correct
machine description of the protocol). Then the front-end and back-end
try to use the protocol. If the FE or the BE detect a protocol
violation, the primitives are sufficient to be able to reliably
distinguish which party was in error so it can be forcibly reset.
We might want to be able to detect and reset in the case when one or
both parties are in error but neither complain too.
I think I spent about 2 mins on this with Ian about a year ago.
This is what you are saying above except that I'd want to do it without
embedding any protocol specific knowledge in the tools apart from a
protocol description file for each supported protocol.
So, in my version xenstore doesn't have any high-level semantic
understanding of the protocols, just a generic mechanism for handling
any protocol.
Also, I think that role based access control can be done on a general
concept of a "resource" available in xenstore and the different resource
classes can all reuse the same foundation.
This kind of thinking is another reason why there is a need for a small
library to sit between the hypervisor interdomain comms primitives and
the driver interdomain comms API. We want that library to do the driver
resident part of policing the interdomain protocols since we can't hope
that the driver authors are going to reimplement it correctly each time.
> Disagregating the store from the rest of dom0 is also an obvious step
> along this path.
Agree.
>
> 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.
Agree.
So basically, the xenstore++ is in a stripped down secured domain and
someone with role-based access privileges communicates with xenstore++
to connect a resource to a domain. Xenstore++ checks the permissions
and sets up the connection where the protocol description to use is an
attribute of the resource class. The protocol is policed and if it's
violated then either the resource provider (BE) or consumer (FE) or both
get blown away.
There can be generic mechanisms in xenstore++ for colouring resources
and grouping roles etc to do fancy MAC stuff.
...or something like that.
Harry.
>
> 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
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home