Re: Reliability of RPC services

[Michal Suchanek]

On 4/25/06, 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?"

To rephrase this:
Assume A and B are trying (improperly) to communicate by exploiting a
bug in S. They can communicate this way.
When reasoning about system architecture, it is rarely good to say "X
and Y will not know there is a bug in Z", because this assumption is
often wrong. A more constructive approach is to ask "how could X and Y
exploit this to achieve something unexpected?"

The notices should usually only result from errors. They make the
error more noticable. This makes it somewhat easier to detect the
error and somewhat easier to abuse the error as well.
But one could also imagine that when A's reply capability is
overwritten with B's B is not unlikely to receive A's result instead
of its own.

Thanks

Michal