[cap-talk] On revocation and the use of wrappers and In Defense of Identities

[Jed at Webstart]

At 06:38 AM 12/5/2006, Neal H. Walfield wrote:
>I have understood from my interactions with the capability community
>that the need for revocation is the exception and not the rule.  This
>is one reason to not use a wrapper by default, as is done in, for
>instance, the L4 world.
>
>Let's say that I have the following scenario: Frank is a file object
>to which Alice has read and write access.  Alice wants to give this
>object to Bob but wants to reserve the right to revoke this access
>later.  Let's say she uses a wrapper so Bob has access to Frank'.
>Now, Bob decides to delegate some of his access to Carol.  Namely, he
>wants to only delegate read access to Frank' to Carol.  Jonathan has
>advocated that the access bits should not lie in the capability but in
>the object.  As such, this delegation requires an interaction with the
>server.  Bob invokes Frank' with the fetchReadonly method and receives
>in his reply FrankR.  FrankR will continue to provide access to the
>file object even after Alice revokes the Frank' wrapper as Alice
>didn't use a membrane.  Here is the resulting access graph:
>
>                      Frank <--- FrankR
>                      ^   ^         ^
>                     /     \        |
>                  Alice -> Frank'  Carol
>                            ^
>                            |
>                           Bob
>
>What's the right solution here?  Should Alice have used a membrane?
>Should membranes be a first class object (like wrappers in EROS).  If
>so, how should resource accounting be done?

I sense a bit of flap here (including Jonathan's Defense) but about what
I regard an excellent, important, and I might say timely topic.
I believe MarkM and I (I mention MarkM for credit and not for
blame) have a solution for both Neal's concerns and for Jonathan's -
though I despair of communicating this solution via email without
a considerable additional amount of flap.  We discussed this topic
extensively at HP last Friday.  Let me see if I can cut through some
of the flap...:


Suppose you have a mechanism where if Alice has a permission
(any sort of permission really, I hesitate to use the term
"capability" because people seem to immediately infer
some preferred implementations) and Alice wishes to
delegate some subset of this permission to Bob in such
a way that any future exercise of the permission that
Alice delegates to Bob can be distinguished as the
permission that Alice delegated to Bob?  Suppose
further that the permission delegated to Bob can be
revoked by Alice and that Alice is unable to exercise
the permission so as to make it appear as if it was
Bob invoking it.

In a similar manner with further delegation to Carol.
Here's the picture as I see it:

                    ----low access----   Carol
                   /                       |
                  /                        ^
Object ("Frank") -----medium access --   Bob
                  \                        ^
                   \                       |
                    ----High access----   Alice

The burden falls on Frank and on the communication mechanism.
 From Frank's (the server's) perspective he needs to be able to
support the appropriate labeling and revocation of the permissions.
Alice should be able to revoke Bob's permission and anything
delegated from it.  Bob should be able to revoke Carol's
permission and anything derived from it.  In general Bob's
permission is a subset of what's available to Alice and
Carol's permission is a subset of what is available to Bob.
 From Frank's viewpoint this is a simple matter of bookeeping.

Furthermore (and this is where the new mechanism that I've
been discussing comes in) the permission that Bob
receives is labeled (at the server, Frank) as being delegated
from Alice to Bob.  The permission that Carol receives
is labeled as having been delegated from Bob (and before
that from Alice).  And finally, the permission received by
Bob is not available even to Alice.  When Bob invokes
this permission the invocation can be distinguished and
labeled as from Bob as delegated from Alice (even if
Bob might proxy it or further delegate it with or without
identity tracking).  Similarly when Bob further delegates
to Carol.

All the above can be done within the 'pure' object-capability
framework with no access control via identity (IBAC) at
any point.  I believe it can also be done reasonably efficiently
(though that depends on the context and implementation
of course - we'll see if this works out).  Really it 'just' amounts
to some handshaking with identities that then get recorded
as labels in the server, Frank as above.  Of course there is
a need for an identity mechanism, but that is for labeling/
auditing and independent of access control.

Let's stay at the level of semantics for a bit and ask, if we
had all the above, would it meet the needs expressed by
Neal and by Jonathan?  If not, then what else is needed?


Let me just say this here generally about delegation where
communication is possible:  Not only can it happen in
any case (by proxy as we know), it should be able to
happen, and conveniently.  This sort of delegation is at
the root of human (or machine) cooperation.  If there is
communication then collaboration can happen and should
be enabled.  If there was an intent to block collaboration
(and with it delegation) then it is the communication that
needs to be blocked (even if just by social or legal pressure)
to have any effect.

I believe the importance of the above delegation with
responsibility approach is that it can leverage any sort
of identity notion (e.g. web of trust, hierarchical, etc.)
that is available to label delegation and couple it with
revocation.  I believe that this is the best that can be
achieved in any digital system.  Let's see.
achieved.  I look forward to hearing from others what
more they feel is important.

--Jed http://www.webstart.com/jed/ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20061205/508ff17e/attachment.html