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

[Harry Butterworth <harry@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

On Wed, 2006-07-26 at 16:04 -0700, Andrew Warfield wrote:
> I certainly didn't mean to imply that this had to be a part of
> xenstore itself.  But yes, I think we both agree.  In short, some
> policy enforcement foo could sit along-side xenstore and validate the
> way it is used to allow interdomain comms.  This foo could be largely
> be based on access control checks of access to xenstore (creating
> keys/directories, adding watches, etc.).  If this foo was actually the
> system-wide policy engine, it could use things that it sees happening
> in the store to admit lower-level operations.

I don't think I see it quite like that.  I think there should be a set
of low level primitives which are necessary and sufficient to implement
the generic resource access control and protocol policing functions and
the primitives that actually get used should be a function of the
protocol description which is in turn an attribute of the resource
class.  So essentially the security stuff falls out in the wash in the
implementation of the manipulations of the resource configuration rather
than being a bolt-on on the side that is watching what is going on
(having any kind of `watcher` necessarily involves duplication of effort
and bad coupling since both the doer and the watcher must contain
knowledge of the task at hand).

So I'm sort of turning xenstore inside out: currently xenstore is a
generic mechanism with content defined by the clients in the FE and BE
and I'd say that xenstore instead needs to define a fixed set of
primitives that support generic protocol description and access control
mechanisms.

This for example implies a standard set of high-level interdomain
communication mechanisms of which any particular protocol would use a
subset.  This is to be contrasted with the current implementation where
the FE and BE can define an arbitrary manipulation of xenstore to
establish a bespoke high-level interdomain communication mechanism.

I think we do agree about the high level picture though.

> Your points about resource colouring are interesting, but I think they
> may a few steps down the road.  Once two VMs are allowed to do shared
> memory communication it's a little moot as to what they are using it
> for -- disk/net/sweet nothings 

A resource colouring example would be something like having a group of
'red' resources including 'red' domains and a set of 'green' resources
including 'green' domains and perhaps a global policy to fail any
attempt to connect anything red to anything green even via a resource of
another colour.  This probably has some mapping onto an ACL concept.
I'm not really into this stuff.

> -- so the real benefit to AC in
> xenstore is in tool-independent per-resource admission control, and
> making sure that VMs follow established driver protocols.  (This
> facility would be generally useful as a means of shaking out split
> driver protocol bugs too by the way. ;) )

Designing the protocol independently of the implementation and having a
specification would also be an improvement over having to reverse
engineer it from the existing code only to find that it was broken ;)

> Getting back to Reiner's point about block AC checks in the backend
> drivers:  I think that if you trust the backend code sufficiently to
> _have_ the AC check in the first place, then you trust it implicitly
> to make correct use of page sharing etc.  So why not implement the
> tests for (a) permission to talk to the specified frontend, and (b)
> permission for that frontend to talk to the specified disk at the
> store level (which is where the two drivers are negotiating things
> anyway), and just use existing in-hypervisor AC mechanisms to control
> whether the backend is allowed to map the comms page and connect event
> channels.

I might be missing the point in the above paragraph.

I'm not sure that we have to trust the BE at all.  It's possible to
insert a trusted intermediate encrypt/decrypt/versioning/digital
signature layer so we don't have to trust the BE with resource isolation
or returning the right data and the FE can use mirroring for redundancy
against data lost by the BE.

So I think it's better for both a and b to be done by a trusted third
party which is smaller, easier to verify and subject to less frequent
change than a whole kernel.

Harry.


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