Put a process in a sandbox where it can do least harm

Mac OS X has a sandbox facility code-named Seatbelt. The public API for it is documented in the sandbox(7), sandbox_init(3), and related manual pages. The public API is somewhat limited, but the facility itself is very powerful. While the public API only lets you choose from some pre-defined sandboxes (e.g. “All sockets-based networking is prohibited”), you can also use the more powerful underlying implementation which allows you to specify exactly what operating system resources are available via a Scheme-like language. For example, here is an excerpt of the sandbox used for portmap:

(allow process-exec (regex #"^/usr/sbin/portmap$"))(allow file-read-data file-read-metadata (regex    #"^/etc"    #"^/usr/lib/.*\.dylib$"    #"^/var"    #"^/private/var/db/dyld/"    #"^/dev/urandom$"))(allow file-write-data (regex    #"^/dev/dtracehelper$"))

You can see many sandboxes used by the system in /usr/share/sandbox. It is easy to experiment with sandboxes by using the sandbox-exec(1) command.

For Windows, you may want to have a look at David LeBlanc’s “Practical Sandboxing” talk given at Black Hat USA 2007. Windows has no built-in sandboxing technology per se, so the techniques described leverage an incomplete mechanism introduced with Windows 2000 called SAFER. By using restricted tokens, one can create a process that has limited access to operating system resources.

For Linux, you might investigate the complicated SELinux mechanism:SELinux home,a HOWTO. It is used by Red Hat, for example, to harden some system services in some of their products.

For Windows there is a sandbox in Google Chrome. You may want to investigate it. It uses liberal BSD-like license.

For Linux there would be good old chroot or more sophisticated http://plash.beasts.org/wiki/.

OS X since Leopard has some SELinux-like protection available.

The site codepad.prg has a good "About" page on how they safely allow the execution of any code snippets..

Code execution is handled by a supervisor based on geordi. The strategy is to run everything under ptrace, with many system calls disallowed or ignored. Compilers and final executables are both executed in a chroot jail, with strict resource limits. The supervisor is written in Haskell.

When your app is remote code execution, you have to expect security problems. Rather than rely on just the chroot and ptrace supervisor, I've taken some additional precautions:

• The supervisor processes run on virtual machines, which are firewalled such that they are incapable of making outgoing connections.

• The machines that run the virtual machines are also heavily firewalled, and restored from their source images periodically.