[cap-talk] Saving the Unix API

[Eric S. Raymond]

Alan Cox <alan@lxorguk.ukuu.org.uk>:
> > really effectively. The plan-9 fs showed that per-process namespaces were
> > feasible without breaking much. Ron Minnich is trying to partially recreate
> > that for Linux, and I think it would be interesting to shift the Linux basic
> > model more towards plan-9 on this point.
> 
> Linux 2.5 already supports per process namespaces. Al Viro is a plan 9 fan
> as well as the Linux VFS maintainer.

Shap and Mark Miller and I had a long conversation about this last
night.  I thought per-process namespaces could be used to save the
Unix API, by filtering each spawned process's view of the file store
in a capability-clean way.  Shap ran with the idea and developed it
better than I had, but Mark found a show-stopper at least in the way
we were considering it.  The flaw is that, in the design we were
considering, the spawned process's private namespace is created by the
parent and thus known to the parent.

I'm not yet ready to give up on this path -- it would be so damned
*useful* to be able to keep Unix.  Therefore I'm now thinking about an
architecture in which each spawned process's namespace is created by a
dedicated namespace manager at the request of the parent process.

The idea here is that the at process-spawn time, the parent process
would hand the namespace manager encapsulated capabilities describing
its view of the file store.  The namespace manager could see these
without being able to use them itself -- this could at least eliminate
the visibility-upwards problem.  The namespace manager's job would be to 
pass the child process an appropriate set of capabilities.

The remaining question is whether it is possible to specify the namespace
manager's protocol for generating the child's capability set in such a
way that it can be proved to have the right security properties -- all
my maneuver has done is isolate the problem, not solve it.

I am not yet equipped to solve this problem, because I don't yet grok
capability terms in fullness.  Reasoning in them is like assembling
sentences word-by word in a language I don't yet think in -- I can
recognize good grammar and often achieve formal correctness, but the
process is a strain, I have trouble retaining all the rules, and I'm
prone to elementary errors.  I'm not fluent, I'm still having trouble
moving between shap's OS view of the world and Mark's lambda-calculus
view.

But it's worth pursuing, because if we can solve this problem we can
subsume Unix rather than emulating or subverting it.  In practical
terms, this would mean evolving Linux into a persistent-capability OS.
The two difficulties, as I understand them, are:

1. Shared global filespace creates sneak paths outside the capability system.

2. Unix's privilege-inheritance rules are inadequate.

I understand problem #1 very well, I think (the EROS papers really opened
my eyes about this, thank you Shap), but I'm still working on
getting my head around problem #2.  I have intuitions about it I cannot
yet ground.

I think sheer bloody-minded persistence might get me there, though :-).
--
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>