[cap-talk] - Karp - Capabilities - tracking responsibility (Was: Bellizzomi - Users in object/capability systems (was: MLS gone bad, Lampson))

Jed at Webstart donnelley1 at webstart.com
Tue Nov 28 18:47:54 CST 2006

At 04:20 PM 11/27/2006, Karp, Alan H wrote:
>Jed wrote:
> >
> > This approach was great for allowing users to make up what amount to
> > new groups on the fly.  However, this mechanism was subject to the
> > criticism that the TCSEC folks leveled at "traditional"
> > capability systems.
> > Namely there is no auditing with it.  Once I give out those
> > capabilities
> > everyone that I give them to has the exact same capability with the
> > same permissions and the same auditing trail.  That system did not
> > have the feature I suggested recently of making every delegated
> > capability different, with a delegation trail and
> > independently revocable,
> > and communicated in such a way that the sender cannot access the
> > delegated capability for proper responsibility tracking.
> >
>I assume that all communication is over secure channels.  I also assume
>that these channels can be mutually authenticating.  In that case, all
>you need do is keep a log in the messaging layer of messages and the
>channel over which they were received.  You now have your audit trail.

Hmmm.  Keeping a log of all permission communication would provide an
audit trail of a sort.  It seems a bit heavy handed and costly.  Still, I guess
it isn't that much worse than other logging systems do.  However, I don't
see how it would help with the assignment of responsibility.  I go back
to my example:

10/15/2006 17:23:10     Alan -> Sarah -> John
10/20/2006 13:15:07     Tyler -> Bob            ...
10/22/2006 23:17:45     Alan -> Sarah -> Sue
10/24/2006 09:24:16     Alan -> Sarah -> John

When the capability is accessed I want to know that it was the capability
that Tyler delegated to Bob and that the responsibility lies with Bob
as opposed to with Tyler.  For this to work it doesn't suffice for Tyler to
create a revocable capability - even one labeled as being for Bob - that he
then sends (by whatever means) to Bob.  The communication must be
such that Bob receives a capability that Tyler never had or was able to

Let me try a bit more redundancy in an effort to be clear.  Of course we
know that Tyler can exercise the permission that he delegated to
Bob.  What we (I anyway) want to do is to distinguish between
Tyler's exercise of that permission and Bob's - with capabilities as
opposed to an identity (processes with user identities) based approach.

Of course at any time Tyler can revoke the Tyler -> Bob capability,
but without Bob's permission Tyler can't invoke the Tyler -> Bob capability.
Tyler can invoke the Tyler instance of the capability to the same effect
except for the logging/auditing that notes the access by Tyler -> Bob
as opposed to an access by Tyler.

Of course I recognize (communicating conspirators) that an access
labeled as by Tyler -> Bob or one labeled as by Tyler can in fact be
made by any process/person with whom either can communicate -
whether by proxy or one hopes by direct capability communication.
Bob could even try to send the Tyler -> Bob capability back to Tyler
and to get Tyler to think that it was his original capability - e.g. in
an effort to place the blame for some operations on Tyler.

I'm not looking to block normal capability communication (which
as we know can't be blocked).  All I'm trying to do is to supply
a mechanism whereby responsibility can be assigned for actions,
at least to the level of people, much like in ACL based systems.

>You can make capabilities separately revocable by associating a "Do Not
>Honor" list with each channel authentication.  You can get a delegation
>trail by a mechanism such as the one you built for Managing Domains.
>Namely, associate a c-list with each channel authentication and record
>which channel the delegation request came from.  None of these require
>any changes by the capability creator or user, although the last does
>require an additional step to delegate.

I'm sorry, but I don't follow you in the above Alan.  Perhaps you (or
somebody else if I'm just being dense) could explain the above in a
bit more detail including the notions in my further explanation above.

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

More information about the cap-talk mailing list