Rights Amplification

[Neal H. Walfield]

At Fri, 10 Jun 2005 16:55:05 +0200,
Bernhard Kauer wrote:
> > Within this framework, the only directly supported operations on such
> > capabilities are map, grant, unmap and IPC.  The map operation can be
> > used to delegate the capability, grant can be used to move the
> > capability and unmap to revoke it.  The IPC operation allows clients
> > to send messages to an object, for example, to invoke operations on
> > the object.
> 
> I think here is a difference to our view on capabilities: The IPC operation
> allows to send a message through an endpoint to a server. The server could 
> somehow identify the sender of a message.

As we understand it, the next gneration L4 API will not offer first
class capability objects.  The assumption has been that capabilities
will be built on top of end points.  So, I think we agree: there is no
fundamental equivalence between end points and capabilities and the
question at hand is: how do we represent capabilities?  I think we
made this clean in the introduction to the original email:

    Not much can be said about a capability system without first
    determining how capabilities are represented.  The current
    proposals assume that server objects will be represented by
    communication end points (more precisely, by the receive end).
    The send sides of the end points then assume the role of the
    capability.  This is not the only solution.  Other primary
    (kernel) objects following the map/grant/unmap semantics could be
    used to represent objects and capabilities.

> The server could 
> somehow identify the sender of a message.

Are you suggesting that we use the task id of the sender as the key?

The problem with *simply* using the sender of the message as
identification (i.e. no object key) is that it assumes that the sender
is the principle.  This doesn't need to be the case.  Consider a
trusted interpreter: it can serve many mutually untrusting clients
from the same thread.  If the server only uses the task id of the
sender to find the principle, the interpreter will have to implement
its own security architecture.  This is why ambient authority does not
make a good security architecture: this policy unnecessarily restricts
the type of authority principles one can have.  Moreover, exposing the
sender to the receiver violates the principle of least information
(i.e. only expose what is necessary and nothing more) and it also
makes copying access to an object more difficult and requires a
cooperative server.

It is possible to build a capability system using sender ids: the
server becomes a capability server and provides object IDs to clients.
We (primarily Marcus) did it.  The resulting system is slow.  The
reason?  The trust issues involved make the protocols very hairy.  We
finally abandoned the system when Marcus realized that interposing
proxies (a feature we highly desire) was far too complicated: the
server would need to accept capabilities from (i.e. block on)
untrusted clients.

> Using this sender identification as object reference, where the server
> invokes an operation on, is possible only if a single object reference is
> needed. As mentioned by Neal last week this does not work for multiple
> references.

I am sorry, I don't remember saying that or maybe I just don't
understand what you mean.

> By using the sender id as an reference for a user, this problem is gone.
> 
> To demonstrate the difference between these two attempts, look at a simple
> fileserver. If only read/write operations are needed the sender id could
> be the file number. But with an operation which needs multiple files like
> copying between two files, the sender id should identify only the user,
> but not the file anymore.

I am sorry, I don't completely understand this example.  It sounds to
me that you are suggesting is ACLs?  Is that right?

Thanks,
Neal