Take the 2-minute tour ×

I was wondering if there exists a way to run an untrusted C program under a sandbox in linux. Something that would prevent the program from opening files, or network connections, or forking, exec, etc?

It would be a small program, a homework assignment, that gets uploaded to a server and has unit tests executed on it. So the program would be short lived.

share|improve this question
Is this like a single C program you need to run 1 time for 5 minutes, or something you need to run constantly? –  bwawok Nov 22 '10 at 18:51
It would be a small program that gets uploaded and has unit tests executed on it. So the program would be short lived. –  Frank Nov 22 '10 at 19:07
What distribution is the system using? Some distributions have ready-made tools for sandboxing. Does your system have any security model like SELinux or AppArmor enabled ? –  thkala Nov 22 '10 at 19:18
I'm using Fedora 13. I'm looking into SELinux Sandbox policy. I'm wondering what other options exist. –  Frank Nov 22 '10 at 19:43
show 1 more comment

9 Answers

up vote 22 down vote accepted

I have used Systrace to sandbox untrusted programs both interactively and in automatic mode. It has a ptrace()-based backend which allows its use on a Linux system without special privileges, as well as a far faster and more poweful backend which requires patching the kernel.

It is also possible to create a sandbox on Unix-like systems using chroot(1), although that is not quite as easy or secure. Linux Containers and FreeBSD jails are a better alternative to chroot. Another alternative on Linux is to use a security framework like SELinux or AppArmor, which is what I would propose for production systems.

We would be able to help you more if you told as what exactly it is that you want to do.


Systrace would work for your case, but I think that something based on the Linux Security Model like AppArmor or SELinux is a more standard, and thus preferred, alternative, depending on your distribution.


While chroot(1) is available on most (all?) Unix-like systems, it has quite a few issues:

  • It can be broken out of. If you are going to actually compile or run untrusted C programs on your system, you are especially vulnerable to this issue. And if your students are anything like mine, someone WILL try to break out of the jail.

  • You have to create a full independent filesystem hierarchy with everything that is necessary for your task. You do not have to have a compiler in the chroot, but anything that is required to run the compiled programs should be included. While there are utilities that help with this, it's still not trivial.

  • You have to maintain the chroot. Since it is independent, the chroot files will not be updated along with your distribution. You will have to either recreate the chroot regularly, or include the necessary update tools in it, which would essentially require that it be a full-blown Linux distribution. You will also have to keep system and user data (passwords, input files e.t.c.) synchronized with the host system.

  • chroot() only protects the filesystem. It does not prevent a malicious program from opening network sockets or a badly-written one from sucking up every available resource.

The resource usage problem is common among all alternatives. Filesystem quotas will prevent programs from filling the disk. Proper ulimit (setrlimit() in C) settings can protect against memory overuse and any fork bombs, as well as put a stop to CPU hogs. nice(1) can lower the priority of those programs so that the computer can be used for any tasks that are deemed more important with no problem.

share|improve this answer
Thanks, I've added more description! –  Frank Nov 22 '10 at 19:10
systrace worked for me for simple, programs, but got stuck indefinitely when GNU as(1) as run by GCC. So I gave up on it. It's an unfixed bug in systrace: forum.soft32.com/linux/… –  pts Dec 10 '10 at 18:57
add comment

Well, if NaCl research proceeds properly then you should eventually be able to download a Native Client compiler (aka a modified LLVM), compile all assignments with that and run.

For now I suggest you use seccomp - look at the man page for prctl. AFAIK, this stops your process from being able to do anything beyond operate on the already opened handles.

share|improve this answer
Thanks for the tip on seccomp. It looks relatively easy to use compared to configuring SELinux. I'm going to take a closer look at this. –  Frank Nov 22 '10 at 23:09
add comment

I wrote an overview of sandboxing techniques in Linux recently. I think your easiest approach would be to use Linux containers (lxc) if you dont mind about forking and so on, which don't really matter in this environment. You can give the process a read only root file system, an isolated loopback network connection, and you can still kill it easily and set memory limits etc.

Seccomp is going to be a bit difficult, as the code cannot even allocate memory.

Selinux is the other option, but I think it might be more work than a container.

share|improve this answer
add comment

Try User-mode Linux. It has about 1% performance overhead for CPU-intensive jobs, but it may be 6 times slower for I/O-intensive jobs.

share|improve this answer
This looks great! Thank you for the suggestion. –  Frank Jul 11 '11 at 21:05
add comment

Running it inside a virtual machine should offer you all the security and restrictions you want.

QEMU would be a good fit for that and all the work (downloading the application, updating the disk image, starting QEMU, running the application inside it, and saving the output for later retrieval) could be scripted for automated tests runs.

