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

[Jed Donnelley]

At 06:58 PM 12/8/2006, Jonathan S. Shapiro wrote:
>In the discussion of proxying and capabilities/ACLs, there is something
>that I think we are forgetting.
>
>Proxying is done by software, not by humans. There are many real
>installations where installed software is audited (sometimes after the
>fact), users do not have install authority, users do not have access to
>compilers, and users have limited access to scripting (e.g. scripting
>only within a confinement barrier).

I don't think this case is really being forgotten.  I think it's just
that it isn't the difficult situation to deal with.  If you only run
audited software or can't run software, can't create an automated
"subject", then it seems that delegation is pretty much a non issue.

>Observe that the most important protections are against unauthorized
>modification and unauthorized *bulk* disclosure. If a single user gets
>hit by a virus that leaks the limited number of records accessed by that
>user, this is a manageable business risk. In this case, the challenge is
>to protect the central service software from Trojans and viruses --
>which is (in practice) a manageable proposition.

POLA is just good O-O practice in any case - single user or
central service.  The cost for failures may be more or less
in different cases, but limiting access is a good idea in all
cases.

>In these environments, the purpose of a permission revocation mechanism
>isn't to revoke access.

At this point I'm not quite sure what "these environments" are.

>It is to ensure that access requires a
>combination of conspiracy and proxying software. That is: it is to
>establish a condition where the misbehaving party must dodge the audit
>process.
>
>This breaks down completely in a system with untracked delegation.

I'm not sure about "completely".  POLA is still POLA.  However, I
agree that tracking delegation adds value.  It's no longer the
laissez faire communication of permissions that the TCSEC document
criticized.

>This is relevant to identity-based access control as follows:
>
>Principal-based access control can be seen as a very course kind of
>membrane-based access control, where the set of processes running on
>behalf of a user all run within a per-user membrane associated with that
>user. The difference between this and our discussion of membranes is
>that revocation is not based on tracking dependency at transfer
>boundaries.

Sorry, but there still seems to be some huge differences between
what you refer to as "principle-based" access control and capability
based access control.  I keep asking the question about who/what
has permission to modify the ACL in principle-based access control.
I haven't heard an answer.  Is it:

1.  Any subject with access,
2.  The "owner" of the object (one user - defined who knows how),
3.  Some administrator or controller - whether human or automated policy.

The only case that comes close to providing adequate delegation
reasonable programming (even the simple case of breaking a single
program up into independently protected modules) is the first.
That gives you a facility somewhat like capabilities.  It still
has problems with breaking confinement (delegation without
communication) and confused deputies (at least), but with such
a scheme (unlike any ACL mechanism I've seen, because it opposed
deeply felt controls, the "fatal conceit", of those who value
ACLs), but it comes close.  Why consider even something like
that, however, if capabilities (communicable permission tokens)
can do the job and provide just as much responsibility tracking
access management by revocation?

>When we argue for membranes, we aren't arguing against principal-based
>access control. We are actually arguing for a combination of two things:
>
>   1. Dynamic creation of principals.

Certainly.

>   2. Dependency based revocation.

I'm not quite sure what you mean by the above, but we want much more.
We want the combined designation with authorization that capabilities
provide (avoid confused deputies).  We want natural OO semantics.
We want simple and direct delegation.  Responsibility tracking and
revocation of delegations are added values to be sure, but as we
have seen they are somewhat secondary.

>I want to suggest that these two points are largely orthogonal. It seems
>pretty clear that if we are going to have *any* type of principal-based
>controls, the ability to create new principals dynamically is an
>important thing regardless of the mechanism that captures the notion of
>principal.

Fine.

>The case for dependency-based revocation is more slippery, and I think
>it is much less clear. Dependency-based revocation seems predicated a
>dubious assumption:
>
>   My reliance on a capability is contingent on the source
>   of that capability.
>
>This is clearly flawed in the presence of capability validation. For
>example, if I can test that a capability you gave me is equivalent to a
>capability that I already have, then there are two usage scenarios:
>
>   a) I am holding the capability in service of you, in which case
>      it ought to get revoked when yours is revoked, and automatic
>      propagation of revocation seems desirable.
>   b) I am managing a capability that I received from you, but your
>      role is purely as the capability delivery (i.e. communication
>      channel). In this case my capability should not be contingent
>      upon yours.
>
>Note that KeyKOS, EROS, and Coyotos all support this form of capability
>validation.

I'm not sure I understand what you are getting at above Jonathan.
If I delegate to you and later decide you are no longer worthy
of my trust, it may be valuable for me to be able to revoke just
the permission that I delegated to you (and not my own or equivalent
permissions that I delegated to others).

Even if "I" am purely a capability delivery mechanism (as in some
sense a 'power box' in), there is still value in being able to
have responsibility tracking and revocation in the delegation.

>There appears to be a second dubious assumption, which is that we are
>able to articulate a sensible practical rule about when to introduce new
>membranes,

I believe I suggested a reasonable policy in this regard.  Perhaps you
could criticize my suggested policy (stated more carefully elsewhere,
but roughly track and be able to revoke for at least high level delegations
involving human action including delegations between people and delegation
to programs at startup).

>and also about which membrane crossings involve dependencies
>and which do not.

I don't understand what you mean by the above.  Any permissions
passed through a membrane must be themselves logically serviced
through the membrane.

>Finally, dependency-based revocation only looks attractive if we assume
>that dependencies form a lattice. When capabilities begin to traverse
>membrane domains in a cycle, we can very quickly get into some very
>surprising outcomes.

I don't see why.  A -> B -> A seems perfectly reasonable to me.
I'll have something to say about essentially unwrapping delegation
labeling/revocation in another message, but I don't believe cycles
of delegation cause any problem.

>At the moment, I am unclear how to sort all of this out in my head, and
>I would like to see some discussion about usage models and design
>patterns around these issues.

I believe I have a pretty clear picture of usage models and design
patterns in my thinking, but of course until we're dealing with
a running system it's difficult to say.  Much of my thinking is
based on running systems that I'm familiar with (e.g. RATS and
NLTSS and even network systems like widewords and YURLs), but
I'm trying to add value to those approaches with responsible
delegation with revocation.  I don't believe the addition
breaks the basic model, but I do believe it adds value.

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