On Tue, Jul 28, 2009 at 08:37:36AM +0200, Bas Wijnen wrote: > On Sun, Jul 26, 2009 at 01:53:29PM +0200, Bas Wijnen wrote: > > The ability to contact a thread is one thing you need a capability for. > > But to contact a thread with a certain request (and no other) is also > > something capabilities should allow for. That is hard to implement > > without kernel protection, AFAICS. > > I forgot to mention a feature that is not possible without kernel > protection: encapsulation. If the server is responsible for its access > control, it is impossible to forbid it to _receive_ messages from > untrusted sources. If there is a program that is willing to listen, it > can simply not do access control, and allow any request. That means > that you never know if a program can communicate (in fact both incoming > and outgoing) with other programs. AFAICS, the only solution to this is > kernel support.
Strictly speaking, encapsulation of this kind is possible without kernel support; just look at qemu or similar---run your untrusted code in a system emulator and all is safe. The problem is doing this efficiently; kernel support is required if you want to solve the problem with less of a sledge hammer. -- Sam http://samason.me.uk/
