Re: cap exchange race with map/unmap

[Neal H. Walfield]

At Wed, 19 Oct 2005 15:37:17 +0200,
Marcus Brinkmann wrote:
> 
> At Wed, 19 Oct 2005 14:21:23 +0200,
> Bas Wijnen <address@hidden> wrote:
> > I note that the capability server as a library approach isn't being 
> > discussed
> > at the moment.  Is there something wrong with it?
> 
> Yes.  First of all, it fundamentally requires that the individual
> clients and copy operations are disclosed to the server.  This may be
> a violation of your security policy.
> 
> 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.

Thanks,
Neal