[cap-talk] Where capabilities fall short - determining the invoker

[Norman Hardy]

On May 24, 2005, at 9:36 PM, Toby Murray wrote:

> While I'm waiting for MarcS security cookbook to come back, I'd like 
> to put up a second example. If the material there can solve this then 
> cool.
>
> We have an object O. O maintains a list to other objects A, B etc. We 
> can add a capability to O using O.addCap(Capability obj); We would 
> like to have B be able to remove themself (and only themself) from the 
> list in O.
>
> I understand that we could use a reocable forwarder to B, (called fB) 
> and store fB in O. B can then remove the cap to itself that is inside 
> fB therefore, effectively removing themself from O.
>
> It would be nice(r) to allow the removeCap() method of O to be able to 
> reason about the source of the invocation. The fact that it doesn't 
> tie to any human identity or is only very short lived etc. doesn't 
> matter. Having O reason and say
> "for all caps in my list, do they refer to the same object that 
> inovked this method?" is fundamentally different and (possibly) more 
> expressive.
>
.....
The trouble with adding the ability to primitively identify the invoker 
means that another ability disappears.
It has to do with semantics preserving code transformations.
No longer can one move code into a subroutine based only on the 
semantics of the statements involved.
The Keykos experience was that new domains were invented much as 
subroutines were invented in more conventional systems.
It is difficult for code transformation techniques (whether done by 
humans or programs) to know whether moving an invocation into a new 
object is valid.
The ability to identify the invoker is a step towards loosing the power 
of subroutines, which is hardly different than loosing the power of 
sub-objects.

Keykos has a limited ability to identify callees since the resume key 
can be vetted by someone with access to the domain creator of the 
caller.
This does not damage code transformation techniques however because the 
would be transformer is in league with the holder of the relevant 
domain creator.
Abuse of the domain creator (such as allowing too powerful a vetting 
service, or disseminating the vetting power to broadly) can ruin code 
transformation rules.
But abuse of the domain creator can do that many other ways too.
You must use the domain creator correctly to make the objects it 
implements work right.