[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cap-talk
Subject:    RE: Capability development principles (was Re: [cap-talk]YURLs.	What
From:       "Stiegler, Marc D" <marc.d.stiegler () hp ! com>
Date:       2005-11-29 22:39:46
Message-ID: BCD023E7727C0A4C93574C4D6C7FE3125B31A1 () cacexc12 ! americas ! cpqcorp ! net
[Download RAW message or body]


> >At the risk of sounding stupid, I've always kinda understood 
> that being 
> >able to 'transfer' a capability , itself is also a capability.
> 
> I don't see how the above can work.  Doesn't it set up an 
> instant infinite recursion?  That is, if C is a capability 
> and let's say that T is the capability to transfer C, then 
> there must be a capability to transfer T = TT, and so on.

To transfer a capability requires holding both the capability to be
transferred and the capability to the target destination to which you
wish to transfer that capability.

In a world of people, who are unconfined, the requirement to have the
destination capability has no security benefit, because people will who
want to share capabilities will have pre-existing channels. But the
requirement for the destination capability is very powerful when working
with confined application objects. You can (sometimes) grant objects
powerful authorities to work with, even if you wouldn't trust the author
of the object with that authority, because you can ensure that the
object cannot communicate the authority it has been given.

--marcs

_______________________________________________
cap-talk mailing list
cap-talk@mail.eros-os.org
http://www.eros-os.org/mailman/listinfo/cap-talk
[prev in list] [next in list] [prev in thread] [next in thread]