Hello,
I am in the process of making an Online Judge, a program that uploads a program and checks if it is correct by compiling and executing the code. I would like to remove the dangerous portions of it that may allow crashing of the system or damaging it. I have so far been able to limit the memory usage and the runtime. I need to implement removal of the malevolent code in the supported languages (C,C++ and Java). So far this is what I have been using:


shell_exec("grep -iv system $tmpf > $sol; rm -f $tmpf");
shell_exec("mv $sol $tmpf");
shell_exec("grep -iv Runtime.getRuntime...exec $tmpf > $sol; rm -f tmpf");
shell_exec("cat $sol");

Is there something else that I am missing?

TIA,
-S

- From a coding standards point of view you already violated one of the basic rules that says not to trust user input. That rule should lead to the fundamental decision to reject instead of trying to "correct" things. If correcting things was or is your default MO I would suggest you track back any important decisions you made regarding this topic and review those again. Thinking for the user, correcting, guessing is just not "the way". On the other hand, if you can not reject things then you should focus on expendability IMHO.
- From a security point of view try on the "that what is not explicitly allowed, is denied" mantra for size. It should point you to making certain you can isolate, mitigate and audit events. Sure you should properly harden your host system, but in your case I would also suggest any form of containment by virtualisation the VMware or QEmu way. Chrooting or using a dedicated machine won't do since all ops target the host system. Since your can get away with a light VM guest and "saved state", losing your VM should be relatively painless and you should be able to restore your pristine env in a matter of seconds.
- From an efficiency point of view whitelisting has a way better cost/result ratio over blacklisting. Anyone who uses any blacklisting schemes is aware of (the impact of) detection errors and the amount of administrative updating necessary, if you dig what I mean.
Just my thoughts on the matter.

What distro are you using because it may have SELinux? I only know a small bit about Security Enhanced Linux(SELinux), but this sounds like a job it would be good for. From what I know, SELinux can implement fine grained access permissions to specific processes/programs.

Please don't ask me how to use it though because I just don't know, lol. I use SUSE which uses appArmor for that type of thing.

Good Luck

If you don't know, then what's the use of giving "advice"?

You ever heard of a brainstorm? It's when people work together to try and figure something out. People share their knowledge or ideas about something (however little the idea/knowledge may be) and it sparks discussion that may lead to an 'answer' or 'solution'. I should have posed a question afterwards such as "Maybe someone else knows?" etc, but I didn't, SORRY. Either way, if it solves the problem or not, then at least people have a little knowledge of it now so that in the future it may help them solve a problem faster/better.


So, IF ANYONE HAS ANY ADVANCED KNOWLEDGE OF SELINUX, PLEASE POST HERE AND LET US KNOW IF IT CAN SOLVE SINEDIE'S PROBLEM. Thank you.

I agree with unSpawn, running untrusted code inside a VM is the best way to handle it. As an additional precaution, don't advertise that the code will be executed in a VM either, that way attackers are missing a key piece of knowledge they would need to defeat your protections scheme. Security by obscurity shouldn't be relied on, but in this case it buys you a little extra time.

As for the second suggestion... an infinite number of monkeys on an infinite number of typewriters may eventually produce the complete works of Shakespeare, but I haven't head of anyone who actually thought it was a good idea to try it, due to the low probability of success. I'll leave it as an exercise to the reader to draw the analogy to an infinite number of people who don't know an answer about something...

The virtual machines are probably the easiest way. I know at least VMWare can take snapshots that can be restored pretty quickly. So you could take a snapshot of a clean image and save it, and then run each program restoring to the snapshot after every run.

I found an FAQ on SELinux and it looks like it can bar programs from doing any harm to a system.

Check out faq # 2 and 3

A lot of people say it's really good but is hard/complex to set up. It may be overkill for what you're looking for, but if the virtual machines don't work for some reason it may be a possible alternative. I know red hat and Fedora have it installed by default and some other distro's offer it as downloadable packages.

There's no need to talk back like I'm attacking you or apologise. Since you're relatively new at LQ maybe you have not noticed yet that LQ is not like other fora and that the Linux Security forum is not like other security fora. In this forum we deal with all sorts of security questions ranging from "simple" cases like access restrictions to full-blown incident handling of breaches of security. LQ members have come to trust the members that frequent this forum for dealing with problems a certain way. Those who I consider helping out "the right way" all share the same specs: being helpful, having a stuctured approach, precise, factual and quick to help out by sharing conceptual and practical knowledge of things. In short: quality over quantity. You are strongly invited to post, I know you meant well, but please be aware of the implications for the OP and us when posting a suggestion as an answer instead of a suggestion.
See? I'm not chiding you, just hoping to make you think...


