39 lines
1.3 KiB
Markdown
39 lines
1.3 KiB
Markdown
|
## Execution/Compiliation/Verification Workers
|
||
|
|
||
|
Submitted assignments for C/C++ but also many otehr languages need to be build
|
||
|
or compiled before you can run them. Finally the submitted solutios shall be
|
||
|
verified automatically to some extend.
|
||
|
|
||
|
### Execution of Untrusted Code
|
||
|
|
||
|
The general problem here is to provide a safe environment that jails the
|
||
|
program into a sandbox leaving the rest of the system inpenetrable. This is
|
||
|
considered generally NOT possible in practice as exploits can exist in any
|
||
|
complex systems.
|
||
|
|
||
|
These opportunities to exploit the system are especially given when lower levels
|
||
|
are used. C code generally offers a wider range of possible attacks. Besides
|
||
|
a planned attack on a system, systems may be brought down also by accident.
|
||
|
|
||
|
* DOS of the Test Environment (CPU, RAM, Network..)
|
||
|
* Fork-Bombs
|
||
|
|
||
|
### Mitigation Measures
|
||
|
|
||
|
* Dedicated Hardware on a seperate Network
|
||
|
* Virtual Machines
|
||
|
* Containers (e.g. Docker, LXC)
|
||
|
* Apparmor / SE Linux
|
||
|
* Limit resources (CPU, RAM, Disk, Network)
|
||
|
* lower nice values to keep system responsive
|
||
|
* Filesystem Privileges
|
||
|
* "least privelege"
|
||
|
* cgroups
|
||
|
* chroot - http://www.bpfh.net/simes/computing/chroot-break.html
|
||
|
|
||
|
* only a very reduced tool chain
|
||
|
|
||
|
http://blog.remoteinterview.io/post/89639823776/how-we-used-docker-to-compile-and-run-untrusted
|
||
|
http://hmarr.com/2013/oct/16/codecube-runnable-gists/
|
||
|
|