On 4/25/06, Jonathan S. Shapiro <[EMAIL PROTECTED]> wrote: > On Tue, 2006-04-25 at 10:38 +0200, Michal Suchanek wrote: > > On 4/25/06, Jonathan S. Shapiro <[EMAIL PROTECTED]> 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
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
