[cap-talk] Capabilities as Rights

Jonathan S. Shapiro shap at eros-os.org
Thu Mar 24 14:05:35 EST 2005


On Wed, 2005-03-23 at 13:03 -0800, Karp, Alan H wrote:
> If the clist is held by the TCB, and Alice asks the TCB to put an entry
> in Bob's clist, and the TCB says "No" based on some policy, then should
> we call this a capability system?

It depends.

First, a system that uses capabilities for protection and simply does
not provide any "insert entry" operation is still a capability system.
The decision not to support such an operation might very well be a
policy decision, but it is implemented statically.

Second, suppose the nature of the refusal was that the system did not
implement c-list capabilities, but instead implemented capabilities to
processes wherein each process contained a c-list. The fact that you
would need to wield a process capability to perform the operation does
not imply that the system is broken -- it is merely a question of which
resources are nameable.

Finally, the case I think you intended to address: there *was* a
"capability to c-list" and there *was* an "insert cap in c-list"
operation implemented by that capability, but the system nonetheless
refused for some reason having to do with an exogenously imposed policy.

I think all of us would say at first that this is not a "pure"
capability system, but the reason is not the presence of an exogenous
policy module.

The real reason is that the exogenous policy module made its decision
based on information that was not present in the invoked capability --
typically the decision would be based on some sort of authentication
context of the invoked process.

We now need to ask a very tricky question: why was the authentication
state in the process rather than in the capability?

If the answer is: (a) the protected payload provisions of the capability
format were too limiting, we needed more bits, and so we took them from
the process state, combined with (b) we were envisioning a system in
which every capability's protected payload would encode the identity of
the wielding process (e.g. by using a reference monitor on all cap
transfers), then I think we could argue that this is still a special
purpose capability system. It is not general purpose, but there is a
capability-based structure that has been specially optimized in the
implementation to deal with an awkward situation.

But I would not call it a general-purpose capability system anymore.


Here is another interesting refinement: suppose we said that for every
invocation, the recipient gets protected payload from both the
capability and the sending process, but the sending process can cause
the from-the-process payload to be replaced by a well-known "anonymous
sender" bit pattern that is not otherwise used. Would *that* be a
capability system?

It is certainly possible in such a system to program using pure
capability idioms. I think that the system is impure, but I also think
that there may be pragmatically well-motivated usage idioms for such a
design. We will be experimenting with the implications of this in
Coyotos.

shap



More information about the cap-talk mailing list