[cap-talk] keyrings and bootstrapping capabilities

[Norman Hardy]

Thanks Jed for the additional background.

On 2007 May 28, at 12:25 AM, Jed Donnelley wrote:

> At 02:19 PM 5/25/2007, Norman Hardy wrote:
>
>> On 2007 May 24, at 8:53 AM, Peter Amstutz wrote:
>>
>>> As part of the system I'm designing that I discussed the previous

......


>>> b) A user sits down at a public terminal and wants to log in to a
>>> remote
>>> system and edit a file for which he knows a public identifier, but
>>> doesn't happen to have the 128 bit capability key granting write
>>> access
>>> on hand.  The user should be able to log in with a user name and
>>> password and then be able to go on to acquire the capability to  
>>> permit
>>> editing the file.
>>
>> I take it that write access to the file is somehow protected by an
>> RSA key.  This is not a capability paradigm but it has its uses.
>
> I don't understand the relevance of the above sentences/comment?

I assumed from Peter's comment that there was a file and that as  
policy it was necessary and sufficient to know a 128 bit secret to  
modify the file.
I then assumed that that policy was implemented by installing a  
password guard for the file and putting the key to that guard in a  
public place.

>

....

>> I assume that a RW capability to the file's guard is in a widely held
>> directory.
>> Presenting the secret key to the guard would do the trick.
>> The secret key need not travel to and from the public terminal.
>> Public terminals are, of course, still a problem!
>
> I don't understand the contribution of the above comment.
>
See previous comment.

>

........
> If, however, one is given access to a directory without
> the "free access" right, then all access rights that are
> turned off in the directory capability itself are turned
> off in the fetched capabilities before being returned
> in response to "fetch" requests.
>
Of what use is such a returned capability?
Perhaps rights amplification was necessary to use it.
Keykos did not use this pattern but the kernel could support it.

......


>
>>> Accomdating groups in this scheme is trivial, as a "group" simply
>>> becomes a keyring shared between multiple users.
>>
>> Yes!
>
> This is indeed how "groups" were created in most of the capability
> systems that I am familiar with.  As I've noted before on this
> list, in the Elephant storage system users could create
> directories out of whole cloth and then grant access to
> such directories to other users.  Such directories may
> or may not have the "free access" noted above.
>
> I believe a mechanism like Horton can provide a responsible
> identity for any capabilities, including any shared through
> such a person to person sharing mechanism.  With such a facility
> I could create a directory (e.g. for the purpose of "group"
> sharing).  I could take responsibility for my capability
> to that directory.  Using Horton I could share it with you
> in such a way that you then were given responsibility for
> the directory and anything fetched through it.

Indeed Horton is just such a membrane technology.


......

>> If you discover that he has had motivation, means and character to
>> subvert the system then killing his password access may not suffice.
>> To anticipate that unfortunate case it would be necessary to
>> initially put his shell in a membrane.
>> Then actions by his remaining agents subsequent to his removal are
>> blocked as well.
>> If he has contributed to mission critical function then you may well
>> be out of luck.
>> If he has written and delivered code that you depend on with moles in
>> it, you have problems whether or not the code was delivered within
>> the system or not.
>
> Horton is just such a membrane mechanism, specifically focused
> on an "identity" notion that can be associated with responsible
> people.  To achieve the goal of being able to associate logged
> actions to responsible parties and to be able to reactively
> block access (e.g. remove access by a person who has behaved
> inappropriately) I believe something like the Horton mechanism
> is needed.
>

Yes!

Concerning resource control with capabilities see:
http://cap-lore.com/CapTheory/KK/Meters.html  for control of CPU time
http://cap-lore.com/CapTheory/KK/Space.html  for control of storage
http://cap-lore.com/CapTheory/KK/BankNexus.html  for more space bank  
notes.