Re: Reliability of RPC services

[Bas Wijnen]

On Tue, Apr 25, 2006 at 07:00:58AM -0400, Jonathan S. Shapiro wrote:
> 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.

Not at all.  Remember that no notice is sent in the usual situation.  Only if
S overwrites the reply capability _without first having used it_, does the
drop notification take place.  If S is well-behaving, this will never happen.
So B can try to send a message to A, but it will fail because S will not
simply overwrite A's capability when it should still use it.

Except if S is malicious, but in that case it will just set up a communication
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).

I think you are mistaken, at least with the system I'm thinking of.  You're
not still thinking of "notify on every overwrite, even after use", I hope?

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

I fully agree.  If this would indeed open such security holes as you
described, then it would be a very bad idea to implement it.  However, I don't
think it does.

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

As I said, you would probably know that better then me. :-)

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

Ah yes, you are right.  But I'm still surprised by how easily you say it's ok
to not solve it.

> It's just that I'm not willing to fundamentally compromise the system
> architecture

I fully agree that that price would be too high for anything.

> to admit the particular solution that you like.

However, I don't think it comes with this solution.

> I understand why the solution is attractive (in fact, I *agree* that it is
> attractive).  Unfortunately, it is expensive and dangerous.

You still haven't convinced me about the dangerous part.  I'm sure you know
more about the cost, and it's a pity that it's high.  However, I hope to
convince you about the importance of the problem (or be convinced about its
unimportance), which would lead to a reevaluation of what cost is acceptable.

I'll reply to Marcus' mail about going back from details to the problem with
some use cases.

> > 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 same is true for other error replies.  If the server says "I'm unable to
complete this request, because of foo", then the client will receive an error
because of something the server does.  This case is the same, the server
decides (probably by mistake) that it will not use the reply capability and
overwrites it.  This is _not_ a result of some other client providing a reply
capability in a request of its own.  This is only a result of the server doing
weird things.  It is not unlikely that it is so buggy that it can be taken
over by a client (turning it into a malicious server).  But if the server is
bug-free, then these overwrites will never happen.  The notification is really
meant for server crashes, but should for robustness also happen when the
server overwrites a _valid_ reply capability.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature