[cap-talk] Namespaces, protection, and adminstration
Jonathan S. Shapiro
shap at eros-os.com
Fri Jul 27 01:17:29 EDT 2007
I would like to re-state the rsync problem as a starting point for a
discussion about namespace-derived controls.
What I wanted to achieve was the following:
1. httpd can publish anything under /srv/www, /home/*/public_html
2. rsyncd can publish anything under /srv/www
3. rsyncd can publish anything under /home/OPENCM, but only to a client
coming from www.eros-os.com.
Requirement  was actually pretty stupid. It came about because I
didn't want to stick a private key on www.eros-os.com. A better solution
would have been to use a "push" protocol and ssh. Now that I think about
it I will probably switch to that.
Rules (1,2) can be accomplished by building two namespaces, one for
httpd and the other for rsync. Each binds a common directory object at
the path /srv/www. In addition, the rsync namespace has a binding
So far so good.
But there is a nascent problem here. This approach, which looks very
simple when applied to two directories and two daemons, does not scale
well. Some issues:
1. For human management reasons, we will probably organize /srv/www
by subsystem. Some subsystems will have cgi scripts. We do not
want the cgi scripts to be published by either httpd or rsyncd.
Soon we will come to want a name-based filtering policy for this.
2. Eventually, after a history of many changes, we will come to forget
which directories and files have been bound in which name spaces,
and we will wish to answer the question:
"Which daemons have which permissions on this object?"
This is, in effect, the capability audit problem. It is a known
3. Later, we may install ftpd, and we may want to declare that some of
the content previously published by httpd and rsyncd should now be
published by ftpd. For external consumption, we want the respective
namespaces to correspond.
However, we may not want *all* of the content to be published in
this way. Which things to publish becomes context-sensitive. Humans
are very good at mapping names to contexts. From a usability
perspective, name-derived contexts is not without merit.
4. Many things that we might publish include references (in the form
of paths, relative or absolute) to other things. The more name
spaces we introduce, the more of these we will break.
Yes, we can embed capabilities. Paths are appropriate when we
intend the relationship to be indirect, and that remains a useful
idiom even in a capability system.
There are some people who have argued that multiple name spaces should
be avoided because humans cannot manage them. Namespaces are social
constructs, and need to serve human social requirements. The argument
goes that for the sake of audit and commonality of name interpretaoin
there should be a single, global, mutable namespace, but this namespace
should be subject to context-sensitive and path-based mandatory
controls. The namespace is mutable, but this does not mean that my word
processor can write an arbitrary location. Indeed, my word processor may
not have read access to any part of the namespace (except, perhaps, the
subtree containing the submodules of the word processor application).
Now this design is obviously not a capability-based design. I am not
excluding capability transfer via IPC. Rather, I am asking whether human
management of policy may not be well served by a human-sensible
namespaces and name-based restrictions.
Note that the mechanism sketched here has no "own" write. There is no
way for user A to grant access to user B in the absence of an (1) an IPC
path, or (2) authority to modify the global policy.
Note further that nothing here excludes private namespaces and/or
undisclosed data. Confined subsystems can still be constructed.
Accepting that I want to build on a capability substrate, I am left to
contemplate how humans should manage authority in the context of
Jonathan S. Shapiro, Ph.D.
The EROS Group, LLC
More information about the cap-talk