Re: Reliability of RPC services

[Jonathan S. Shapiro]

On Tue, 2006-04-25 at 12:22 +0200, Bas Wijnen wrote:
> On Mon, Apr 24, 2006 at 09:21:44PM -0400, Jonathan S. Shapiro wrote:
> > Yes, so now you have a situation where client A is notified of the
> > server's mishandling of client B. This is a security error. Coyotos will
> > not expose this fact.
> 
> I must be missing something here.  A and B have a communication channel (the
> reply capability), so the fact that A is sending a message to B cannot be the
> problem.

No. Client A has a channel to some server S. Client B has a channel to
S. Assume that S is a trusted server, and that A is not *supposed* to be
able to talk to B (or at least, not through this server). The drop
notice can be used to construct a channel between A and B.

> It reminds me of the DRM discussion we had:
>       The client doesn't _have to be_ notified when its capability is
>       dropped, but it can agree with the kernel that it will be.  Kernel
>       support is needed for this agreement, though.  So the question is: why
>       do you want to prevent such agreements from being made?

Because these agreements have the effect of disclosing third-party
behavior (as I have described above). It is inevitable that any kernel
will include a small number of such operations. Every one of those is an
exploitable design flaw, and must be resisted strongly. We will not get
rid of all of them, but we should not multiply them either.
 
> If the checks for capabilities being move-only give a too big performance hit,
> it would perhaps be possible to make a different object type of them, with a
> parallel set of kernel operations (except that they move, not copy).

This would be even *more* expensive.

> I want to describe the problem I am talking about again, because it surprises
> me how unimportant you seem to think it is:...

Please go re-read my seven step analysis from yesterday. I'm very aware
of what the problem is. It's just that I'm not willing to fundamentally
compromise the system architecture to admit the particular solution that
you like. I understand why the solution is attractive (in fact, I
*agree* that it is attractive). Unfortunately, it is expensive and
dangerous.

> Getting back to the beginning, C is waiting for S, but for the above reasons
> is never going to receive a reply.  This is conceptually too hard for the
> programmer, so we add an extra possible result... The notification is simply 
> one of the possible error conditions.

The problem with the idea is that this is NOT simply a new error
conditions. In a well-structured system, error conditions happen because
of things that *I* do (where "I" may include processes that I am
collaborating with, if we are sharing resources). In this case, the
error condition can happen because of something that someone *else*
does.

The correct word for this type of "feature" is "security hole", not
"error message".


shap