Question

I’m currently working on the back-end of ACM-like public programming contest system. In such system, any user can submit a code source, which will be compiled and run automatically (which means, no human-eye pre-moderation is performed) in attempt to solve some computational problem.

Back-end is a GNU/Linux dedicated machine, where a user will be created for each contestant, all such users being part of users group. Sources sent by any particular user will be stored at the user’s home directory, then compiled and executed to be verified against various test cases.

What I want is to prohibit usage of Linux system calls for the sources. That’s because problems require platform-independent solutions, while enabling system calls for insecure source is a potential security breach. Such sources may be successfully placed in the FS, even compiled, but never run. I also want to be notified whenever source containing system calls was sent.

By now, I see the following places where such checker may be placed:

• Front-end/pre-compilation analysis – source already checked in the system, but not yet compiled. Simple text checker against system calls names. Platform-dependent, compiler-independent, language-dependent solution.
• Compiler patch – crash GCC (or any other compiler included in the tool-chain) whenever system call is encountered. Platform-dependent, compiler-dependent, language-independent solution (if we place checker “far enough”). Compatibility may also be lost. In fact, I dislike this alternative most.
• Run-time checker – whenever system call is invoked from the process, terminate this process and report. This solution is compiler and language independent, but depends on the platform – I’m OK with that, since I will deploy the back-end on similar platforms in short- and mid-terms.

So the question is: does GNU/Linux provide an opportunity for administrator to prohibit system calls usage for a usergroup, user or particular process? It may be a security policy or a lightweight GNU utility.

I tried to Google, but Google disliked me today.

Answer 1

mode 1 seccomp allows a process to limit itself to exactly four syscalls: read, write, sigreturn, and _exit. This can be used to severely sandbox code, as seccomp-nurse does.

mode 2 seccomp (at the time of writing, found in Ubuntu 12.04 or patch your own kernel) provides more flexibility in filtering syscalls. You can, for example, first set up filters, then exec the program under test. Appropriate use of chroot or unshare can be used to prevent it from re-execing anything else “interesting”.