[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Capability Authentication
From: |
Marcus Völp |
Subject: |
Re: Capability Authentication |
Date: |
Mon, 17 Oct 2005 12:55:09 +0200 |
User-agent: |
Debian Thunderbird 1.0.6 (X11/20050802) |
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
- Re: The Perils of Pluggability, (continued)
- Re: The Perils of Pluggability, Alfred M. Szmidt, 2005/10/10
- Re: The Perils of Pluggability, Jonathan S. Shapiro, 2005/10/10
- Re: The Perils of Pluggability, Matthieu Lemerre, 2005/10/10
- Re: The Perils of Pluggability, Alfred M. Szmidt, 2005/10/11
- Re: The Perils of Pluggability, Jonathan S. Shapiro, 2005/10/11
- Re: The Perils of Pluggability, Jonathan S. Shapiro, 2005/10/10
Re: The Perils of Pluggability (was: capability authentication), Alfred M. Szmidt, 2005/10/10
Re: Capability Authentication, Marcus Völp, 2005/10/13
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/14
- Re: Capability Authentication,
Marcus Völp <=
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/17
- Re: Capability Authentication, olafBuddenhagen, 2005/10/18
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/18
- Re: Capability Authentication, olafBuddenhagen, 2005/10/20
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/20
- Re: Capability Authentication, Jonathan S. Shapiro, 2005/10/21
- Re: Capability Authentication, Marcus Brinkmann, 2005/10/25
- Re: Capability Authentication, Jonathan S. Shapiro, 2005/10/25