Re: [MirageOS-devel] Merging XenStore+MAC

[James Bielman <jamesjb@xxxxxxxxxx>]

Hi Dave,

On 09/09/2014 08:07 AM, David Scott wrote:
> Hi James,
>
> Yes, that's the latest one. Note it's not in a fully working state-- 
> when integrating irmin I unhooked a bunch of stuff so that I could 
> refactor the core more quickly. The following features are 
> (temporarily) unhooked:
> - interdomain rings (unix domain socket still works)
> - ACLs
> - watches
> - Xen kernel build
>
> Now that the irmin core is working it's probably time to start 
> re-adding these.
> If you had complete freedom, what would your ideal interface be?
I'm doing a quick update of the security interface away from a 
"record-of-functions" approach to a proper OCaml module type (leading to 
another module parameter to Server.Make for the security module).  Once 
I have something that looks good I'll send a pull request and hopefully 
we can come up with an interface that works well on both sides.
My thinking is that I will backport this interface to our current code 
based on the older XenStore tree and we will continue to use that 
internally.  Having the interface available in the newer tree going 
forward should hopefully let us switch to the newer version when it is 
ready without too much pain.
>     - I've been unable to compile a standalone Xen kernel because
>     "mirage-xen" wants to install "xenstore" via OPAM, which conflicts
>     with "ocaml-xenstore-server".  Should that be working?  Do I need
>     to update to Mirage 2.x?
>
>
> Ideally I'd like to remove the dependency between mirage-xen and 
> xenstore-- it's currently needed by the suspend/resume code but it 
> complicates the build of the Xen xenstore kernel.
Indeed, this has been a problem for us too.

A similar issue we ran into is the assumption that a console is 
available in Mirage.  I have some patches floating around for a dummy 
console that I should get into shape for submitting (IMO ideally there'd 
be a way to fall back to the hypervisor console for domains like 
XenStore that may be started before the console is ready).
> For the moment I've been testing via the unix domain socket and had 
> been planning to recreate the kernel version later. Does this work for 
> you?
Yes, I think this is fine for getting the basic interface tested. I'm 
inclined to postpone adding all the calls to security hooks on each 
access check until the DAC checks are in place, though.
It'd be nice to come up with a framework for doing the DAC checks and 
calling the security module in a unified way.  Since the DAC checks are 
likely a subset of the checks we're doing for MAC, we may be able to 
implement DAC using the security module interface and come up with a way 
to compose them.
>     - I see some code that appears to support mounting virtual trees
>     of some sort (in server/mount.ml <http://mount.ml>), but it
>     doesn't seem to be used currently?  One feature I need to do this
>     integration is a virtual "/label" tree for reading/writing nodes
>     security labels.  What is the best way to implement a virtual
>     subtree like this currently?
>
>
> Ah yeah, that's been unhooked too. I need to hook it back in. Would 
> your tree be entirely virtual or would you want to write-through to 
> irmin beneath?
Hmm, I'm not actually sure yet on this one.  In the in-memory case, its 
simple because we know if MAC is enabled before we create any nodes, so 
everything is always labeled anew each time we start XenStore.  If there 
is a situation where we could persist the XenStore tree without MAC then 
reload it with MAC enabled then we'd probably need to implement 
relabelling.  Right now there's an assumption that the tree is created 
fresh each boot so it never has to be relabelled.
Our case is a little unusual in that we want to expose the security label of

  /local/domain/1/name

as a virtual path:

  /label/local/domain/1/name

So we'll definitely need access to the underlying node.  To be 
conservative, I think we'd probably want to assume we need to write 
security labels along with node values to the underlying storage, but 
I'll need to think through the relabelling issue.
Thanks!
James


_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel