Re: Capability Authentication

[Marcus Völp]

Marcus Brinkmann wrote:

> Maybe someone
> smarter than me can fix that, but in my view this requires more
> changes to L4 than the addition of a cmp operation.
>  
As I said, the fact that we did not include a cmp operation yet is 
simply because we were not sure to need it. Once you convince us cmp is 
in, provided it opens no further security leaks.

> BTW, the protocol you describe doesn't even work, as in L4.sec there
> is no way for "C" to name "S" in its request to "D".  Introducing such
> names, which would have to be authenticated, is impossible if C and S
> have a certain asymmetric trust relationship.  However, there _are_
> protocols which work, and I have worked them out (you can ask me for
> more details).  They all require RPCs in which capabilities are passed
> as arguments and can be identified by the receiver, for example using
> a cmp operation.
>  
It would be great if you could provide us these protocols. Actually that 
is what we are currently searching for to determine whether the proposed 
architecture will work out.

> Also, this proposal does not address the general case where an
> operation must be performed on more than one capability, like server
> side copy operations.
>  
I know this proposal is not complete and we can find various scenarios 
where it seems not to work. With regard to server side copy we are not 
quite sure yet whether we need such an operation. But this again assumes 
some system structure which performs the copy in a server that can 
savely invoke capabilities.

> > ad 2:
> > Alternatively the server can prepare to defend against misbehavior of D. 
> > In L4.Sec the receiver of an IPC controls the location where an incoming 
> > message is placed. Thus it can select an area of its address space so 
> > that even if D replies with bogus content, S is not harmed. It remains, 
> > however, the problem of blocking S. An easy way to defend against 
> > blocking attacks is to fork of a thread for this particular client's 
> > request and let it invoke the pot. untrusted capability on behalf of the 
> > client. Other thread invoking the same server are not affected by this 
> > blocking.
> >    
>
> This proposal achieves nothing.  First of all, there is no benchmark
> that tells you when you have waited long enough and the capability
> should be rejected, for example because the destination blocked too
> long.  But even more seriously, there is no benchmark to decide when
> the capability is good and its implementation be trusted.  Thus, this
> proposal does not achieve the original goal at all.
>
> It's nice that I can create a new thread to restrict the damage caused
> by a blocking RPC partner.  But it has nothing to do with what you
> want to achieve in Jonathans example.
>  
I don't agree here. The proposal is to be able to decide on the trust of 
a capability after invoking it and avoiding the damage when it turned 
out not to be trusted. This has nothing to do with blocking time but 
more with a server structure that acts for and on behalf of a client.

Jonathan's example (I assume you refer to the example where the server 
has to decide whether or not to leak secure data) works by requesting 
the not yet trusted target of the capability to authenticate itself 
(e.g., via the kernel protected badge send with the reply IPC) and
to leak information only after the knowing that the server is trusted.

> > Again please keep in mind that both are preliminary solutions. We have 
> > still to construct a system on top of L4.Sec. Also please note that 
> > L4.Sec is not a fixed API but has experimental status and that we 
> > welcome both suggestions for improvement and requirements. However, you 
> > will find that features will be added only if they cannot be implemented 
> > on top of L4.Sec with a reasonable effort. This is one of the 
> > fundamental rules which in my opinion contributed to the success of L4. 
> > So  please apologize my stubbornness  in this point. Compare might be 
> > such a feature which will get added if we find no way to achieve what 
> > Jonathan listed in his mail.
> >    
>
> You addressed this note to Jonathan, but I hope you will not mind if I
> share my opinion on it.  From my perspective, it is totally fine that
> you are conservative in what you adopt for your design and
> implementation.  It's also fine to have a focus on certain aspects of
> the system and leave other aspects completely aside.
>  
You misunderstood me here. The above solutions describes our current 
vaque direction at what systems we want to build on top. It does not 
mean that we leave other aspects completely aside. We just have no 
resources right now to look at them all. I hope when analysing your 
protocols we will have the use cases we need to decide whether the 
current API will work or how it must be adapted. The note above is not  
addressed to Jonathan only, I just wanted to point out that we will 
continue trying to keep the kernel interface small because this is in my 
opinion one of the reasons for L4's success.

> But I am rather puzzled by your suggested preliminary solutions.  The
> first doesn't work, and the second doesn't address the problem at all.
> At least to me they don't offer any insight into the following
> questions:
>
> 1. Is the design pattern actually desirable?
>  
I don't know yet. We did not yet design / build a system of a scale 
which would allow us to answer this question. We are right now looking 
into such a system and we would welcome any contributions and a detailed 
understanding of your envisaged system.

> 2. If yes, can it be _efficiently_ supported by the L4 architecture
>   with a reasonable effort?
>  
Since the answer to the first question is a don't know we should not 
talk about efficiency yet. If a system structure cannot efficiently be 
supported by L4 we need to understand why and if it turns out to be the 
kernel which causes the inefficiency we will change it. Do you have any 
numbers for your architecture where you find L4 to be the bottleneck 
(assuming the functions you need were added).

Marcus


--
Marcus Völp

TU-Dresden 
Department of Computer Science
Institute for System Architecture

Tel: +49 (351) 463-38350
Fax: +49 (351) 463-38284