Re: cap exchange race with map/unmap

[Marcus Brinkmann]

At Wed, 19 Oct 2005 15:57:43 +0100,
Neal H. Walfield wrote:
> > It can require too much trust when receiving a copy of a capability:
> > The receiver must trust the server (by making a blocking RPC to it)
> > even for just accepting the copy.  This may be a problem in your
> > system architecture design.  (I am not sure it is a problem in our
> > hurd-on-l4 design.  It depends on if a server actually makes a call on
> > an auth, container, etc capability, or if those are only used as
> > authentication tokens).
> 
> I think this is the killer argument for the cap server as library
> design: in order for a client, A, to pass a capability to a second
> client B, B must make a blocking call to the server implementing the
> object named by the capability.  This is not a problem if B will
> invoke the capability eventually anyways as is the general case,
> e.g. when using a file object.  However, capabilities are not always
> used like this: sometimes they are only passed as arguments.
> 
> Imagine that a task (A) uses the system auth server (AUTH), that a
> second task (B) uses a proxy auth server (PROX) which in turn
> interfaces with AUTH and that A wants to authenticate itself to B.
> According to the current protocols (i.e. as inherited from the Hurd on
> Mach), A invokes auth_user_authenticate on a capability naming AUTH.
> AUTH returns a capability to A which it needs to pass to B.  According
> to the protocol, B would then invoke auth_server_authenticate on a
> capability naming its auth server passing the capability as an
> argument (as well as the permitted users).  The problem is that in
> order for B to accept the capability from A, it must make a blocking
> call to AUTH, however, B knows nothing directly about AUTH: it only
> knows about it via PROX.  Since we know the context, B could ask its
> auth server, i.e. PROX, if AUTH is trusted, before accepting the
> capability.  As you can see, the protocol gets increasingly complex
> and performance is problematic.

This example comes from me, and I have used it in the past to argue
this way.  But this was when we used thread IDs to identify servers,
and thus could make a direct thread ID comparison to see if the
capability (supposedly) comes from a trusted server.  This is not true
anymore for any of the "secure" variants of L4.

In those secure variants, you must make an upcall to the proxy auth
server anyway (and the proxy auth server to the real auth server) to
authenticate the capability before you can actually invoke RPCs on it.
So, this is not the difference anymore.

However, just for completeness, there is another way to avoid the
problem, and that is to never copy the capability in the first place.
Instead, you just make revocable copies all along the way of the
operation you intend to perform, as arguments to RPCs to trusted
objects.  This is also problematic, however (performance, breaking
abstraction).

Thanks,
Marcus