unix domain sockets, descriptor passing?

[Marcus Brinkmann]

Hi,

the basic assumption of our capability design is that we can prevent storing
capabilities provided by untrusted servers in other tasks.

Now, what about pflocal and descriptor passing?  In the Hurd, this is more
general: Instead passing descriptors, you pass capabilities.

Unfortunately, pflocal will not accept arbitrary capabilities in our scheme.
This is of course an intentional security feature.  It makes implemented
descriptor passing as it is implemented in BSD, AIX, Linux etc near
impossible though.

We might find a way to implement it on the user side.  The data over the
socket could contain the reference container and server thread information,
or some other data that allows the receiving task to acquire the capability
from some other place, for example directly from the sender, or from the
server providing it.  However, the former would require that the sender is
still running, while the latter would require that the sender knows the
receiver in advance.

Also please see http://www.ussg.iu.edu/hypermail/linux/net/9508.1/0060.html
for security problems with descriptor passing even in monolithical kernel
systems.  I don't know if this problem was ever fixed.

This is of course just an indication for a design problem in Unix/BSD.  One
way to fix it would be that each user has to create and use its own pflocal
server.  This basically means that we are implementing sockets in user space
without any system code.  In fact, I start to think that this, although it
would be not so good from a performance point of view, is the logical
conclusion of our fundamental design decisions.  This would also improve the
accounting of other resources like memory and cpu time.

Thanks,
Marcus

-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org    address@hidden
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
address@hidden
http://www.marcus-brinkmann.de/