[capsicum] Already sandboxed apps in FreeBSD

I'd like to send a status update and describe which apps are sandboxed in my Github tree. * bspatch/bsdiff: opening of nessesary files is moved to the beginning of application, then cap_limitfd() on each nessesary fd and cap_enter(); * bzip2: functions that perform compression/decompression are executed in the forked separate process, that enters capability mode and signals about compression/decompression success/failures via exit code; * fetch: slightly modified libfetch to include file/socket descriptor information in internal data structure. The process of fetching data and writing it to local storage is performed in the separate forked sandboxed process. Parent and child exhange status information via socket pair using very simple RPC protocol. Because the size of "struct url" structure has changed, this introduces and ABI break, so I'm not sure this is safe to ship with 9.1-RELEASE. * lwresd/liblwresd: this is useful for DNS resolving support for sandboxed processes. The problem with traditional gethostbyname() and friends is that they open new network connection to different hosts (current DNS resolver) each time when new request is made. So it is impossible to use them in capability mode, when socket opening is not permitted. When using liblwres, an application makes a connection to the local lwresd daemon, that then sends a request to upstream server. I have modified liblwres library to use UNIX domain sockets instead of AF_INET UDP sockets for communication with lwresd, and added a new function that helps to initialize a connection to lwresd daemon when application has not yet entered capability mode. I have sent this patch to upsteam BIND devs, received some feedback and now try to adapt this patch to their requirements. The problem here is that AFAIK BIND will be probably removed from the base system when FreeBSD is released... Should be confirmed though. * syslogd: modified to fork() child process that enters capability mode and limits all opened file/socket descriptors. For certain operations (sending to remote host/port [operation "@"] and executing an external command [operation "|"]) the child sends a request to parent via socketpair and simple RPC. Currently proper handling of external commands executing is not implemented. That means, that parent does not query the status of child processes, so zombie count may increase in the system. I plan to fix this shortly. In general, syslogd is an example of an application that was not written with privilege separation in mind, and that requires huge rewrite to separate privileged and non-privileged part of an app. OpenBSD developers have done an excellent work for separating syslogd in their dev tree, by the way. So adapting OpenBSD syslogd will be easier, when OpenBSD supports Capsicum. By the way, it will be interesting to know about status of Capsicum porting to OpenBSD. Matthew, could you please write a couple of words? I'm currently preparing a talk for BSDDay'2012 in Wien, Austria, and I plan to include OpenBSD/NetBSD/Linux status as well. Thanks in advance! -- Regards, Ilya Bakulin http://kibab.com xmpp://kibab612 at jabber.ru