[cap-talk] Non-Delegatable Authorities in Capability Systems

[Toby Murray]

Thanks for the comments, Kevin. Some responses inline.

On Sat, 2007-12-08 at 23:19 -0500, Kevin Reid wrote:
> 1. The NDA system in Figure 3 succeeds only if the protocol of the  
> target object is such that it does not reveal itself (or other  
> capabilities to be protected from delegation) in responses. 
> This would be avoidable by using what is to Figure 3 as a membrane is  
> to a caretaker.

Indeed.

> 
> 2. In section 1.4, you state:
> 
> > Importantly, in many object-capability systems the authority to  
> > reply is not delegatable. Examples include systems such as E [15],  
> > W7 [23] and the Annex Capability System [8] that never reify this  
> > authority, making it impossible to delegate. Another example is any  
> > capability-based IPC system that does not allow the receiver of a  
> > message to transfer the capability used to send back the reply. The  
> > EROS operating system is a counterexample, since it allows the  
> > receiver to transfer the resume capability that is used for sending  
> > back the reply [25].
> 
> 
> If I understand what an EROS resume capability is, then this is false  
> for E.

Right. I had presumed that for local method calls that the "return"
statement in E was implemented by popping the current stack frame, as in
other object languages. Apparently not.

I had presumed that for the distributed case, that the semantics would
be slightly different and so had been careful to try to avoid making
claims about this case. I wasn't aware of the "ejector" semantics (which
i'm still not clear on ;)

>  A resolver (eventual) or ejector (immediate) is precisely a  
> "capability used to send back the reply" -- and under CapTP,  
> pipelining means that the response resolver can be resolved to  
> (delegating to) a promise which lives in some other vat, and may  
> therefore outlast the confused delegator.

Could you unpack the above a little. Does everything after "under CapTP"
apply only to the distributed case or the local case as well?

Ignoring the distributed case for now,

>    # simple reification, immediate
>    to bar() {
>      leak(__return)
>    }
> 

by the above, does this mean that, when invoked, bar calls leak, passing
the capability that bar wouuld use to send back the reply to its
invoker? Hence, leak may return from the bar invocation, on bar's
behalf?

If so, then this would appear to break the semantics I had assumed.

> However, an important characteristic of resolvers (and resume  
> capabilities, IIUC) is that they are /use-once/: at most one response  
> can be delegated, and so (in the preceding scenario) that response  
> must be to a request made of Alice while she was confused (or she  
> would not have leaked that particular resolver).

Are ejectors (I'm presuming that __return in the above example is an
ajector and that "ejector" is (effectively) the capability used to
return from an invocation) also use-once?


> Therefore, while the claim as written is false (no-delegation-of-a- 
> reply), a more relevant property (no-delegation-of-future-replies)  
> exists in E (and possibly EROS as well).

Am I right in saying that the upshot here is that, in E,
no-delegation-of-a-reply is false (since ejectors can be delegated) but
reply caps are use-once?


> 
> Minor comment: I expect that the actual results in a "buggy  
> delegator" scenario depend on the exact mechanism used for upgrading  
> the buggy program (what level of the system is replaced); i.e. the  
> examples, containing no upgrade hooks, are unrealistic. Some upgrade  
> hooks might defeat the no-delegation-of-future-replies property.
> 
> Minor comment: What you call "method name" is properly called "verb"  
> in E. The distinction is that methods are part of the / 
> implementation/ of the object; verbs are parts of the messages it  
> understands, the interface.

Thanks for the tip. However, in order to avoid confusing readers that
are not familiar with E terminology, I feel that keeping method name is
appropriate for this particular paper.

> 
> Minor comment, section 2.3: If accountability, but not non- 
> delegation, is desired, then the Horton system serves that purpose  
> with less indirection, if I recall it correctly.

Indeed. But that paper was written well before Horton was invented.
>