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

[Jed at Webstart]

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

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

>But I have to admit I haven't caught up with the latest email storm,
>so I don't know if it has been discussed before and if any problems
>with that have been identified.

It has been a blizzard.  I feel we're making progress, but I'm not
yet sure if we're reaching consensus.

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

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

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