[cap-talk] On revocation and the use of wrappers

[Jonathan S. Shapiro]

> Jonathan has
> advocated that the access bits should not lie in the capability but in
> the object.

Jonathan's comment was restricted to OS-based capabilities, where a
capability cannot simply be a pointer to a method dictionary and (in
general) the signature of a capability's methods cannot be introspected.
Therefore, the comment that follows may not apply to, say, E, where the
interposition can be done with code. The issue in an OS is that
interposing with code is prohibitively expensive.

In context of operating systems, we have two problems: (1) the
capability representation must have fixed size, and (2) there is no
sufficiently universal set of object-level operations or classes of
operations that naturally justifies reserving bits in the capability
representation, and (3) there isn't really room for a distinct,
server-interpreted bitmask. For these reasons, EROS and Coyotos do not
try to store application-defined permissions in the capability
explicitly.

Given this, there are two places where object-specific permission bits
might be stored:

  (1) In bits of the protected payload reserved for this purpose. The 
      protected payload is part of the capability representation.
  (2) In a per-object data structure maintained by the server that is
      (in effect) indexed by the protected payload.

The problem you are noting is that the server has no visibility into
wrapping, and so requests to upgrade/downgrade authority can escape the
wrapper.

This is a deeply hard problem, and one for which I don't know a good
general solution. The heart of it is that the permissions negotiation is
in some sense a meta-object protocol, and a passive wrapper can't
interpose the protocol appropriately.

In practice, however, the problem doesn't seem to work out in the way
you describe, because the case of "object capability points to server"
is almost never observed in the wild. The problem with this design
pattern is that it prevents the server from performing selective
revocation of objects. The practical consequence is that servers tend to
issue wrapper capabilities that encapsulate server capabilities rather
than the server capabilities themselves.

Because of this, the wrapping protocol doesn't tend to work in quite the
way that you describe. What tends to happen is that the granting client
goes to the server and says: "please fabricate a new wrapper for this
object", and then hands the new wrapper to the client. This, of course,
involves storage allocation, but it is the server who populates the
wrapper.

While the original provider can shoot the bank, this doesn't guarantee
revocation, because the client can make a new wrapper for itself using
its own storage and discard the original; the server cannot tell.

So the key question is: what does this new wrapper point to? That is:
there is some state within the server denoted by this wrapper, and how
does this state relate to the "original" object state.

The reason I put it this way is that we are about to fall into one of
two options:

  1. The hierarchical capability trap. That is: we declare that every
     newly fabricated object alias is descended from something, and
     is whacked when its parent is whacked.

  2. The ACL trap, in which we re-invent ACLs as a means to justify
     reparenting operations in the server-side alias hierarchy.

The underlying issue is one of conflicting objectives: we don't want the
receiver to be able to escape our ability to whack the object, but if
the receiver B passes an externally authenticatable capability to a
process C who already has independent rights to it (and can prove that),
we may want C to be able to retain its copy of the capability
independent of the delivery path.

In any of these cases, I still claim that the revocation pattern is
rare. My argument is that well-structured applications have failure
domains that are smaller than their revocation domains. In consequence,
membranes do not need to exist at every process boundary.

This is all a rather bad puzzle, and it's a terribly important idiom to
get right!

shap

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100