[clug] Process sandboxing
jeffm at ghostgun.com
Tue Jul 19 07:50:15 MDT 2011
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.
More information about the linux