Rights Amplification

[Marcus Brinkmann]

At Fri, 10 Jun 2005 16:55:05 +0200,
Bernhard Kauer <kauer at os.inf.tu-dresden.de> 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.

The question here is really if the L4 IPC "capabilities", ie
communication end points, can be used to implement "capabilities" of a
capability system.  The answer of course differs, depending on which
requirements you choose for the capability system.  We are looking
here specifically at a requirement for a certain form of rights
amplification, or synergy in general.

You seem to say that this should not even be attempted.  But that
would be pretty sad, because L4 end points almost have all properties
that are needed, and only little needs to be added.  And from
experience, capabilities without any kernel support just don't work.

> By using the sender id as an reference for a user, this problem is gone.

The problem is not gone.  Or rather, it is gone like a leg is gone if
you amputate it because of a broken toe.  Paul Watzlawick calls this
"Patt-End" solutions. ;) [1]

This is because you still have to implement a capability system, but
now without any kernel support whatsoever.  That just doesn't work.
It was a pain to do in L4 X.2, but in the upcoming L4 designs, it
would be even harder because now you also have to reintroduce global
IDs for tasks in userspace, and that is not easy.  This would mean
that instead of taking advantage of the upcoming security features, we
would have to battle and overcome them.  That makes little sense to
me, in particular if alternatives are pretty attractive from our point
of view.

> 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 very aware of the differences.  We have been there, done that,
and it just doesn't lead to a feasible system.  It's not that you
can't do it at all.  It just has all the wrong consequences: You keep
compromising one thing over another (performance over security, code
simplicity over performance, and so on) and once you look at
end-to-end performance, you will actually find Mach interesting again.
It's that bad.

Can you show me protected capability systems which are implemented on
L4 that work the way you suggest?  The "best" I can see is Mungi, and
that uses random OIDs, and thus doesn't even enter the picture,
because it is not a protected capability system at all.  And from what
you said, the upcoming L4 design won't change a thing, and just make
it harder.

I think that there is an excellent chance that the upcoming security
features can be used to build a fast and secure object/capability
system.  Solving the problem of multiple object references in messages
is essential for that.  However, I am even more sure that without any
kernel support, implementing a competitive and secure capability
system on top of L4 is nigh impossible.

I am not sure what further evidence I could give you that the
suggestion you make just doesn't work.  My own failed attempt and lack
of any other attempts in that direction are the reasons I can bring
forward.  I have tried really, really hard to make it work.  It could
just be my personal failure.  But it could also be a shortcoming of
the L4 design.

Maybe L4 is not supposed to support protected capability systems of
the type I imagine.  But that is not what you are saying---you are
saying I should pursue a path I have already walked and found to be
miserable.  I can only ask you to reconsider my argument, or to be
much, much, much more specific about how to do it the way you suggest.

Thanks,
Marcus

[1] Solutions which are so good that they not only remove the problem,
but everything associated with it.