[clug] Process sandboxing

[jm]

This is a bit of a summary to date with a bit more background.

On the weekends I'm currently playing around writing an Erlang port for 
Lua. There's all ready a few ways out there to bridge Erlang to Lua (a 
port, a dynamically loaded driver, and a node). This is more a 
programming exercise for me to write a more complex port program. I've 
previously written a port to use Linux's inotify.

For the curious there's an explanation about ports at  
http://www.erlang.org/doc/tutorial/c_portdriver.html A node would do a 
similar thing over a network with minor added complexity. While a  
driver is dynamic library loaded into the erlang emulator and has the 
down side that a bug in the driver can crash the emulator.  Not a good 
thing when your boasting about how erlang doesn't crash. The up side is 
that it is faster.

Anyway, one of the good things about lua is that the scripts can only 
call functions you give it access to. Hence, it occurred to me that 
while there are already ports written for bridges to other languages 
(eg, python, ruby, etc) that creating a port which would allow execution 
of scripts in a tightly controlled prison could be a promising idea. 
This leads me to what is needed to do this is

 * a channel to communicate with the erlang process
 * restricted access to the file system so as to be able to load modules 
and load/store modules.
 * limit the CPU the script can use (worry about this later)
 * limit the memory the script can use (worry about this later)
 * a way to control what other resources the script can access


Containers: such as OpenVZ and LXC, I've only read a few articles, but I 
seem to be able to specify (based on the  lxc.conf man page) having a 
loop back only (can I actually to it off?), create its own pseudo tty, 
specify a root fie system, drop capabilities ( is there a drop all and 
then add option?), limit cpu usage, limit device usage (by explicit 
allow). This may work, I'll just have to spend some time playing with 
config files to create a template and workout how to automate it.

seccomp: Very limited access to begin with, use a trustee thread to ask 
for permission for everything. Seems to fullfil most of the above except 
limiting CPU and memory usage. Should be easily automated. The trustee 
thread may have security issues as in order for it to work it can only 
use cpu registers for variables. As long as the trustee thread doesn't 
need to be modified to make this work this shouldn't be a problem.

Finally, lxc will be in the kernel for the foreseeable future and 
seccomp  does seem to be under active development based on the existence 
of some recent articles on lwn.net about it.

later,
Jeff.