While most web logs are quick to offer easy digestible and higly opinionated sound bites for instant satisfaction, most useful security knowledge is not amassed overnight. It takes studying and practicing. SE Linux works by applying a policy. Policies need to be written and "installed". Out of the box SE Linux, when applied with the default "targeted" policy, comes with a lot of domains that *can* be applied (ranging from apps like acct to services like Zebra) but are not. They run as unconfined_t: think hard on the outside, chewy on the inside. Try if you will to paint a picture of what is necessary to confine the OP's "service" to a domain: see for example Dan Walsh' work on Fedora's Xguest. Now try to imagine that next to that you need to make allowances for using a compiler and running the resultant binary and you would see that the amount of work involved (developing such a policy, testing and finetuning to arrive at the point where you can give solid guarantees with respect to what in essence is a case of deliberately running hostile code) is not trivial. Supporting VMware it does, but as far as I know (and I don't know much) SE Linux (or GRSecurity, TOMOYO or AppArmor) is not an alternative for using virtual machines in the way the OP could.

Thanks unSpawn, CRC123 and chort for your replies.

Well, the s/w is required to run the programs by specification of online verification, TINA factor! So the correction follows.

I am planning to shift to SELinux which is currently disabled on the CentOS 5.1 (i386) that is being used. I somehow still need to make sure that none of the scripts spill anything out of the directory..., my only is that the location of temporary file upon uploading may not be allowed by the restrictions.

The following are the steps I have taken so far.

1. Very few inputs taken (like question no., user-id, passwd, etc). All of them are validated (excluding passwd) for the expected data type.

2. Password is never sent on shell_exec.

3. The compilation, run and verification is done by a shell script. The following are the extra precautions incorporated in the shell script:
4. Malicious code removal is now done by the following snippet from the PHP itself.
I would be happy if any further suggestions are given. I think virtual machine would be an overkill for such a small purpose (!). Is unionfs+chroot a better solution? ( http://librenix.com/?inode=10795 )

TIA,
-S

Excellent. If you remain adamant your methods and scope of "malicious code removal" beat virtualisation then testing the system for all sorts of "simple" bad coding, obfuscation, network access, heap or buffer fun should prove it. I wish you wisdom and good luck. $deities know you'll need it.

Point taken. I would like to know your views on unionfs+chroot though.

Thanks,
-S

In relation to what please? What threaths should that combo mitigate? You could always test it yourself with the things I mentioned in my previous post and find out for yourself if that combination works for you. BTW, do you by any chance have a list of threaths you expect? And did you ever try to contact other Online Judge developers for nfo?

Simply grep'ing for strings in system calls is going to cause a lot of false-positives.

Also, it's been a long time since I took C/C++, but I'm fairly certain it would be possible to write a program that would in turn construct a second program using obfuscated characters (could be done easily enough by simply using the integer value for ASCII characters) and then call the second program to run malicious code, thus entirely escaping your sanitization script.

Not much expecting threats, really; nor have consulted the other developers. Will be using for the course students who login with their LDAP password. So I am not sure if that would invite them to try being smart at the expense of action..., therein lies a bit of complacency. I have taken backup of everything that apache can modify and going to use SELinux, so not expecting too much of trouble either. Also going to login the details of the submissions through another machine with PHP script upon successful authentication.

But this can't be reason for being complacent, and I want to block at least the most obvious attacks. I am planning to rename the compiler executable (g++ & c++) to something else so that even if they obtain a shell they can't compile. I can take b/u of the content on a partition during the contest time and make it read-only, just in case I may need it later.

As of using obfuscated code, I think as long as they are not going to find the compiler, it will make no difference. Hence I am more concerned about disabling them from reading or writing files..., afterall it is not required for the participants. A simple i/p, o/p redirection will do.

I tried making a few of them work (but failed/dissatisfied), most notably PC2 by CSUS and domjudge but both come with only the judging part. I would like the s/w to show the questions as well and not just ask for answers! It took me lesser time to come up with something usable for practical purposes (which I did in a few days). But I am wary of some security aspects, so been consulting you experts.

I am planning to spawn this into a full-fledged s/w for general purpose so I would like to have more security scenarios that need to be taken care of.

The point still is practicing safe hex: inside a chroot you'll be still executing the build process and whatever got built in the memory of the host system. Even if you assert your audience to be somewhat less malicious than the average cracker you would still have to deal with recovering from for example "benign" memory corruption due to ahhh, "mistakes". And running a default SE Linux "targeted" policy alone isn't going to cut it (unconfined_t, post #8) so I really, really would like you to see that virtualisation is a relatively safe, low-cost, efficient, performant "buffer". Period. If you can't then at least check out the GRSecurity, PAX and RBAC trinity and don't forget to check with 'paxtest' once you've set up shop (see paxtest.*/results/Gentoo.blackhat for what it should look like).