Re: Reliability of RPC services

[Bas Wijnen]

On Tue, Apr 25, 2006 at 11:37:42AM -0400, Jonathan S. Shapiro wrote:
> Before I respond to any of this, please define your model using the
> lexicon that I sent out. There is no point responding if we are not
> using the same terms.
> 
> My comments were based on 
> 
>   reply capability = send once + notice on overwrite
> 
> which appeared to be the case you had defined at the time. You are now
> arguing about a different model, so I would like to be clear before I
> respond.

I have all the time been talking about send exactly once + notice on
non-reference.  Also, I have been assuming single-copy, because (as you wrote
in an other e-mail as well), this is the only reasonable way to implement
notice on non-reference.

For single-copy + notice on non-reference, notice on overwrite is implictly
true as well, but that's not what I'm conceptually talking about.

I hope this clears things up.

Thanks,
Bas

> On Tue, 2006-04-25 at 13:47 +0200, Bas Wijnen wrote:
> > 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
> > 
> > _______________________________________________
> > L4-hurd mailing list
> > address@hidden
> > http://lists.gnu.org/mailman/listinfo/l4-hurd
> 

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