[cap-talk] Namespaces, protection, and adminstration

[Jonathan S. Shapiro]

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 [3] 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
for /home/OPENCM.

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
     hard problem.

  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
multiuser systems.

Ideas?
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC