[cap-talk] Capabilities - the rub, an account

Jed Donnelley jed at nersc.gov
Wed Nov 15 19:33:28 CST 2006


>On Nov 9, 2006, at 9:12 PM, Mark S. Miller wrote:
>
> > John Carlson wrote:
> >> Eric Jacobs wrote:
> >>> Jed at Webstart wrote:
> >>>> If you run on a capability infrastructure you can remove the account,

If you run on a capability infrastructure you can remove the account,
but then you think, "Oh my gosh, I wonder where he might have
delegated access to some of the resources he had access to?"
How do I remove any access that he might have delegated?"

> >>> Simple: revoke the proxy that you originally created for the
> >>> account.
> >> Must you "pass" the account to every single call to the kernel?
> >
> > What's an account?

An "account" is whatever authority a person receives after authenticating
to a system.  In the case of an object/capability system it's typically some
set of capabilities.  A person "logs in" (authenticates) and is given some sort
of access process (e.g. a 'shell') that can exercise all the person's authority
on their behalf.  One of the aspects we tout about object/capability systems
is the facility to limit the authority given to programs run by such 
a shell on a
person's behalf (e.g. Polaris, Plash, and other object/capability type
mechanisms).

I believe one of the areas that the object/capability community (us?) hasn't
come fully to grips with is that of the permanence of permissions granted
by capabilities.  It's easy for systems like Polaris or Plash to lean on the
underlying identity based access control mechanisms for permanence.

In the capability systems that I worked on (RATS and NLTSS, I expect
it's the same in KeyKOS, et. etc.) capabilities at least have the potential
to be permanent (in NLTSS processes were also permanent).  In that
context I believe there are some deeper issues associated with access
control that I at least don't believe have been fully vetted in capability
systems/in the object/capability community.  Specifically:

We talk a good line about revocable capabilities, membranes and
such.  We all know how such mechanisms can work in capability
systems.  However, consider capabilities in the light of what I hear
are the absolute minimum access control/audibility requirements
that many (most?) people dealing with computer security demand,
including:

1.  It's possible to look at the access control data on the system
and determine who has access to what (both starting from who
and finding what or starting from what and finding who),

2.  It must be possible to audit the system - find out who gave
what to who.  I'm not sure today's market leading systems
(e.g. Unix, Windows) actually succeed in this area, but it's
one that certainly gets a lot of lip service).

I'm not going to be able to finish this message this evening
as cleanly as I would like.  I do think I need to send it off.
Let me just say that I believe there is an issue with permanence
of access control granting that I haven't seen covered effectively
in capability systems.  Just consider the HP member of the
board who was removed from the board.  He looses his account.
Does that mean that all his delegations are removed?  Should
it?

If you argue that it should then it seems that all capabilities must
be labeled at least with a person (like an identifier) so they can be
revoked when the account is removed.  This would be a very strong
sort of membrane like facility for all users.  I've never seen such
implemented.  Others?

On the other hand that would seem to suggest that only some
sort of "superuser" would be able to grand permanent permissions
(give permanent capabilities) that extend beyond their own accounts.
That seems too much to me.

The above two thoughts suggest the need for some sort of distinction
(control?) over the permanence (separation from an identity/account)
in capability systems and "management" of same.  I'm not sure just
how that would/will work.

I think somebody like Lampson could be sold (resold) on the
object/capability model if the simplicity of the object oriented
parameter passing was made clear.  What I don't fully understand
is how that can be done while at the same time achieving the
minimum administrative controls needed for access control and
the minimum need auditing facilities.

Technically I'm hopefully optimistic.  Without even the needed
technology in place, however, it seems to me we are a very long way from
any sort of market success. 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061115/e90a3ef8/attachment.html 


More information about the cap-talk mailing list