I need to run an untrusted program that may be attempting to crash my system or use it for malicious purposes. I have to pipe input into standard in for the program and read any standard out that it sends. What I can think of, is I need to prevent the program from creating any files, reading any files but a few necessary ones, opening any network connections, or hanging the system itself. I also need to batch run a series of these programs. I've looked into a few sandbox options but they're all 'alpha' or unsupported. I've also thought about running the code inside a virtual machine, but I would need a quick way to batch run a series of these programs and I don't know how to do that with a virtual machine without one program affecting the running of the next.

Anyone got any suggestions? Anyone done something like this before?

Thanks in advance.

I need to run an untrusted program that may be attempting to crash my system
Interesting. Any details?


I've looked into a few sandbox options but they're all 'alpha' or unsupported.
Which ones?


I would need a quick way to batch run a series of these programs
So that kinda boils down to security vs speed.
Which one are you willing to sacrifice?..


Anyone got any suggestions?
Load a LiveCD on a spare box.

A web page (the server) will accept unknown C++ source code uploaded by untrusted users, compiling the code, evaluating the result, and sending a status report back to the user.


http://sandbox.sourceforge.net/

http://www.ussg.iu.edu/hypermail/lin...06.1/0373.html
That thread pointed me to ptrace, but I was hoping for something more wrapped up and ready to go. I don't trust myself to think of all the hooks needed to check for. My area of programming is more in Java than c.

I also found
http://user-mode-linux.sourceforge.net/

I could use UML or even qemu to run the code and figure out some hack to get input back and forth, but I would have to restore the VM's state after each run and I'm afraid that may take too much time.

It doesn't have to run that fast. I even want to time out the process after a few seconds(10-15). I would accept up to a minute of down time between runs. Maybe two. Anything more than that is pushing it.


I need to automate the process. Users are uploading the code from a web page.

I actually have a working model in Java, but it uses Java's built in sandbox. I'm hoping to expand to c++.

Question sounds like the answer to "what is it good for" from the SELinux FAQ. Personally, it's the first thing I disable on a new installation (some might even say SELinux itself comes from an untrustworthy source) but for the .0001% of users with your specific needs I suppose it might be useful. I'd rather drill my own teeth than have to configure it, but to each their own (inelegant kludge of a solution.)

http://www.nsa.gov/selinux/info/faq.cfm

A web page (the server) will accept unknown C++ source code uploaded by untrusted users, compiling the code, evaluating the result, and sending a status report back to the user.
OK. So basically you're saying "fsck up my box". Cool. Still, if you don't know what to expect I definately would run the whole build and test sequence on a separate box in some form of virtualisation cage. If you really can not afford to have a separate box running the whole virtualisation process on the webserver itself hightens risks, so you'll have to look at how you can balance it. Anything that can ease the trade-off, like possible restrictions you can place on uploaded code in any way will help. Wrt to the virtualisation itself you'll want to use a strict separated environment with a separate (possibly hardened and modified) kernel and a minimum of libs/apps and no network access except for exchanging code and reports with the (definately hardened) host system. I would strongly advice against you running code in the same kernel you run the host OS in. However hardened your system is, that's asking for problems. A userland environment like for instance Qemu offers should be more suited for the task.


I could use UML or even qemu to run the code and figure out some hack to get input back and forth, but I would have to restore the VM's state after each run and I'm afraid that may take too much time. It doesn't have to run that fast. I even want to time out the process after a few seconds(10-15). I would accept up to a minute of down time between runs. Maybe two. Anything more than that is pushing it. I need to automate the process. Users are uploading the code from a web page.
Qemu allows you to restore snapshots and VM states. Add a custom image (smaller memory footprint) and possibly you can run say three slots for which you can queue code.

The problem with this scenario is that you just can't tell what a program might try to do .. even if it is functioning correctly.

A simpler, more innocuous example of the same problem is, "test this program to see if it will segfault."

So, what you have to do is to limit what it is allowed to do, by means of "hardening" and the intelligent use of non-root userids.

The problem with this scenario is that you just can't tell what a program might try to do
Which scenario?

You might look into 'pbuilder'. Martin Krafft goes into it in great detail in his book, The Debian System, but I haven't gotten that far. I have encountered a few references to it, and it seems to be a way to build a virtual sandbox, cleaning up after itself after a program is executed.

I understand you there. The programs I'm running should be simple and nice, so if they do anything really deep into the kernel or something strange, they're probably not doing what I want and should just stop.

Pbuilder looks like a chroot environment. As I understand it, chroot sets up another / inside a directory. With this, will I be able to prevent hardware access or network access, as well as limit file write size?

I don't know. Like I said, I haven't gotten that far in the book. But, as I understand what you want to do, there is not going to be a quick and easy solution. I assume you saw the pbuilder manual,
http://www.netfort.gr.jp/~dancer/sof...ilder-doc.html