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

Valerio Bellizzomi devbox at selnet.org
Thu Nov 16 19:03:54 CST 2006

On 15/11/2006, at 17.33, Jed Donnelley wrote:

>>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
>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
>set of capabilities.  A person "logs in" (authenticates) and is given
>of access process (e.g. a 'shell') that can exercise all the person's
>on their behalf.  One of the aspects we tout about object/capability
>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
>I believe one of the areas that the object/capability community (us?)
>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
>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
>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
>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,
>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
>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?

The issue of "labeling" recalls what I said about "marking", the
difference is that the "mark" should not contain a sensitivity level, but
a person identifier.
If we give each person an "account capability", then we can make all other
capabilities derived from the first one, in the sense that there is a sort
of dependency of all user capabilities in a given system upon the account
capability of the user. If we revoke the account capability, all other
capabilities are revoked along with delegations that depend upon his
account, to make an example in ACL systems, if you delete the user
account, all user directories are also deleted.

>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 see possible that the two figures of the "installer" and the "operator"
could replace together the figure of "superuser", thus we gain separation
over the identity/account permanence and management. The Installer could
have control over the permanence, and the Operator could have control over
Two distinct figures that both have partial control.

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

Here we agree, but never put the wagon in front of the horses.


More information about the cap-talk mailing list