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

Jed at Webstart donnelley1 at webstart.com
Thu Nov 16 20:06:17 CST 2006


At 10:53 AM 11/16/2006, Marc Stiegler wrote:

> > 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).
>
>This topic does seem to keep recurring here. Points:
>
>1. It makes no difference whether you are using caps or acls, you cannot
>tell who has access, you can only tell who was given a direct enough
>access such that you can hold them accountable.

While this is of course literally true, I believe it understates the case
against object/capability systems.  In identity based ACL systems access
is only directly granted through the identity based ACL mechanisms (e.g. Unix).
Since programs run as users with their identity (I of course know this non POLA
is a problem, please don't jump on me here as I play devil's advocate)
there is no issue with separate "principal" identities for running
programs (processes, active objects).   Consequently one can determine
who has direct access by looking at the ACL (e.g. ugo rwx and group
in Unix).  Regarding indirect (e.g. proxy) access:

>Those who have direct
>access can proxy, thereby spreading access beyond your control but not
>spreading accountability beyond your control.  The beginning of sanity is
>for everyone, both people on this list and computer security pros in
>general, to understand this.

I agree to an extent (my position on this 'inalienable right' to
delegate should be well known on this list), but again I think
it understates the case against object/capability systems.

The most important factor in this area I think is that any
proxying disappears when the active process doing the
proxying goes away - as it inevitably does in many cases
(often at a logout, a kill, but certainly when a system restarts
in today's systems).

Another factor I believe is that such proxying doesn't seem
to be a practical problem from the security viewpoint.  Others
can correct me, but I don't know of any instances of script
kitties or the like installing proxy access.  I think part of the
reason they don't is that such access isn't permanent enough
to suit their needs (see above about the limited lifetime of
processes).

>Accountability is what you really wanted
>anyway. So the 2 requirements deserve to be rewritten to reflect what
>people actually want and actually can get (which happen to be the same)
>rather than what they think they have and think they can get (which are
>similar though different). A first necessary step toward security is
>discarding one's illusions, for the attackers will discard your
>illusions whether you do or not.

We agree that proxying without explicit delegation is possible whenever
there is a communication channel available.  We agree that this is
important for everybody to understand going forward.  I also believe
that trying to block delegation (at least revocable delegation - more
on revocation and membranes below) when communication is available
is pointless - though others even on this list have disagreed.

Even if we accept the above as truths to deal with, however, all
object/capability systems that I'm aware of do much more direct
delegation without the sorts of controls that the security people
want to see.   This is partly because they just do much more delegation.
More delegation is to the good (I believe), but if one follows Lampson's
argument it comes at the cost of additional complexity (certainly
true to some extent as there is more delegation) that is unmanageable
in a practical system.

I believe what he's getting at (or would be if he had all the necessary
information) is that if object/capability systems are to do explicit
delegation at the fine grained level they claim to add value at (namely
on a per process basis), then they have to meet the high standards
for visibility and auditability that ACL systems meet for their direct
delegation and avoid impractical complexity.  He doesn't believe that's
possible.

We argue (subtly trying to get back on the object capability side)
that most of this apparent additional complexity is illusory.  That
it comes automatically by using good object oriented programming
techniques throughout a system.  We argue that in the few places
where the additional complexity isn't handled automatically (e.g.
at application initialization - where some profiles are needed for
initial capabilities and where the power box notion can add
authority at no more cost than with a typical "open file" window)
the needed additional mechanisms are relatively minor (once
built into a system) and that their minor cost is well worth
their POLA gain (e.g. against Trojan horses).

OK, so much for the summary of where I think we stand.  Now for
"the rub".  I believe that people like Huskamp et. al. (NCSC TCSEC)
and Lampson feel that the "flexible" and "free" delegation used by
capability systems (communicate a permission token wherever
communication can happen) works directly AGAINST what they
feel is important in computer systems in making directly visible
who has access to what and auditing.

I don't believe this need be the case, but I appreciate their point.
To illustrate why I don't believe this need be the case consider
an extreme example.

Suppose we had a classical capability system (descriptor based,
along the Dennis and Van Horn lines - think KeyKOS if you like)
where every time a capability was communicated from one process
to another it was re labeled to indicate an additional delegation.
Think of this as some sort of automated proxy mechanism supported
by the message passing kernel if you like.

This could of course get somewhat unwieldy after a time
(Alice gave it to Bob who gave it to Larry who gave it
to Moe who ...), but we're just thinking things through here,
so follow with me for a moment.

