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

[Kevin Reid]

On Dec 6, 2007, at 7:24, Toby Murray wrote:

> "Non-Delegatable Authorities in Capability Systems"
> By Toby Murray and Duncan Grove
> (to appear in the Journal of Computer Security)
>
> http://web.comlab.ox.ac.uk/oucl/work/toby.murray/papers/NDA.pdf

I would like to point out two non-fatal problems and some other minor  
issues:


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 is  
the same requirement as for use of a generic caretaker (as in  
org.erights.elib.facet.makeCaretaker).

This would be avoidable by using what is to Figure 3 as a membrane is  
to a caretaker.


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. 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.

   # simple reification, eventual
   to foo() {
     def [p, r] := Ref.promise()
     leak <- (r)
     p
   }

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

   # possibly-outlasting-myself delegation
   to baz() {
     return leak <- ()
   }

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).

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).


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.

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.

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>