l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reliability of RPC services


From: Marcus Brinkmann
Subject: Re: Reliability of RPC services
Date: Tue, 25 Apr 2006 13:16:00 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Tue, 25 Apr 2006 06:52:05 -0400,
"Jonathan S. Shapiro" <address@hidden> wrote:
> 
> On Tue, 2006-04-25 at 10:38 +0200, Michal Suchanek wrote:
> > On 4/25/06, Jonathan S. Shapiro <address@hidden> 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.
> > 
> > How is client A notified of mishandling of client B? It is only
> > notified when its own capability is dropped for whatever reason. Be it
> > server is killed, just drops it, forwards it to another server that
> > fails to handle it, or overwites it with a capability received from B.
> > But A cannot tell that.
> 
> You are mistaken. Assume that A and B are trying (improperly) to
> communicate by exploiting the drop notices. They *can* communicate this
> way.
> 
> When reasoning about system architecture, it is rarely good to say "X
> doesn't know Y", because this assumption is often wrong. A more
> productive approach is to ask "how could X and Y exploit this to achieve
> something unexpected?"

This discussion has gone astray, probably because parties have
different models in mind (I am not sure).

In the move-only-and-send-exactly-once model, there is no
communication possible between A and B if S properly handles the reply
capabilities.  If S does _not_ properly handle the reply capabilities,
all bets are off anyway.  That would just be an exploit of a bug in S,
not of the system architecture.

Thanks,
MArcus





reply via email to

[Prev in Thread] Current Thread [Next in Thread]