[cap-talk] Where capabilities fall short - determining the invoker
norm at cap-lore.com
Wed May 25 13:52:26 EDT 2005
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
> 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
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
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
This does not damage code transformation techniques however because the
would be transformer is in league with the holder of the relevant
Abuse of the domain creator (such as allowing too powerful a vetting
service, or disseminating the vetting power to broadly) can ruin code
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.
More information about the cap-talk