Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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.

share|improve this question
5  
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

5 Answers 5

up vote 25 down vote accepted
  • 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)

  • 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.

share|improve this answer
    
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

A simple solution for Debian systems would be to run the script as the user nobody, "an account with no rights or permissions":

sudo -u nobody command

Of course, if the test programs do things like file manipulation, you might have to set up a small sandbox first:

sandbox="$(mktemp -d)"
sudo chown nobody "$sandbox"
sudo -u nobody touch "$sandbox"/writeable
share|improve this answer
    
that user exists only in Debian, or some other distribution as well? –  korda Nov 16 '11 at 12:39
    
@korda It is very common across distributions. –  rozcietrzewiacz Nov 16 '11 at 12:46
    
gotta check it out too then –  korda Nov 16 '11 at 12:48
1  
@rozcietrzewiacz is right. The only 100% secure approach (absolutely no possibility of harming anything other than the host) is to run things on a separate box with no network connection. Anything less (VM, jails, sandbox systems, nobody) has security holes from time to time and can be broken out of. –  l0b0 Nov 16 '11 at 13:23
2  
@korda Don't use the existing nobody user, use a dedicated account that you created. But that's not as much sandboxing as you can get for a reasonable price. Use a VM. –  Gilles Nov 16 '11 at 23:51

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

DESCRIPTION
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.

share|improve this answer

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.

share|improve this answer

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!

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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