[cap-talk] Another "core" principle - Brinkmann

[Jed Donnelley]

At 01:58 PM 12/22/2006, Marcus Brinkmann wrote:
>At Thu, 21 Dec 2006 13:02:34 -0800,
>Jed at Webstart <donnelley1 at webstart.com> wrote:
> >
> > At 05:26 PM 12/20/2006, Marcus Brinkmann wrote:
> > >At Wed, 20 Dec 2006 15:52:40 -0800,
> > >Jed at Webstart <donnelley1 at webstart.com> wrote:
> > > > I don't believe there is anything in the basic capability paradigm
> > > > that makes this so and I believe the object/capability paradigm
> > > > can handle this situation - without having to trigger a massive
> > > > re population of capabilities in Carol's directories and without
> > > > requiring re delegation by Carol (e.g. to Dave) and similar
> > > > repopulation of directories all the way down the chain - where
> > > > of course knowledge of this event should (and I argue can)
> > > > be largely unknown.
> > >
> > >I don't think there is anything intrinsically wrong with repopulating
> > >them, as long as it could be automatic.
> >
> > While it seems wasteful to me, I can accept that point.  Unfortunately
> > there is no way that it can be automated - at least not with ordinary
> > "user" access.  How could Alice (who is the one who wants to fix
> > the problem) get access to Carol's directories.  Even if we assume it's
> > Carol trying to fix her own problem (somehow the new capabilities
> > from Alice appear on the scene), what to do about poor Dave?
> > Neither Alice nor Carol can access his directory structure (which
> > of course I assume is on another machine on the network).
>
>Well, it could be possible under different assumptions.  Any specific
>technique can be impossible by raising the barrier, or by asking for
>deeper generalization.  But when one looks at a specific
>implementation, new possibilities can open up.

Hmmm.  Once a capability is delegated (e.g. as to Carol and to Dave),
it either continues to function or it doesn't.  It seems pretty straight
forward to me.  Not deep and no barriers, just simple capability
semantics.

>...
> > <mechanism description>
> >
> > If we're going to provide for revocable delegations, then it
> > seems clear to me that we need to do so in such a way that
> > down stream delegations are unaffected.
>
>Tentatively, I think I am not convinced that delegation should be
>intertwined with identities in the way you described.  The reason is
>that I am not sure it achieves much, but I might be missing something.

It is this binding of access to identities that is just what the TCSEC
people and those like them want.  I admit that despite my absolute
fanaticism with object-capabilities, I've been uncomfortable with no
means for dealing with access control on the basis of people.  Of
course ACLs do so, but to use straight ACLs one must give up
delegation and any hope of POLA access control.  That's way too
much to give up IMO.

Wouldn't it be wonderful if we could utilize a pure object-capability
mechanism and still achieve management of access by identity?
Even more wonderful if all access control administration is
by users (no "superuser"/root access required) that can perform
natural "delegation" actions and have the right thing happen?
Also it would be great to have logs that can be audited for
responsibility for actions by identity.

I believe the approach I've been describing achieves all the
above.  It seems to me to achieve a great deal.  However,
I read on about your concern:

>Let me describe what my concern is, and maybe you can easily get it
>out of the way.
>
>Say that we have a mechanism as you seem to desire, which allows Alice
>to delegate a capability to Bob, and Bob delegates to Carol, and then
>Alice (or who?)

It is Alice that has this permission.  Alice did the original
delegation and controls the "string" (is permitted by the
server to change policy for the "book keeping") for any
subsequent delegations.

>does some magic wiggeling with the left big toe and
>the delegation by Bob to Carol will survive a revocation by Bob.  I am
>now not looking at what this magic is, just what the outcome of it is.

The "magic" seems easy to me, but I like your approach:

>Carol now has this magic capability, but Carol does not know this.  In
>fact, Bob could have given Carol a proxy capability, which points
>directly to Bob.  Now the magic doesn't work any longer, and the
>capability that Carol got from Bob will not work when Bob's
>capabilities are revoked, or at any earlier time if Bob wants so.

Certainly.  That's the nature, the desired nature, of a proxy.

>Is this a desirable outcome?  Say you answer "yes, it's desirable".
>Then why even bother with the magic of the left big toe?  But say you
>answer "no, we want to avoid that".  Then we have to come up with a
>strategy to avoid it.  What could such a strategy be?

I argue that with the sort of responsibility delegation mechanism that
I've discussed available, it is wise policy to use that mechanism
for delegation between people.  This approach has the properties that

1.  Anybody can delegate to anybody else (of course identities
are needed, but as you say we can postpone that discussion).

2.  Anybody who has done a delegation can revoke it - BUT, with
the provision that anybody upstream of the delegation chain
can bypass any such delegation.

