13

I am trying to run a program compiled from C code from an unknown source. I want to make sure that the program does not harm my system in anyway. Like for instance, the program might have soemthing like system("rm -rf /") in the source, which is un-detectable, unless the code is thoroughly examined.

I thought of the following 2 ways

  1. Run it inside a VM like VMWare
  2. Build a windows exe on linux and run on wine

Both are not very elegant solutions and I cannot automate them. and also, in case of 1, it can harm the VM.

Any help would be appreciated.

I want to run the program in what we can call a "sandbox".

arbithero
  • 426
  • 3
  • 13
  • 1
    I've thought about chroot, but it does not stop fork bombs and other system call problems. Thanks – arbithero Oct 04 '10 at 23:14
  • Similar Qs on sandboxing/jailing processes in Linux or Unix: * http://unix.stackexchange.com/q/6433/4319 * http://stackoverflow.com/q/4410447/94687 * http://stackoverflow.com/q/4249063/94687 * http://stackoverflow.com/q/1019707/94687 – imz -- Ivan Zakharyaschev Mar 13 '11 at 13:36
  • 1
    wine has absolutely no value in containing the executable. Run a wine executable as root and you can wipe your system – sehe Nov 01 '11 at 22:18

9 Answers9

6

Check out seccomp. It was designed for this use case.

florin
  • 13,986
  • 6
  • 46
  • 47
5

I wrote an overview of sandboxing methods on Linux (archived) here. You are best off using Linux containers (lxc) or selinux, in my view. You could use a virtualisation solution and automate it, but it is a lot more effort.

lxc will isolate your processes, filesystem and network, and you can set resource limits on the container. There are still risks of a kernel attack, but they are much reduced.

Yushin Washio
  • 675
  • 8
  • 12
Justin Cormack
  • 1,226
  • 12
  • 8
4

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

2

You can use something like schroot and chroot the program, but anything of sufficient nastiness will bust out of that.

You best bet is probably a virtual machine (vmware or virtualbox) and taking a snapshot before compiling and running the program. That way you can roll back if something goes horribly wrong.

Dave
  • 416
  • 2
  • 5
  • In fact, you should just roll it back after testing anyway, because you might not have noticed what went horribly wrong. – caf Oct 05 '10 at 01:13
  • @caf True, if it's untrusted then it's untrusted. Don't muck about and rollback anyway. – Dave Oct 05 '10 at 12:25
  • Virtual machines are not exactly a secure environment either, if the program being executed knows it's in one. – Jonathan Oct 06 '10 at 15:09
1

Create an user that has write access only to non-critical directories. Run the program as that user. If you are also interested in privacy, consider also restricting its read rights.

Flavius Stef
  • 13,740
  • 2
  • 26
  • 22
1

The wikipedia page for chroot may be a good start. It describes chroot and also provides links to a few, more thorough alternatives.

vanza
  • 9,715
  • 2
  • 31
  • 34
1

chroot is one possibility if you want to isolate it from everything else but still have an environment for it to run in.

http://en.wikipedia.org/wiki/chroot

https://help.ubuntu.com/community/BasicChroot

wkl
  • 77,184
  • 16
  • 165
  • 176
0

Run it on a non-networked computer that you will re-image once it's done. There is no safe way to run it on a machine and continue to trust that machine afterwards.

Jonathan
  • 13,354
  • 4
  • 36
  • 32
0

In addition of other answers, using strace or ltrace may help you to understand what the program is doing.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547