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

Re: [MirageOS-devel] Merging XenStore+MAC

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


as a virtual path:


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.


MirageOS-devel mailing list



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