[cap-talk] MinorFS Philosophy

Rob Meijer capibara at xs4all.nl
Sat Jul 12 14:16:23 CDT 2008


On Sat, July 12, 2008 13:51, Toby Murray wrote:
> Hi Rob, and all cap-talkers who are interested here,
>
> I want to ask a question about the philosophy behind MinorFS. It appears
> to be unique amongst other POLA-related filesystem projects, such as
> Plash.
>
> The fundamental difference appears, to me at least, to be this:
>
>  - Programs run under MinorFS need to protect their secrets (and yours)
> from the rest of the system. Hence, there is inherently some trust being
> placed in a MinorFS'd program (like the ssh example you gave), while the
> rest of the system is potentially untrusted.
>
>  - In contrast, Plash is used to guard your secrets (and those of your
> trusted applications) from Plash'd programs, which are inherently
> untrusted.
>
> Hence, the two approaches appear to be almost mirror-images of the other
> with the trust relations inverted.

I agree they are mirror images at some levels, although I hadn't
considered that in terms of trust relations. The most important
differences are I feel in the delegation patterns used. In systems like
plash, the user is always at the start of the delegation chain, while with
MinorFs he is somewhere halfway in the chain.

> I'd like to get your thoughts, and those of others, on this
> characterisation of the two approaches.
>
> Taking this further, one can build a "capability metaphor" for a Plash'd
> program as follows: A program running under Plash runs in its own
> filesystem namespace. Each name within that namespace can be thought of
> a handle to a capability that the process can access by using the open()
> syscall. Then the propagation of capabilities between Plsah'd processes,
> follows (roughly) the rules of the object-capability model.
>
> I wonder whether one can do likewise for MinorFS. I haven't yet been
> able to do so, which makes me think that the philosphy behind MinorFS is
> unique indeed. However, because of this, I have trouble trying to figure
> out how I could make best use of MinorFS, as opposed to Plash which I
> can immediately see how it can help me to enforce POLA.

If I need to put it in terms of namespaces and capabilities, MinorFs
treats a directory treegraph as its own namespace, and each node in the
directory treegraph, both as a node in the treegraph, and as a new
namespace itself.
Any process in the system can access a directory or file if it has a
capability to the namespace bound to it or one of the parent nodes in the
full treegraph. The capabilities used are what I call 'strong paths', but
basically you can look at them as password capabilities if you like.

A high level node in the treegraph is given to MinorViewFs (that runs on
top of MinorCapFs). MinorViewFs creates sub nodes for each uid, that it
will delegate to each instance of the '2rulethemall' program running under
that uid by giving it the password capability.

The 2rulethemall program will re-delegate this capability to the user (or
any program) if she suplies it with the user memorable password that
2rulethemall holds for that purpose.

Under the uid nodes, MinorViewFs will also create nodes for programs, and
under that for instances of these programs (pseudo persistent processes).
MinorFs will delegate the capabilities to these nodes, one to each
individual pseudo persistent process its own node.

A pseudo persistent process can create its own directory treegraph under
the  node it got delegated from MinorViewFs. If the process wishes to do
so it can ask a subnode for its password capability (strong path), so it
can delegate this subgraph to any other process.
(The same as for pseudo persistent processes, MinorViewFs maintains and
delegates nodes for non persistent process bound storage.)


You should think of a path like:

/mnt/minorfs/cap/ea1fd1f0e245617f37b09124b699baf84700cc5e/foo/bar.txt

like:

<MOUNTPOINT>/<NAMESPACE-CAP>/foo/bar.txt

Where you could ask the foo directory for its namespace capability,
so that the same file might be accesible as:

<MOUNTPOINT>/<NAMESPACE-CAP2>/bar.txt
or
/mnt/minorfs/cap/a565904c59359d52ea869e565e1b37b2cdd4b6ff/bar.txt

and the file itself as:
<MOUNTPOINT>/<FILE-CAP2>
or
/mnt/minorfs/cap/cf4ccdc179de324d6f276fca132015100ed93c68


> Am I limited by trying to think of least authority solely within terms
> of the object-capability model, or is it that MinorFS is meant to solve
> a different problem altogether?

I hope the above gives some help with that. Think of MinorFs as a password
capability system with caps as data, in this case caps as strong paths.

One thing that MinorFs tries to facilitate that might be interesting from
your perspective, but that I hav not realy sufficiently emphasised is the
concept of pseudo persistent processes and some base level of persistent
delegation between those processes. The private storage for what
MinorViewFs considders pseudo persistent processes, should allow programs
a place to store (partial) self serializations in such a way that a new
incarnation of the process could truely be considdered the same process.

The private storage thus in concept becomes a disk based extention to the
encapsulation concept of object oriented programming.

As for difference in philosofy, I feel the main point would be that the
user also is subjected to least authority, not just the processes.
And just as with active objects, giving a user only the authority he needs
at the time he needs it to get his job done should IMO make his job much
more simple and thus more manageable.

So instead of having to manage the big global filesystem namespace,
smaller namespaces are managed by different processes that can delegate to
the user and each other and that the user can delegate to. The user thus
becomes just an other active object from a capability modeling point of
view.

Is this making sense, or have I somewhat lost track of my marbles here ?



More information about the cap-talk mailing list