Sandboxing in Linux

Question

I want to create a Web app which would allow the user to upload some C code, and see the results of its execution (the code would be compiled on the server). The users are untrusted, which obviously has some huge security implications.

So I need to create some kind of sandbox for the apps. At the most basic level, I'd like to restrict access to the file system to some specified directories. I cannot use chroot jails directly, since the web app is not running as a privileged user. I guess a suid executable which sets up the jail would be an option.

The uploaded programs would be rather small, so they should execute quickly (a couple of seconds at most). Hence, I can kill the process after a preset timeout, but how do I ensure that it doesn't spawn new processes? Or if I can't, is killing the entire pgid a reliable method?

What would be the best way to go about this - other than "don't do it at all"? :) What other glaring security problems have I missed?

FWIW, the web app will be written in Python.

Answer 1

Although it is still in development, and not yet considered secure, you might check out the technology behind Google Native Client. It is designed to allow untrusted native code to be run in a web browser, but could probably be adapted for use on a web server. You might use something like this on top of other techniques such as a virtual machine, for additional security.

Answer 2

See this page on Google Chrome's sandboxing methods for Linux. As you can see, there are plenty of methods, but none of them are great for a distributable application like Chrome because some distros might not include them. This is not really a problem for a web application though, because you can control what is installed on your server.

Personally, my favorite is Seccomp, because it has a very low overhead compared to other tools like ptrace (switch address spaces on every syscall!) or KVM (big memory hungry virtual machine), and it is incredibly simple compared to tools like SELinux (and therefore more likely to be secure).

Answer 3

The few details you provide imply that you have administrative control over the server itself, so my suggestion makes this assumption.

I'd tackle this as a batch system. The web server accepts an upload of the source file, a process polls the submission directory, processes the file, and then submits the result to another directory which the web application polls until it finds the result and displays it.

The fun part is how to safely handle the execution.

My OS of choice is FreeBSD, so I'd set up a pre-configured jail (not to be confused with a vanilla chroot jail) that would compile, run, and save the output. Then, for each source file submission, launch a pristine copy of the jail for each execution, with a copy of the source file inside.

Provided that the jail's /dev is pruned down to almost nothing, system resource limits are set safely, and that the traffic can't route out of the jail (bound to unroutable address or simply firewalled), I would personally be comfortable running this on a server under my care.

Since you use Linux, I'd investigate User Mode Linux or Linux-VServer, which are very similar in concept to FreeBSD jails (I've never used them myself, but have read about them). There are several other such systems listed here.

This method is much more secure than a vanilla chroot jail, and it is much more light-weight than using full virtualization such as qemu/kvm or VMware.

I'm not a programmer, so I don't what kind of AJAX-y thing you could use to poll for the results, but I'm sure it could be done. As an admin, I would find this a fun project to partake in. Have fun. :)

Answer 4

There's a tool called strace - it monitors system calls made by a given process. You just need to watch out for specific calls suggesting 'illegal' function access. AFAIK, it's the method used in programming competitions to sandbox contestants' programs.

Answer 5

ptrace-based confinement for untrusted programs can be used like the one described in http://www.cs.vu.nl/~rutger/publications/jailer.pdf, http://www.cs.vu.nl/~guido/mansion/publications/ps/secrypt07.pdf.

They have a change-root-ing policy rule, CHRDIR, whose effect is similar to chroot. (Section "The jailing policy")

However, they might have not published their source code (partially based on a modified strace http://www.liacs.nl/~wichert/strace/ -- Section "Implementation")...

See also other available ptrace-based approaches to chroot-in-userpace: https://unix.stackexchange.com/a/72697/4319

Answer 6

On Fedora 11, there is the SELinux Sandbox which seems to do exactly what you want (except perhaps limiting spawning new processes; the linked blog post does not mention that).

Of course, there is always the risk of kernel bugs; even with SELinux, parts of the kernel are still exposed to all processes.