Ask HN: Is there a reliable way to sandbox untrusted code?
I'm designing on an application which involves running untrusted code. The untrusted code does not need to make any system calls, just take a string as input and return a string as output. There aren't any real constraints at this stage on the form in which the code should be provided. Source code, byte code or binaries would all be OK.
Are there any ways to do this securely, at the moment? NaCl is intriguing, but there hasn't been much incentive to break it yet. Java and Javascript sandboxes have probably been pounded on the hardest, but privilege escalation exploits for them do show up from time to time. Are there any other sandboxes I should be looking at? Is attempting to securely run untrusted code just a foolhardy enterprise?
4 comments
[ 3.5 ms ] story [ 36.6 ms ] threadhttp://stackoverflow.com/questions/1224708/how-can-i-create-...
You can do the same in any interpreted language that allows you to specify the environment to eval calls.
Here is a simple solution: have a single machine running a web app ("paste your code here") and one or more sandboxes (physical machines running off CD-ROM/NFS/anything nonwritable). On submission, the web server sends the code to one of the sandboxes, which compiles and executes it and returns any output (SSH seems convenient for this). Any other network access to/from the sandboxes is blocked. If one of the sandboxes stops accepting connections or otherwise misbehaves, reboot it.
This doesn't isolate the untrusted programs from each other. Sufficiently nasty code may be able to persist across reboots by nestling in firmware, but that does not pose an additional security problem. This setup is trivial to DoS, but it's simple and doesn't rely on, say, the Linux kernel being secure from local attacks - you just need a properly-configured firewall, e.g. on the web host ("drop all packets to/from sandboxes except locally-initiated SSH connections").