Re: [capsicum] constructing a pure file descriptor from a capability



Robert,

Hi Bill:

The details are in the Capsicum paper, but the principle is that capability-mode processes are denied unscoped access to global namespaces. We consider the TCP/IP address/port space to be a global namespace, and so connect()/bind() isn't allowed.

Ah, I think I see now. So I can write a program that calls cap_enter(), then creates a socket, and from that socket creates a capability with CAP_CONNECT. But the program still won't be able to use that capability to actually connect to a resource. OK, I think I get it.

-Bill

 
Arguably, we should actually add new system calls for connectat() and bindat() system calls, which allow scoped connecting and binding of UNIX domain sockets via delegated file/directory capabilities. The principle is that capability-mode processes can inherit, or be delegated, sockets that are already bound or connected, meaning that they can use them from that point onwards, they just can't initiate the connection using a global name. A daemon process (perhaps thought of as a "socket server") can provide pre-connected/bound/etc sockets as a service to sandboxes. There's an interesting related question to do with minimising privileges associated with services that map between ambient global namespaces and sandboxes, which Capsicum doesn't specifically address -- you could imagine, for example, having variations on capability mode that permit use of global network namespaces, but not global file system ones. However, I'm tempted to start to prod at that idea only once we have a nice set of service daemons. The thrust of Pawel's casper work is to provide a framework for providing services to sandboxes, and launching services in sandboxes.

Robert




This archive was generated by a fusion of Pipermail (Mailman edition) and MHonArc.