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

[Jed at Webstart]

At 05:14 PM 12/4/2006, Karp, Alan H wrote:
>...
>Identity tells us little about whether or not we should honor a specific
>request.  It is only as good as the relationships connected to it.

<tome with some repeat of previous material - working on wording>
Right.  A property of the human condition and any systems that we
construct. We have various technical tools for dealing with this
situation (e.g. PGP/GPG key introductions/Web of trust, hierarchies
that we put trust in, etc.).  I didn't start this thread in an effort to
improve our situation with regard to digital identities.  What I hoped
to do is to improve the situation with regard to delegation of
permissions with any available identities (the best we have).

I'm responding to what I understand from reading "Traditional
Capability-Based systems: An Analysis of Their Ability to Meet the
Trusted Computer Security Evaluation Criteria":

http://www.webstart.com/jed/papers/P-1935/

are some of the concerns that the Defense/MLS, etc.
community has about capabilities.  In a nut shell what
that concern amounts to is that they feel capabilities
are too laissez faire.  That is, they are concerned when
they see that any subject can communicate a capability
(and the permission that it embodies) to any other subject
that they can communicate with.

We of course know that this is inevitable - it is the
communicating conspirators problem.  Does this mean
that the TCSEC people are simply asking for the
impossible and blaming capability systems for not
giving it to them?

Reading a bit between the lines, I don't think so.
The TCSEC people and some of the recent papers
supporting the object/capability paradigm both point
to capability revocation as being helpful in this area
(concern about "laissez faire").  At least with capability
revocation Alice can communicate a permission to
Bob that allows Bob to perform whatever action
Alice is requesting, but at the same time allowing
Alice to retain the ability to revoke that permission
at any time.  Alice is sending a different permission
to Bob than the one Alice keeps for herself.

Is this the best we can do for the TCSEC concerns?

I think we can do better.  I believe that we can do all
that can really be done within the object/capability
paradigm.  What else do the TSCEC people need?
They also need logging and auditing.  They want to
know who did what when.  Can we give that to them
within the object/capability paradigm?  Last Friday
Mark Miller demonstrated that yes we can give
them the ability to find out who did what when - in
so far as it's possible to know (these identity
discussions that we've been having).

Imagine Alice and Bob to be people, with Alice
choosing to delegate a permission to Bob.
The TCSEC folks want to know when it's Alice
exercising the permission and when it's Bob.
Of course we know Alice could proxy for Bob, but
let's assume Alice is trying to do the delegation
in support of the auditing.  That is, she wants to
delegate to Bob but not to be responsible for
Bob's actions with the permission she delegates
to him.

When Alice is delegating to Bob and choosing
to delegate a revocable capability, she could
at the same time add to that revocable capability
what is essentially a label, e.g. "delegated to Bob".
She could then send that revocable and labeled
capability to Bob.

Unfortunately, the above simple approach doesn't
work out too well for Bob.  If Alice carries out the
above procedure, at the end of it Bob has a labeled
capability that Alice can revoke, but Alice also
has that capability.  How can the auditors know
that any requests on that capability are the responsibility
of Bob and not of Alice.  They can't.

The last piece of this puzzle is to provide a means for
Alice to communicate a capability to Bob that is labeled
and revocable and that Bob receives but Alice doesn't
(at least initially and without Bob's complicity) possess.

Identity based access control systems (IBACs) give the impression
that they can always report who did what when.  They claim
to be able to do so because every subject in the system
has an identity (e.g. a user identifier) and access is controlled
and could be reported on the basis of who did what when.
We know that this impression is often an illusion, since
IBACs make it so difficult enough to do delegation that more
often than not some sort of proxying is done in it's place
(e.g. access like that through Web and other servers that
cause so many security problems on networks).

Still, I've never seen any means for tracking access based
on identity in capability systems.  One could argue (as the
above TCSEC group report did) that object/capability systems
are inadequate in that regard.  Now that we can demonstrate
an object/capability mechanism for tracking responsibility
through delegation, one that clarifies just what can really
be achieved through such means, it seems that we can
argue that object/capability systems are at least as strong
as IBAC systems in this regard as well.
</tome>

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