[cap-talk] keyrings and bootstrapping capabilities

[Jed Donnelley]

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
> > thread, I've been mulling over the bootstrapping problem for a
> > capability system.  In particular, I see two challenges:
> >
> > a) Alice and Bob are looking at directory D.  Alice has read-only
> > access to the directory and all its contents.  Bob has read-only
> > access to the directory (cannot add or delete files), but
> > read-write access to certain specific files.  If Alice shares
> > her read-only reference to the directory with Bob, how does Bob
> > determine which files he can write to?
>
>I presume that the directory is a directory of capabilities, and by
>hypotheses here--capabilities to files.
>I further assume that Alice and Bob look by having different
>capabilities to D.
>In Keykos the directory has no concept of principal and Bob, using
>the capability D from Alice, can only read the files with the file
>capabilities he gets via D.

Most of the capability systems that I'm most familiar with also
work like Norm describes above.  I believe all object/capability
systems work like this:  If Alice and Bob share the same access
to a directory (e.g. "read-only" access as you say above), then
the access to the objects in the directory that they can get
access to from the directory are exactly the same.  For Alice
and Bob to get different access to objects in the directory
they must do it through other means.  For example, regarding:

> > 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?

>In Keykos when one logs in one is attached to his own persistent
>instance of a shell which holds a capability to his own personal
>directory in which one can store secret keys.

The above is again common to the capability systems that I am most
familiar with (e.g. RATS, NLTSS, Elephant, and I believe DVH).  By
authenticating, a "user" (connection) is given access to a
bootstrapping base "home" directory via some sort of a power
'shell' whose purpose is to grant the user full access to what
is in the directory.

>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.

One concept that I will mention at this point as it might bear
on what you (Peter) are concerned with, is a relatively minor
directory "trick" that has been discussed previously on this
list and I suspect many are familiar with.  I first saw this
in the Elephant storage system (~1970).  I'll call it the
"free access" right to a directory and describe it in the
form used in the NLTSS system, though there are a number of
variations and possibilities.

The idea is that if one (active object, process, etc., e.g.
acting on behalf of a person/user) is given access to a
directory with the "free access" right (e.g. access bit),
then capabilities can be fetched freely and directly from
the directory with all their access rights.

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.

The most common use of such a "free access" right is
to allow sharing of:

1.  Some directory capabilities with full access - i.e.
with the "free access" right, that may have, for example,
"write" access that includes the permission to insert
capabilities into the directory and to "write" to files
or to "insert" to directories fetched from the base
directory, and

2.  Some directory capabilities without full access -
i.e. without the "free access" right that may not
have the "write" access permission.  In this case
any fetched files or directories will also have
their "write" access turned off - even though they
are in the stored capabilities in the directory
as seen through a capability with the "free access"
permission.

I hope this idea is clear.  As I say, there are variations.
I mention it for general interest in this area.

> > The best solution I have been able to come up with seems to provide
> > the
> > user a "keyring" of capabilities.  When some code acting on behalf of
> > the user requires higher access than is available from the
> > reference it
> > currently holds, it would look up the object identifier in the keyring
> > to get the best capability for that object that has been granted to
> > that
> > user.  Access to the keyring would be carefully controlled, of course,
> > and by ensuring that untrusted code is never granted access to the
> > keyring, you can still delegate authority without giving away the keys
> > to the city.
>
>You have described what we called a 'directory' in keykos.
>It holds capabilities. About the only program with a key to the
>directory is the shell.

Hmmm.  I think I understand where Norm is coming from above, but
there is something about Peter's words that I don't understand:

> > When some code acting on behalf of
> > the user requires higher access than is available from the
> > reference it
> > currently holds, it would look up the object identifier in the keyring
> > to get the best capability for that object that has been granted to
> > that
> > user.

Of course the "shell" has access to the user's "home" directory
and thus to any permissions (and ultimately authority) that the
user has.  What I don't understand is the notion that the code
acting on behalf of a user has one sort of access and then
requires a "higher" access.  Where did it get the initial access
to begin with?  Perhaps this was granted when the code was
initialized?  Whether or not a running program (code, active
object, process) has access to some lesser capability or not,
to get some permission that it doesn't have it must ask or
otherwise be granted such access from outside itself.

A mechanisms along these lines that has also been discussed
often on this list is the "power box" mechanism.  This idea
is much like an "open file" window in a typical windowing
system (Windows, Mac, Unix) - EXCEPT, that instead of simply
providing a name for an object (e.g. file) that the program
can look up, the power box has access to the user's full
"home" directory (unlike the running program) and can fetch
a capability granted by the user (through the user interface -
e.g. the GUI) so that it will be returned to the running
program.  Only by such a means (generally through access to
capabilities that it does have) can a running program get
access to additional capabilities (permissions).

>We have not found a need for the shell to 'find the best capability';
>indeed that sounds like an invitation to confused deputy problems.
>If one is unclear why he should be able to do something it is best to
>first become clear rather that for some program to try to find an
>excuse why this user should be able to 'write on the file'.
>Just because that is what the Unix kernel does, does not mean it is
>convenient, merely conventional.

The above is puzzling and a bit confusing to me - though
I expect with further clarification I would agree.

> > 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.

Having used such a higher level sharing mechanism, one then
has the option to exercise control based on identity (the
identity labels for the capabilities) beyond just the normal
"bearer right" of capabilities.  For example, if one had
some authority through the servers of the capabilities, one
could block access to any capability whose responsible
identity was "Joe" - e.g. if Joe's access was removed
from some enterprise.  One could also add "Joe"'s access
back at a later time.  As discussed in Horton one could
track (e.g. audit/log) access by identity (e.g. again
"Joe") and chose to remove access based on logged actions.

> > In following with the c-list implementation I described previously,
> > each
> > capability key that is distributed would be logged with a user id.
> > Revoking a user's access to part or all of the system would be a
> > matter
> > of revoking the capabilities granted to that user.
>
>The Keykos practice was to zap the password that granted the person
>access to his persistent shell.
>This is more and less than what you suggest and there are arguments
>for both sorts of severance.

Hmmm.  I believe I understand what Norm is describing.  It is quite
difference than the "identity" based mechanism (e.g. Horton) that
I described above.  By "zap"ping a password, one would stop a
person knowing the password from initializing a new "shell" with
access to a person's 'home' directory for control through an
authenticated connection to the system.  However, "zap"ping such
a password would not stop access by existing processes (active
objects, running programs) with existing capabilities.

The Horton mechanism, by contrast, acts through labels associated
with the capabilities, so access can be blocked by identity to
running programs.

>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.

> > This may be the conventional solution -- I'm not sure, the E-Rights
> > page
> > is heavy on theory and abstract transactions, and light on design
> > patterns in practice.
> >
> > Are there any particular holes in this approach, and if so, are there
> > alternate preferred ways of designing a capability system that address
> > a) and b) above?  I think capabilities are the right underlying tool,
> > but the user experience needs to be more or less the same as how
> > people
> > interact with computer security now (minus the security breaches,
> > spyware, viruses etc :-)

I hope I've answered your question with my comments above.  If not,
let's iterate.  I'd very much like to understand and be sure that
we've been able to meet your core requirements with a capability
system (POLA protection).  Of course with the Horton system now on
the table also, we'd like to understand where the mechanism that
it provides can add value.

--Jed  http://www.webstart.com/jed-signature.html