Re: capability interface for idl4

[Matthieu Lemerre]

"Jonathan S. Shapiro" <address@hidden> writes:

> 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.
>

What I would like here would be to have the IDL generate the code
depending on the implementation of the microkernel we choose, but with
keeping the same interfaces.  I have thought that capabilities could
be associated to an end point in the kernel, and it seems to be so in
EROS. 

BTW, by capability handle I mean the local number which is assocatied
with the capability.

I understand that having the knowledge of the endpoint when it is, for
instance, a global thread ID exposes far too much knowledge to the
client of a capability.

But what if the endpoint is a local mappable object?  AFAIK, in L4ng
you specify the number by which the endpoint will be accessible when
this endpoint is mapped to you.  If this is done for each capability
(provided that you can map the same endpoint to different numbers, and
you don't have a way to tell if 2 endpoints have the same receive
end), what is the problem of this approach?

>
>> >> 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?
>

Right, I have read Ness' post not enough carefully.  Simple handle
passing is an unauthenticated operation, and is useless since
capabilities are accounted by the kernel.

> 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.

Sorry, I don't know what you mean by credential block (as you may
know, I'm new to these capability problems).  What are they?

What I name authentification token is in fact some sorts of
capabilities that you cannot copy, just map/unmap/grant.

It is something which could be implemented on L4ka's L4ng by capIDs
(as described by Espen Skoglund in
http://os.inf.tu-dresden.de/pipermail/l4-hackers/2005/002190.html).

If I understand correctly, in EROS capabilities can be "only" copied,
whereas in L4 they can't, they can only be mapped/granted/unmap.

Copying could be simulated in L4 by using a trusted capability server
which would map the capabilities.  Marcus told me that you could
emulate mapping by "wrapping" a capability in EROS, although I haven't
read how this works yet.

Maybe I'm wrong, but it seems that both set of primitives enable the
same operations.  Maybe the L4 ones are unsecure to you?  I understand
that for instance unmap can be dangerous for fpages (the mappee would
have to be prepared to recover from a pagefault, this would be
unpractical).  But what if you can unmap capabilities?  You could just
try to do an operation on the capability, and you would know if the
IPC failed.

>>   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.

What I tried to do here was to show an example where capabilities
without copy operations could be better (for a performance point of
view) in some scenarii.  I think that unmaping an object is a less
costly operation than revoking the capability and re-creating a new
one.

>
> 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.
>

Were what I named authentification tokens what you thought they were?
If so, I would be interrested to know how what I described above (on
the notification server) would be unsecure.

>
> 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.
>

If a client gets a new capability from a server, what is the problem
if it maps it to other clients and unmap them (provided that unmap
would recursively unmap the mappings that the mappee could have done)?
Could some task keep a mapping of the capability if the client unmaps
everything it has mapped?

Could you explain to me how your proxying hostile server would work?

>
> 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.

Of course, I would be really interrested to hear them.

> shap

Thanks for your explanations,
Matthieu