[cap-talk] capability copy and capability map
clandau at macslab.com
Thu Oct 26 21:33:50 CDT 2006
At 1:46 AM +0200 10/26/06, Marcus Brinkmann wrote:
>Let's look at a capability invocation that passes capabilities as
>arguments. This may be rights amplification, or a simple case of an
>operation that works on more than one server object at the same time.
>A simple example of the latter is an operation that does a virtual
>move or copy from one resource container to another.
For example, transferring money from one bank account (purse) to another.
>All these examples have in common that there is
>error_t foo (obj_t obj1, obj_t obj2, ...);
>where both objects, obj1 and obj2, are implemented by the same server.
>(I believe in EROS this issue is addressed with a "branding"
>This is how the mapping database looks before the invocation:
> S e r v e r
> |obj1 |obj2
> v v
> C l i e n t
>This is how the mapping database looks after the invocation:
> -- S e r v e r --
> |obj1 |obj2 ^
> v v |obj2
> -- C l i e n t --
I understand that you are invoking obj1 and passing obj2.
>The server now must perform an eq? operation on its own mapping of
>"obj2", which is at the root of the mapping tree, and the mapping of
>"obj2" which it got from the client, which is a leaf node of the
>The important feature is that for the purposes of authenticating the
>operation FOO on obj1 and obj2, the server is satisfied to receive a
>revocable copy of obj2.
This appears to me to be subject to a TOCTTOU attack. Suppose:
The server implements two bank accounts obj1 and obj2.
Carol holds obj1 which is derived from the server.
Alice holds obj2 derived from the server. Alice grants her obj2 to Carol.
Carol invokes her obj1 passing her obj2, requesting to transfer $100
from account obj2 to account obj1.
Server performs eq?(server's obj2, obj2 passed by Carol), which under
your assumptions returns true.
Now Alice decides she no longer wants Carol to have authority over
account obj2, and revokes Carol's obj2.
Alice invokes obj2 to find out what Carol did to the account before
it was revoked. Let us assume the server is multithreaded and replies
that account obj2 holds $100. Alice knows that no one other than
Alice and Carol have ever had access to account obj2, so there should
now remain $100 in account obj2.
Now the server continues processing Carol's invocation. Relying on
the result of the eq? operation performed above, the server transfers
$100 from account obj2 to account obj1.
I see no way for Alice to know at what point in time operations on
obj2 initiated by Carol will no longer take place. This does not seem
to be useful semantics for revocation.
More information about the cap-talk