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

[Marcus Brinkmann]

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.

> >However, I think I would
> >explore a system design first where all delegations are explicit in
> >the manner that if Alice wants Bob to delegate a capability from Alice
> >to Carol directly, without going through Bob, then Bob should have the
> >authority to do just that, in some automatic fashion.
> 
> I'll just clarify that all of these actions are what I'm assuming the
> people involved wanted:
> 
> 1.  Alice -> Bob -> Carol -> Dave  ("->" indicates delegates to),
> 
> 2.  Bob's access is revoked,
> 
> 3.  Carol is introduced to Alice and Alice decides that Carol
> should be trusted with the authority delegated to her from
> Alice via Bob.
> 
> Namely, Alice delegated to Bob as part of her work.
> Bob delegated to Carol as part of his work.  Carol
> delegated to Dave as part of his work.
> 
> Bob leaves the organization or otherwise has his
> access revoked.  Note that this only becomes an
> issue because we're trying to add value by allowing
> these sorts of delegations to begin with (which nominal
> ACL systems cannot do) AND we want the delegations
> to be revokable (which ACL systems can do - at least
> for those who have write access to the ACL for an object).
> 
> At this point Bob's access is revoked.  The right thing
> happens and the access delegated to Carol and thence
> to David becomes unusable.
> 
> Carol or Dave complain and say they can no longer get their
> work done.  If they should no longer have the access that
> Bob delegated through Carol, then the right thing is happening
> and that's it.
> 
> However, what about the case (common in ACL systems)
> where Carol (and thence Dave) should have some of the
> access that Bob delegated independent of Bob?  In some
> ways this is the default case in ACL systems.  ACL
> systems can't do delegation except independently of the
> delegator.  That being the case this issue doesn't come up
> in ACL systems.  Instead the dual of this issue comes up,
> namely that there is no effective way for Carol to do the
> delegation to begin with.
> 
> 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.
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?) 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.

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.

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?

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?

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

> >I didn't really get the connection
> >between the membrane discussion and the group management discussion,
> >they seem to me to be quite orthogonal.
> 
> I'm not sure about the "group" notion (though I believe that could
> also be added), but I do feel that adding identities as labels for
> explicit delegation through membranes adds value in object-capability
> systems as I've described.

It may be so, but I am not sure under what other constraints.
 
> >I merely want to point out that the design space is rather large, and
> >even primitive operations that do not directly translate to the high
> >level constructs you want to build can be meaningful or appropriate.
> 
> 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.

Thanks,
Marcus