Re: capability interface for idl4

[Jonathan S. Shapiro]

On Wed, 2005-10-05 at 01:19 +0200, Matthieu Lemerre wrote:
> I think that this is close enought to what we've already done to make
> the step.  If I take, for instance, the declaration of 
> hurd_pm_container_allocate:
> 
> error_t
> hurd_pm_container_allocate (hurd_pm_container_t container,
>                           l4_word_t start, l4_word_t size,
>                           l4_word_t flags, l4_word_t *amount)
> 
> hurd_pm_container_t is a capability to a container.  (It is not the
> case for now, but hurd_pm_container_t could be a pointer to a struct
> containing both the capability handle and the communication end point
> of the server).

For a temporary implementation while you wait for L4sec this is fine,
but it is an unacceptable production design. In the production system,
hurd_pm_container_t needs to be a capability index to a kernel-protected
capability. The capability must completely contain the in-kernel pointer
to the in-kernel endpoint data structure.

> >> 1. simple handle passing
> >>    We simply pass the handle for authentication. This means, the
> >>    server we pass the handle provides the cap.

This sounds like an unauthenticated transfer. I suspect that it is
fundamentally insecure. Can you given an example where you believe this
might be an appropriate operation?

You did give an example below this part of your note describing
authentication tokens, but I do not know what those are exactly. The
thing you described sounds suspiciously like a capability to a
credentials block. Once you add such a thing, you are done talking about
security.

>   If a copy operation is permitted, then a malicious server could copy
>   the authentification token to another server, and then you could not
>   do anything to revoke the right to use the authentification token to
>   the other server.  You would have to ask the notification to revoke
>   the right, which is most costly than a simple unmap operation.

I believe that the problem is MUCH more fundamental than this. The
entire idea of an authentication token (if I understand you) is a
mistake.

Challenge: identify even one scenario where an authentication token
provides real security. I bet that every scenario you propose I can show
how to break.

Finally: restricting copy operations is completely ineffective, because
a hostile server can proxy. Restricting copies does not in any way
improve security. You *do* need a way to revoke capabilities.

On the bright side, this does help reduce the total number of mechanisms
needed in the system.

> So I think the two objects are semantically different.  However, one 
> can be simulated in the other: you can copy objects by having a
> mutually trusted third party when you have map/unmap, and you can do a
> map operation by "wrapping" a capability when you have only copy.

There are bigger problems with map/unmap in capability systems. I would
like to take up that discussion, but I want to untangle the authority
token issue first.

shap