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

[Valerio Bellizzomi]

What is a membrane in this context?


On 05/12/2006, at 10.11, Jonathan S. Shapiro wrote:

>> 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
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk