[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Thu, 26 Oct 2006 19:33:50 -0700,
Charles Landau <clandau at macslab.com> wrote:
> >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.

It would be a mistake for the server to process Alice's request after
checking obj2's copy passed by Carol and before completing Carol's
request.

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

I would rather say that what you have described is not a useful
semantic for object invocation in general.  Operations should complete
atomically unless one has good reasons otherwise, and even then the
server is of course responsible for (re-)validating all necessary
preconditions when restarting or continueing an operation.  I believe
that's an issue of multi-threaded programming practice and not
revocation semantics.  There are many other scenarios not involving
revocation which have the same potential problem, for example
withdrawing money, where the credit check needs to be performed
atomically with the actual transaction.

Thanks,
Marcus