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.