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

[Reiner Sailer <sailer@xxxxxxxxxx>]

[For xense readers, please read the earlier mails
in this
 email-thread on xen-devel (Reiner)]

Keir Fraser <Keir.Fraser@xxxxxxxxxxxx> wrote
on 07/26/2006 09:49:46 AM:

> 
> 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?
> 
>   -- Keir

this is not necessarily about attackers.
It is simply that we anticipate many tools that manage the configuration/life-cycle
management of domains and it is very difficult for us to screen all these
developments to make sure that such tools do not introduce commands that
forget about the labeling/label checking accidentally. If they do, resource
access control can silently fail.

For example, the Xen hypervisor always
checks that a domain has a valid security label when it is started on an
ACM-enabled Xen or no label if it is started on Xen with ACM off. The hypervisor
layer can however not check resource labels but relies on the VMM resource
virtualization to do this (currently Domain0, in general the resource hosting
domain).

I understand Keir's current decision
(relying on resource label checks far in the user space of the resource
hosting domain) to be the result of a trade-off between (a) minimizing
the Xen linux-sparse tree (the burdens related to getting Xen support quickly
into Linux) and (b) the size of "the code required to do the right
thing"  to achieve policy compliant resource access control.

Thanks
Reiner
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel