I'm writing a program that will test programs written by students. I'm afraid that I can't trust them and I need to make sure that it won't end up badly for the computer running it.

I was thinking about making some crash test user with limited access to system resources and run programs as that user, but from what I have found on the net so far, making a virtual system would be the safest option...

Can someone help me with choosing the right approach? Security is a big concern for me. On the other hand, I don't want a solution that is overkill and waste much time trying to learn something I don't really need.

  • 7
    Just run the program in linux in a browser (bellard.org/jslinux). It's a very good sandbox. :) – Fixee Nov 17 '11 at 6:41
  • wow, thats really interesting! however I would have to write some kind of interface to use it (since whole process is going to be automatic)... I need to check it out. If it turns out that this Javascript Linux is more than gadget I may even use it. – korda Nov 17 '11 at 9:49
  • I really intended my comment as a joke, but if you really can use it, that would be amazing. Honestly, the LiveCD answer (with RAMdisk) is a great solution. – Fixee Nov 17 '11 at 16:59
  • Well, if I would manage to use it I would also use it on webpage on which I can access results - that would be really nice and comfortable. Also geek factor counts ;) also live disk isn't option - as I said I'm making program it will run on some server so reboot isn't something I can afford... I guess I will stick with virtual machine anyway... – korda Nov 17 '11 at 17:23
  • Virtual machine can give you highest security without reboot, but lowest performance.

  • Another option, for even higher security than a virtual machine: boot a "live" CD/DVD/pendrive without access to the hard drive (temporarily disable the HDD in BIOS; if you can't, at least do not mount the drive / unmount it, if mounted automatically - but this is much less secure)

  • A docker container is a bit less secure alternative to a full virtual machine. Probably the crucial difference (in terms of security) between these two is that systems running in docker actually use the kernel of your host system.

  • There are programs such as isolate that will create a special, secured environment - this is generally called a sandbox - those are typically chroot-based, with additional supervision - find one that fits you.

  • A simple chroot will be least secure (esp. in regards to executing programs), though maybe a little faster, but... You'll need to build/copy a whole separate root tree and use bind mounts for /dev etc. (see Note 1 below!). So in general, this approach cannot be recommended, especially if you can use a more secure, and often easier to set up, sandbox environment.

Note 0: To the aspect of a "special user", like the nobody account: This gives hardly any security, much less than even a simple chroot. A nobody user can still access files and programs that have read and execute permissions set for other. You can test it with su -s /bin/sh -c 'some command' nobody. And if you have any configuration/history/cache file accessible to anybody (by a mistake or minor security hole), a program running with nobody's permissions can access it, grep for confidential data (like "pass=" etc.) and in many ways send it over the net or whatever.

Note 1: As Gilles pointed in a comment below, a simple chroot environment will give very little security against exploits aiming at privilege escalation. A sole chroot makes sense security-wise, only if the environment is minimal, consisting of security-confirmed programs only (but there still remains the risk of exploiting potential kernel-level vulnerabilities), and all the untrusted programs running in the chroot are running as a user who does not run any process outside the chroot. What chroot does prevent against (with the restrictions mentioned here), is direct system penetration without privilege escalation. However, as Gilles noted in another comment, even that level of security might get circumvented, allowing a program to break out of the chroot.

  • thanks for the answer. I'm a real newb when it comes to stuff like that, could you explain me one thing: why I need to prevent program from reading files in system (for example by chroot)? (if program can't modify them). – korda Nov 16 '11 at 12:21
  • A crash test user account gives you some basic security for sure. Still there are a number of things that you might want/need to prevent. Those can be in a form of exploits of common vulnerabilities embedded in the program or some social hacking, information gathering for the purpose of future remote attack... And probably much more. – rozcietrzewiacz Nov 16 '11 at 12:29
  • Why we are it: is there a way to prevent user from using internet connection? – korda Nov 16 '11 at 12:34
  • 1
    I wonder if nobody has internet access. – korda Nov 16 '11 at 12:50
  • 1
    @rozcietrzewiacz An important requirement for chroot to provide any protection is to not to run a chrooted program as a user who's also running a program outside the chroot. Otherwise the chrooted process can ptrace a non-chrooted process and do anything that way. – Gilles Nov 17 '11 at 8:32

Use a virtual machine. Anything less doesn't provide much security.

A few years ago I might have suggested a chrooted dedicated user or some such. But hardware has become more powerful, and virtual machine software has become easier to use. Furthermore, off-the-shelf attacks have become more sophisticated. There is no longer any reason not to go the whole way here.

I would recommend running VirtualBox. You can set up the virtual machine in a couple of minutes, then install a Linux distribution inside it. The only non-default setup I recommend is the networking setup: create both a “NAT” interface (to communicate with the world) and a “host only” interface (so you can easily copy files to and from the host, and ssh into the VM). Disable the NAT interface while you run your students' programs¹; enable it only when you're installing or upgrading software packages.

Inside the virtual machine, create one user per student.

¹ You can restrict the NAT interface to a whitelist of users, but that's more advanced than you need in a simple, to-the-point setup.


here is a very thorough explanation on why using Chroot is still a very viable option, and why full operating system or full hardware virtualization is especially overkill in specific scenarios.

it is nothing more than a myth that Chroot is not a security feature. there are tools that will build the chroot file system automatically for you, and Chroot is built into many mainstream applications as a purposeful security feature.

contrary to popular belief, not every situation requires full virtualization of the operating system, or full simulation of hardware. this can actually mean having more attack surface to try and cover. in turn, meaning a less secure system. (purportedly for less-knowledgeable system administrators)

the rules are fairly simple: do not put anything inside the chroot that isn't necessary. do not run a daemon as root. do not run a daemon as any user running a daemon outside of the chroot.

remove any insecure applications, setuid binaries, dangling ownerless symlinks /hardlinks. remount unnecessary folders using nosuid, noexec and nodev. build the latest stable version of the running daemon from source. and and most of all, secure the base system!


I'm going to add this, well after the question is officially answered: MAGIC: Malicious Aging in Circuits/Cores, which unfortunately is locked up behind ACM's paywall. The upshot of the paper is that the very small width traces in circuits in use today age during use, and eventually break down. By finding the correct instruction(s) and repeating them over and over, an attacker can age ICs to failure rapidly.

None of VM or sandbox or container or chroot jail would prevent this kind of malicious destruction of hardware. The authors of the paper found such instruction sequences, and experimentally aged hardware to failure, but they didn't give away the instructions, so it may not be a real threat for a while.


On BSD derived unixes (including Mac OS X) there is a facility called sandbox. The manpage says

The sandbox facility allows applications to voluntarily restrict their access to operating system resources. This safety mechanism is intended to limit potential damage in the event that a vulnerability is exploited. It is not a replacement for other operating system access controls.

This is separate from the chroot facility which is also available.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.