sandbox to execute possibly unfriendly python code

Question

Hi, everyone.

Let's say there is a server on the internet that one can send a piece of code to for evaluation. At some point server takes all code that has been submitted, and starts running and evaluating it. However, at some point it will definitely bump into "os.system('rm -rf *')" sent by some evil programmer. Apart from "rm -rf" you could expect people try using the server to send spam or dos someone, or fool around with "while True: pass" kind of things.

Is there a way to coop with such unfriendly/untrusted code? In particular I'm interested in a solution for python. However if you have info for any other language, please share.

Answer 1

You can try some generic sanbox such as Sydbox or Gentoo's sandbox. They are not Python-specific.

Both can be configured to restrict read/write to some directories. Sydbox can even sandbox sockets.

Answer 2

It's impossible to provide an absolute solution for this because the definition of 'bad' is pretty hard to nail down.

Is opening and writing to a file bad or good? What if that file is /dev/ram?

You can profile signatures of behavior, or you can try to block anything that might be bad, but you'll never win. Javascript is a pretty good example of this, people run arbitrary javascript code all the time on their computers -- it's supposed to be sandboxed but there's all sorts of security problems and edge conditions that crop up.

I'm not saying don't try, you'll learn a lot from the process.

Many companies have spent millions (Intel just spent billions on McAffee) trying to understand how to detect 'bad code' -- and every day machines running McAffe anti-virus get infected with viruses. Python code isn't any less dangerous than C. You can run system calls, bind to C libraries, etc.

Answer 3

I would seriously consider virtualizing the environment to run this stuff, so that exploits in whatever mechanism you implement can be firewalled one more time by the configuration of the virtual machine.

Number of users and what kind of code you expect to test/run would have considerable influence on choices btw. If they aren't expected to link to files or databases, or run computationally intensive tasks, and you have very low pressure, you could be almost fine by just preventing file access entirely and imposing a time limit on the process before it gets killed and the submission flagged as too expensive or malicious.

If the code you're supposed to test might be any arbitrary Django extension or page, then you're in for a lot of work probably.

Answer 4

If you are not specific to CPython implementation, you should consider looking at PyPy^[wiki] for these purposes — this Python dialect allows transparent code sandboxing.

Otherwise, you can provide fake __builtin__ and __builtins__ in the corresponding globals/locals arguments to exec or eval.

Moreover, you can provide dictionary-like object instead of real dictionary and trace what untrusted code does with it's namespace.

Moreover, you can actually trace that code (issuing sys.settrace() inside restricted environment before any other code executed) so you can break execution if something will go bad.

If none of solutions is acceptable, use OS-level sandboxing like chroot, unionfs and standard multiprocess python module to spawn code worker in separate secured process.

Answer 5

I think a fix like this is going to be really hard and it reminds me of a lecture I attended about the benefits of programming in a virtual environment. If you're doing it virtually its cool if they bugger it. It wont solve a while True: pass but rm -rf / won't matter.

Answer 6

Unless I'm mistaken (and I very well might be), this is much of the reason behind the way Google changed Python for the App Engine. You run Python code on their server, but they've removed the ability to write to files. All data is saved in the "nosql" database.

It's not a direct answer to your question, but an example of how this problem has been dealt with in some circumstances.

Answer 7

You can check pysandbox which does just that, though the VM route is probably safer if you can afford it.