Default database / namespace

[Bill Frantz]

Let me start by describing the KeyKOS directory structure.  As Jonathan
notes, the directory objects associated a names with capabilities.  It did
not give users access to capabilities they didn't already have, it merely
allowed them to use a human comprehensible string, rather than a number, to
name them.  It should also be noted that this directory structure was not
hierarchical, and directories did not have a .. entry.

Each user had a unique "home" directory.  By default, one of the entries in
that directory, pub/, was a key to the (shared, unmodifiable) directory of
publicly available factories.  

At 09:50 PM 7/3/00 -0400, Jonathan S. Shapiro wrote:
>2. A single global namespace is an unmitigated disaster and should be
>avoided at all costs, because it is an unclosable security hole for reasons
>discussed in the previous messages on this topic.
>
>I should acknowledge that Paul Karger does not agree with me about (2). He
>argues, and I think his argument needs to be understood and carefully
>examined, that a unified namespace is essential to providing (human)
>auditability so that one can determine what has been done in a system and
>also so that one can find all nameable references to a sensitive object.
>
>In a persistent system, I am not convinced that locating all nameable
>references has the same utility as in a non-persistent system, as there are
>likely to be references from persistent processes that are very long lived.
>This said, the issue of auditability is an important one. Paul's argument, I
>think, comes in the context of multilevel secure systems, but the audit
>issue is a general issue.

For general auditing, all you need is names, and the kernel's
representation of capabilities serve these purposes well.  There is one
other suggestion which needs access to the raw representation of the
capabilities, which is garbage collection.

Audit is somewhat less scary because it does not need access to the
capabilities as capabilities, it only needs the representations in a static
snap-shot of the system.  It can use the snap-shot to follow the capability
links.

In order to make the audit report comprehensible to a human, it needs to be
able to translate certain capability representations into strings, the
reverse of the directory object function.  Providing this reverse lookup
operation over a set of directory objects is certainly no more
objectionable than providing the representation of all the capabilities in
the system.  This set of directories would include the subjects, and the
objects being audited.

>In rejecting a global namespace, I want to be clear that I do not reject
>shared namespaces in general. If you and I wish to share a common directory,
>one of us can build the directory and ship a capability to it to the other
>*provided* that we are authorized to communicate. This is a fine design
>pattern.  However, there is absolutely no reason why your name for that
>directory and mine need to agree (though this raises a secondary design
>issue of "environment variables").

It also brings up issues of human communication.  In the KeyKOS world, we
developed the habit of having everyone use the same name for shared
directories.