Run an Untrusted C Program in a Sandbox in Linux That Prevents It from Opening Files, Forking, etc.

Run an untrusted C program in a sandbox in Linux that prevents it from opening files, forking, etc.?

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.

EDIT:

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.

EDIT 2:

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.

How can I run an untrusted code in a sandbox in Windows?

I realize this question is an old one, however it never really got a full answer. When this question was asked, Windows did not have as many isolation options available to it. However there is been some improvement.

The now goto answer for this is to either use use Docker or Hyper V containers/VM.

But the pre-Windows 10 era, answer was to manipulate the process isolation that came around windows vista/7 and use a separate user/application account.

Process Abilities:

You could manipulate the programs Integrate level and run with a restricted/unique user so reach is limited (group policy can further limit user).

Network access:

• Limit using a firewall that blocks outbound connections.

File access:

The NTFS file system has one of the most configurable file systems around,if you are running the process as a distinct user, you can craft an ACL policy to significantly limits the process's file access.

Source:

Finally if you have access to the source-code, you can likely remove or modify problem parts.

How few a files does it take to load a program on Linux?

You don't need anything except the executable to run a statically-linked hello world. You will, of course, need a lot more to compile it.

You can test this fairly easily, I did so with the following trivial C code:

#include <stdio.h>
int main() {
    puts("Hello, world\n");
    return 0;
}

compile it with gcc -static. Then make a new directory (I called it "chroot-dir"), move the output ("hello") into it. So the only file in the chroot is now the executable. Then run chroot chroot-dir ./hello, and you'll get Hello, world.

Note that there are some things that can not be compiled statically. For example, if your program does authentication (through PAM), PAM modules are always loaded dynamically. Also note that various files in /etc are needed for certain calls; any of the getpw* and getgr* functions, the domain name resolution functions, etc. will require nsswitch.conf (and some shared objects, and maybe more config files, and sometimes even more executables, depending on the lookup methods configured.) /etc/hosts, /etc/services, and /etc/protocols will probably be quite useful for any networking.

One easy way to figure out what files a program uses is to run it under strace. You must trust the program first, of course.

What is the safest way to run an executable on Linux?

Geordi uses a combination of chroot and interception of syscalls to compile and then sandbox arbitrary code.

Sandboxing in Linux

Along with the other sugestions you might find this useful.

http://www.eelis.net/geordi/

This is from http://codepad.org/about, codepad.org's about page.

---

Related Topics