[cap-talk] Re: "capabilities" as data vs. as descriptors - public key capabilities

Jed Donnelley jed at nersc.gov
Mon May 3 19:47:51 EDT 2004


At 04:42 PM 5/3/2004, Jed Donnelley wrote:
>At 09:29 AM 5/1/2004, David Hopwood wrote:
>>David Hopwood wrote:
>>>Jed Donnelley (by way of Mark S. Miller <markm at caplet.com>) wrote:
>>>
>>>>The "capabilities as data" model that I generally have in mind when
>>>>in a discussion such as this is something like the "Control by Public
>>>>Key Encryption" mechanism described in:
>>>>
>>>>http://www.webstart.com/jed/papers/Managing-Domains/#s13
>>>>
>>>>I suggest taking a look at that section.  It is on-line and is only
>>>>a few paragraphs along with a diagram (if the notation becomes
>>>>confusing you may need to refer to the introduction where there
>>>>is a note on font restrictions).
>>>>
>>>>With that model the representation of a capability is unique to
>>>>the process that holds it.
>>>Then this is a descriptor capability system. The process-specific
>>>representation is effectively a descriptor.
>>>In the usual notion of a password (a.k.a. sparse) capability system,
>>>the "passwords" are not process-specific. There can be hybrids of
>>>password and descriptor systems, of course, but if "passwords" are
>>>process-specific, and can only be transferred between processes with
>>>the mediation of a TCB, then the resulting system is more like a
>>>descriptor-based cap system than a password-based one.
>>
>>For the "Control by Public Key Encryption" mechanism, I should have
>>added the caveat that this is only true, if the private key of each
>>process on a machine is only known by the TCB of that machine, and
>>not by the process itself. Otherwise, passwords *can* be transferred
>>between processes without mediation by any TCB.
>>--
>>David Hopwood <david.nospam.hopwood at blueyonder.co.uk>

For our implementation concerns, the private key needed to be kept
out of the processes memory space just so it wouldn't show up in
a dump and thereby potentially compromise the identity of the
process.  It's difficult for me to imagine why a process would want
to share it's private key (effectively it's identity), but in like thinking
as before I would argue that if a process chose to do so, that's
its choice (laissez faire computing).

--Jed http://www.nersc.gov/~jed/ 



More information about the cap-talk mailing list