[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.