Now at any time one could say, OK, Larry is out of the
game (the Larry process is destroyed is one way to think
of this, but there are others) and any delegations by Larry
should be revoked.  Now some delegations like in the above
() expression would be revoked and others would not.

This sort of approach could be compared to others, e.g.
to Alan's oft discussed mechanism of always proxying
in, what? Cap Desk?.  One could argue that if for efficiency
proxies were cut out at any point, then there should be
an "accounting" mechanism to get the recovacability that
the explicit proxy would have allowed.  For example, in
the Distributed Capability Computing System if system
A passes a capability to system B who then passes it
to system C, when B says to C, "You no longer need to
come through me to access this capability.  I've told A
about you and you can access it directly from A" then
the permission that C has to the capability at A would have
to indicated that it came via B.  This would be so that if
B is cut out of the equation (more on this below r.e.
"permanence" of capabilities) then that capability could become
invalid but not one more directly delegated on A.

I hope the above discussion might make more clear my
concern about management of "permanent" capabilities.
Namely those that are independent of any proxy or delegation
revocation.  If I do a chgrp in Unix (for example) and change "who"
(which UIDs, e.g. by adding all those in a group) can access a file,
even after my chgrp process is long gone those permissions
remain.  This is the intent of such a direct, visible, auditable
delegation.  I had to be the owner of this file/directory to make
such a change.

I don't want to get sucked in to defending such mechanisms to
the end. I can't defend them, certainly not in a network context.
I'm still playing the devil's advocate.  However, I want to make
clear the ways in which they are different from typical capability
delegation and those aspects of the differences that appeal to
many people (simplicity, visibility, auditability).

If we were to track all delegations as I suggested above (re labeling
every communicated/delegated capability) then I believe it would
achieve some of the visibility and control that the ACL defenders want.
Would it do so at too high a cost in complexity?  Perhaps so.
Could "permanent" (not revoked when a delegating process
is destroyed) capabilities still be granted and adequately managed
(from the perspective of the ACL defenders) with such a scheme?
I'm not sure.  I'm just trying to get all the issues out on the table
for discussion.

>3. It is easy with acls to ask a resource for a list of who to hold
>accountable/who has direct access. It is easy with caps to ask an object
>what authorities it holds. Going the other/unnatural way is hard with
>either system. But it is not impossible with either system, even though
>no acl system seems in my experience to be bidirectionally informative.

In an ACL system like Unix it's easy to determine who has access to
what (where "who" is a UID) by looking at what groups the UID is in
and then rumbling through the file system looking at access permissions.
The practical "ACL" systems we have do give us the relevant information
in both directions I believe.

In a capability system the equivalent it seems to me would be to
go "rumbling" through the principals (users?, processes?) looking
at capability lists to determine who has access to what.  I don't know
of any capability system in which such an approach is viable.

Something like this:

>For the CapWiki, part of the design is, every time a user creates a cap
>for delegation, we put an entry for the revoker and audit trail on that
>user's home page, and include as much info as we can extract from the
>context and the user's explicit entries about who/why/how long this cap
>is for. This will give the user as much (well, actually, more)
>understanding of what authorities he has passed out, and who he passed
>them to, and what those people he gave the authority to should be held
>accountable for, than he gets with any traditional popular acl system.

or something like I suggested above might make more complete delegation
and revocation information available.  However, doesn't this then get into
the very sort of complexity that Lampson is arguing against?  What
policies are enforced regarding such information?

I have to admit that I'm waffling between a devil's advocate and a real
advocate (of the identity/ACL approach).  If a day one capability
advocate and believer like me ends up waffling and seeing fundamental
problems with the capability approach (while still accepting the
value of POLA in principle and accepting that communicating
conspirators can't be blocked from delegating) then I think it's
easy to see why others (e.g. Lampson, Schneider, etc.) will have
difficulties with the object/capability paradigm and argue against it.

This is pretty fundamental stuff we're talking about here.

When we get to the network level of communication of permissions, I really
don't see how any sort of identity/ACL based approach can work.  Something
like communicable permission tokens (capabilities) seem inevitable to me.
Can we get the desired tracking, management, visibility, and auditability
at that level?  Many (most?) on this list don't even seem to feel that network
level capabilities are an important issue.  I think that may be another issue
keeping the object/capability from getting traction.

Whew!  Maybe it's time for another face to face discussion of these
topics - e.g. at HP.

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




More information about the cap-talk mailing list