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

[Reiner Sailer <sailer@xxxxxxxxxx>]

andrew.warfield@xxxxxxxxx wrote on 07/26/2006 02:50:10
PM:

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

The original patch does not cover blocktrap. This might as well illustrate
that there is another patch to be done (and that we are not done yet, also
consider netback). If the current patch doesn't get in because there is
no similar patch to blocktrap, then this can be fixed. I know about blocktrap
but I'd like first to know if working on the patch makes sense, i.e., if
it will be acceptable in general (leaving room for rejecting bad code of
course).

This was not the original argumentation and the effect
of not having blocktrap security support could be mitigated by compiling
the kernel with only blockback support until this support is established.
While Xen is in rapid development, it will now and then happen that new
critical sharing mechanisms are introduced; those will always need to be
examined and equipped with the appropriate security hook to consistently
enforce the security goals.

It is much easier to ensure that a "supported
" kernel is running (e.g., using authenticated or secure boot) in
a device domain than to establish these properties in domain0 user space
management code.

As Andrew mentions correctly, other security mechanisms
can be applied independently on top of the hypervisor security policy;
e.g., by a security policy inside Domain0 to 'lock it down' (layering security
is one principle of building secure systems). However, keeping policies
of different layers (fine-grained OS vs coarse grained VMM policies) separate
is one of our major goals.

Moving the resource hooks exclusively into domain0
will not help the disaggregation today and indeed might result in a movement
into the opposite direction: it ensures that the confinement capabilities
remain dependent on the whole management environment. Introducing enforcement
hooks in the kernel drivers (at least block[trap/back] and netback) reduces
dependencies on domain0, even if today other dependencies persist.

As Keir encouraged earlier: please don't hesitate
to join in if you have some viewpoint you'd like to discuss. This seems
broader than the simple patch discussion that started it. And please try
to keep 'xense-devel' in the cc because this topic is interesting to the
security list.

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