Capability Authentication

[Marcus Völp]

Hi,
this is a reply to an email I found in the l4-hurd mail archive 
[http://lists.gnu.org/archive/html/l4-hurd/2005-10/msg00020.html]. I'm not on the list, sorry.


On Fri, 2005-10-07 at 23:01 -0400, Jonathan S. Shapiro wrote:

>/ > > And, do we need the second one /
>/ > > to be provided by idl4? I say, usually the server will not trust its /
>/ > > client and this it's useless, as the server will not use the new handle./
>/ /
>/ You are making an incorrect assumption. In general, what you say is/
>/ true, but if the server can authenticate the validity of a capability,/
>/ there is no reason not to use it./
...


    The more general solution comes from something we call a "constructor".
    A "foo constructor" is a server that knows how to create new copies of
    the "foo" program. Every constructor inserts a unique, unforgeable, and
    undisclosable capability into the process structure of the process that
    it creates. This capability is called the "brand". Each constructor uses
    a different brand from all other constructors.

    In EROS, there is a kernel capability that performs (approximately) the
    following operation:

    interface ProcessTool extends key {
    bool identify(entry_cap_t someProc, cap_t brand);
    }

    Given an entry capability to a process and a second capability, the
    kernel checks whether the second capability is equal to the existing
    brand in the process. If so, it returns true, else it returns false.

    By construction, only constructors hold ProcessTool capabilities.
    However, if you hold a capability to a foo constructor, and you also
    hold an entry capability, you can turn to the foo constructor and ask
    "is this an entry capability to some process that you created?" That is:
    is it an entry capability to an authentic instance of "foo"?

    This authentication pattern is enormously important for many of the
    security arrangements that we are able to achieve in EROS. One of my
    largest concerns about L4sec is that the L4sec team does not (yet) see
    that this operation is important. Without an operation like this, it is
    impossible (or at least, we do not see how) to build robust third-party
    trust contracts.

Jonathan, yes so far L4.Sec does not support such an operation. We
thought about (I think Bernard Kauer and Marcus Brinkmann
already had a discussion on this topic on l4-hackers) adding
a compare operation on endpoints which allows you to match identity of two
endpoint capability (compare permissions provided). So far we are not sure
whether such an operation is really needed or whether you want to construct
systems the way you do. The fundamental issue is that a potentially trusted
capability is handed to a server by a not completely trusted source (the 
client C).

We thought briefly about two general solutions to this problem:
1) obtain a version of this capability from a trusted source, or,
2) prepare and defend against potential misbehavior of the invoked server.

ad 1:
This solution assumes a network of trusted "name"-servers and protocols 
that require the
client C in order to share a capability with some other process S that 
it establishes this sharing with
the target of the capability (D). C can do so by giving its name to S to 
D and asking D to share the rights
S can then request a capability to D from its trusted nameservers and 
ask for the shared capability provided
it trusts D.

Please keep in mind that we did not build such a system yet and that it 
is only a preliminary and potentially not working solution.

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.

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.

Best regards

    Marcus Völp


-- 
Marcus Völp

TU-Dresden 
Department of Computer Science
Institute for System Architecture

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