Re: Reliability of RPC services

[Jonathan S. Shapiro]

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.

shap

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