I imagine that all delegations to users would initially start from
an admin or root identity.  This would mean that in practice it
would always be possible for this administrator to override any
delegation revocations.

If a user wanted to insure that they could revoke a delegation and
they didn't want any possibility that it could be overridden, then
they could proxy directly or better yet start a new delegation
chain.

But then I ask, why would anybody want to do so?  Why would
Bob want to delegate this permission that he received from Alice
in such a way that his revocation couldn't be overridden by Alice?
Bob of course realizes that Alice was the source for his permission
(capability).  He knows that in principle Alice could delegate directly
to Carol (if Alice had been introduced to and trusted Carol with that
permission).  What does Bob hope to achieve by either proxying
or starting a new delegation chain?  Seemingly his only goal could
be to make things difficult for Carol.  I don't regard this as good
practice, so I believe recommended policy should be to use
what I'll call "responsible delegation" for all delegations between
people.

I argue that doing so will provide the sort of identity based management
of permissions while at the same time always using pure
capabilities that allow delegation for modularity and POLA.

>There would have to be some capability in Carol to some Very Wise
>Wizard which exists for Carol and is trusted by Carol independently of
>Bob.  The Very Wise Wizard may be Alice, or the server implementing
>the service, for example.  And Carol would have to invoke the
>capability passing Bob's delegation to Carol as an argument to an
>operation that basically says: "Is this capability magic?".  But if
>you have *that*, then it seems rather easy to me to make *that*
>operation perform the magic of the left big toe and pass a replacement
>capability as a return value, which is from then on used by Carol
>instead of the one gotten from Bob.  I see no alternative to these
>basic steps.  Do you?

Yes, I do.  We are talking about people here.  Carol get's this
error that says something like:

"Your capability in this delegation chain:

Admin -> Alice -> Bob -> Carol

no longer provides access because Bob's access has been
revoked.  Contact Alice or Admin to get your access restored."

Alice thinks about it for 2 seconds and decides, gosh, I can
never get the attention of that busy Admin, but Alice is in
my department and knows how important my work is with
this permission.  I'll contact her to see if she can restore
my access for me.  Note that the Admin would likely have
to get information from somebody else in any case to
do a bypass like that which Carol is requesting.

Carol calls Alice.  If Alice isn't around - tough luck.  Carol
will have to either try to get the Admin. to do the bypass
(which of course he/she may not have enough local
information to do) or she can wait for Alice to be available.

If Alice is available then it's a simple matter of Alice
invoking her Admin -> Alice capability for this object
and requesting, "Bypass <Bob> to <Carol>" (where
<Bob> and <Carol> are their identity representations,
e.g. public keys or public key hashes, or the
equivalent at the OS or language level).

At that point the server makes the appropriate
book keeping note (associated with this object), and
the next time a request comes in on:

Admin -> Alice -> Bob -> Carol
or more generally:

Admin -> Alice -> Bob -> Carol -> *  (e.g. including
   Admin -> Alice -> Bob -> Carol -> David )

the server provides access.

>In either case, the answer seems to be that indirect magic is
>unnecessary.

I don't see what the term "magic" adds except seeming to be
somewhat pejorative.  If by "indirect" you mean that this is
something that Carol can't get done through her existing
permission Admin -> Alice -> Bob -> Carol, then of course
that's right and that is the intent.

><snip>
> > If we can get the ability to delegate (at all times, everywhere, by every
> > subject - at least where they can communicate) - which I regard as
> > needed for modular development, parameter passing, and naturally
> > adapts simply to POLA) and at the same time get the identity based
> > access management that the TCSEC sorts of people want, it seems
> > to me we will have moved significantly forward.  The fact that by
> > doing so through the object-capability model we naturally enable
> > every subject (active entity, people, processes) to manage delegation
> > and identity based access control on their own seems to me to be
> > a big plus.
>
>I hesitate to open another can of worms, and I am afraid I have
>totally lost overview on the discussion, but has the issue of
>namespace management for identities come up already?  It seems to me a
>deep problem.  How do you manage a shared namespace for identities
>without some shared service?  This question is not entirely innocent:
>Note that such a shared service could act as a Very Wise Wizard in the
>scenario above.  By raising the namespace question I am basically
>pointing at another reason why there already may be a mechanism in
>place that could be used to avoid indirect magic.

My model for identities is public key pairs.  I'm not as familiar with
analogs at the OS and language levels, but it seems pretty straight
forward to me.  I believe MarkM's Horton protocol must deal with such
identities, so I look forward to following that development and clarifying
the corresponding semantics.

I don't see anything particularly deep about such identities.  E.g. you
can consider this to be my identity:

http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0xB70B7F99

I always think in terms of the extraterrestrial with which I've had only
data communication.  I build trust or not in any such identity through
interactions.  No problem.

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