Secure way to run other people code (sandbox) on my server?

Question

I want to make a web service that run other people code locally... Naturally, I want to limit their code access to certain "sandbox" directory, and that they wont be able to connect to other parts of my server (DB, main webserver, etc)

Whats the best way to do it?

Run VMware/Virtualbox:

(+) I guess it's as secure as it gets.. even if someone manage to "hack".. they only hack the guest machine

(+) can limit the cpu & memory the process uses

(+) easy to setup.. just create the VM

(-) harder to "connect" the sandbox directory from the host to the guest

(-) wasting extra memory and cpu for managing the VM

Run underprivileged user:

(+) doesnt waste extra resources

(+) sandbox directory is just a plain directory

(?) cant limit cpu and memory?

(?) dont know if it's secure enough...

Any other way?

Server running Fedora Core 8, the "other" codes written in Java & C++

Answer 1

1. Running under unprivileged user still allows a local attacker to exploit vulnerabilities to elevate privileges.
2. Allowing to execute code in a VM can be insecure as well; the attacker can gain access to host system, as recent VMWare vulnerability report has shown.

In my opinion, allowing running native code on your system in the first place is not a good idea from security point of view. Maybe you should reconsider allowing them to run native code, this will certainly reduce the risk.

Answer 2

To limit CPU and memory, you want to set limits for groups of processes (POSIX resource limits only apply to individual processes). You can do this using cgroups.

For example, to limit memory start by mounting the memory cgroups filesystem:

# mount cgroup -t cgroup -o memory /cgroups/memory

Then, create a new sub-directory for each group, e.g.

# mkdir /cgroups/memory/my-users

Put the processes you want constrained (process with PID "1234" here) into this group:

# cd /cgroups/memory/my-users
# echo 1234 >> tasks

Set the total memory limit for the group:

# echo 1000000 > memory.limit_in_bytes

If processes in the group fork child processes, they will also be in the group.

The above group sets the resident memory limit (i.e. constrained processes will start to swap rather than using more memory). Other cgroups let you constrain other things, such as CPU time.

You could either put your server process into the group (so that the whole system with all its users fall under the limits) or get the server to put each new session into a new group.

Answer 3

Reading the codepad.org/about page might give you some cool ideas.

http://codepad.org/about

Answer 4

chroot, jail, container, VServer/OpenVZ/etc., are generally more secure than running as an unprivileged user, but lighter-weight than full OS virtualization.

Also, for Java, you might trust the JVM's built-in sandboxing, and for compiling C++, NaCl claims to be able to sandbox x86 code.

But as Checkers' answer states, it's been proven possible to cause malicious damage from almost any "sandbox" in the past, and I would expect more holes to be continually found (and hopefully fixed) in the future. Do you really want to be running untrusted code?

Answer 5

try using lxc as a container for your apache server

Answer 6

Check out ulimit and friends for ways of limiting the underprivileged user's ability to DOS the machine.

Answer 7

Try learning a little about setting up policies for SELinux. If you're running a Red Hat box, you're good to go since they package it into the default distro.

This will be useful if you know the things to which the code should not have access. Or you can do the opposite, and only grant access to certain things.

However, those policies are complicated, and may require more investment in time than you may wish to put forth.

Answer 8

Use Ideone API - the simplest way.

Answer 9

Not sure about how much effort you want to put into this thing but could you run Xen like the VPS web hosts out there?

http://www.xen.org/

This would allow full root access on their little piece of the server without compromising the other users or the base system.