share|improve this answer
I don't know about the OP, but launching a VM per test program would be unacceptable in many cases. In my environment (I'm a TA) there can be as many as 200 students submitting 10-12 programs each within a 2-hour period. No program runs for more than 10sec CPU-time, but when the submissions pile up we get turn-around times of 15min or more. Introducing a VM for each program would push the CPU-time to 60sec or more per program and I don't want to think about the turn-around times at all. Maybe a VM per session, but no way we could do that per-program... –  thkala Nov 22 '10 at 22:13
@thkala This is a good point. I like the idea of QEMU but starting a VM for each submission is not good. –  Frank Nov 22 '10 at 23:13
Well, in that case, keep the same VM running all the time. –  Laurent Parenteau Nov 23 '10 at 19:10
Could you do something using a snapshot of a vm that's all booted and ready to compile & run code? FYI, vm's are not necessarily immune to piercing. You could also build a hardware version of this - a small system that boots a resume image off read-only media or over the network and provides output via network or serial, then gets rebooted for the next. There've been some quick booting advances that get linux up in a few seconds. –  Chris Stratton Nov 24 '10 at 18:11
@thkala: That means you'd need less than 3 seconds per submission if you ran them serially. The approach I posted probably takes around 3 seconds on a modern machine (serially). If you parallelize (which you might as well) it would be fast enough. –  Janus Troelsen May 19 '13 at 19:40
add comment

This library should serve your goal well


Good luck!

share|improve this answer
This does not seem to be actively maintained. It also seems to require a Linux kernel patch, which would make it mostly useless considering that its latest version dates back to 2003. –  thkala Nov 22 '10 at 19:11
add comment

When it goes about sanboxing based on ptrace (strace) check-out:

"sydbox" sandbox and "pinktrace" programming library ( it's C99 but there are bindings to python and ruby as far as I know).

Collected links related to topic:


(sorry that not direct links, but no enough reputation points yet)

share|improve this answer
add comment

Do you know about chroot?

But it is not always trivial to use. One of the other answers might wrap it up nicely for you.

share|improve this answer
I have heard of chroot. I hear that there are well known ways to break out of chroot, I've even seen an example somewhere. –  Frank Nov 22 '10 at 19:48
@Frank: That's part of the non-triviality. But an important question here is "What exactly are you defending against?" A chroot jail should go a long way towards protecting against random bad programming or aspecific attacks. If you're facing a directed attack its a whole 'nother ball game. –  dmckee Nov 22 '10 at 19:52
add comment

You can use Qemu to test assignments quickly. This procedure below takes less than 5 seconds on my 5 year old laptop.

Let's assume the student has to develop a program that takes unsigned ints, each on their own line, until a line with "-1" arrives. The program should then average all the ints and output "Average: %f". Here's how you could test program completely isolated:

  1. First, get root.bin from Jslinux, we'll use that as the userland (it has the tcc C-compiler):

    wget https://github.com/levskaya/jslinux-deobfuscated/raw/master/root.bin

  2. We want to put the student's submission in root.bin, so set up the loop device:

    sudo losetup /dev/loop0 root.bin

    (you could use fuseext2 for this too, but it's not very stable. If it stabilizes, you won't need root for any of this)

  3. Make an empty directory:

    mkdir mountpoint

  4. Mount root.bin:

    sudo mount /dev/loop0 mountpoint

  5. Enter the mounted filesystem:

    cd mountpoint.

  6. Fix rights:

    sudo chown -R `whoami` .

  7. mkdir -p etc/init.d
  8. vi etc/init.d:

    cd /root
    echo READY 2>&1 > /dev/ttyS0
    tcc assignment.c 2>&1 > /dev/ttyS0
    ./a.out 2>&1 > /dev/ttyS0
  9. chmod +x etc/init.d/rcS

  10. Copy the submission to the VM:

    cp ~/student_assignment.c root/assignment.c

  11. Exit the VM's root FS:

    cd ..

  12. sudo umount mountpoint
  13. Now the image is ready, we just need to run it. It will compile and run the submission after booting.
  14. mkfifo /tmp/guest_output
  15. Open a seperate terminal and start listening for guest output:

    dd if=/tmp/guest_output bs=1

  16. In another terminal:

    qemu-system-i386 -kernel vmlinuz-3.5.0-27-generic -initrd root.bin -monitor stdio -nographic -serial pipe:/tmp/guestoutput (I just used the Ubuntu kernel here, but many kernels will work)

  17. When the guest output shows "READY", you can send keys to the VM from the qemu prompt. For example, to test this assignment, you could do

    (qemu) sendkey 1
    (qemu) sendkey 4
    (qemu) sendkey ret
    (qemu) sendkey 1
    (qemu) sendkey 0
    (qemu) sendkey ret
    (qemu) sendkey minus
    (qemu) sendkey 1
    (qemu) sendkey ret
  18. Now Average = 12.000000 should appear on the guest output pipe. If it doesn't, the student failed.

  19. Quit qemu: quit

A program passing the test is here: http://stackoverflow.com/a/14424295/309483. Just use tcclib.h instead of stdio.h.

share|improve this answer
add comment

Your Answer


