Next Previous Contents

7. Security

This judging system was developed with security as one of the main goals in mind. To implement this rigorously in various aspects (restricting team access to others and the internet, restricting access to the submitted programs on the domjudge systems, etc...) requires root privileges to different parts of the whole contest environment. Also, security measures might depend on the environment. Therefore we have decided not to implement security measures which are not directly related to the judging system itself. We do have some suggestions on how you can setup external security.

7.1 Considerations

Security considerations for a programming contest are a bit different from those in normal conditions: normally users only have to be protected from deliberately harming each other. During a contest we also have to restrict users from cooperatively communicating, accessing restricted resources (like the internet) and restrict user programs running on judgehosts.

We expect that chances are small that people are trying to cheat during a programming contest: you have to hack the system and make use of that within very limited time. And you have to not get caught and disqualified afterwards. Therefore passive security measures of warning people of the consequences and only check (or probe) things might be enough.

However we wanted the system to be as secure as possible within reason. Furthermore this software is open source, so users can try to find weak spots before the contest.

7.2 Internal security

Internal security of the system relies on users not being able to get to any vital data (jury input/output and users' solutions). Data is stored in two places: in files on the DOMjudge system account and in the SQL database.

Files should be protected by restricting permission to the relevant directories.

Note: the database password is stored in etc/dbpasswords.secret. This file has to be non-readable to teams, but has to be readable to the web server to let the jury web interface work. A solution is to make it readable to a special group the web server runs as. This is done when using the default configuration and installation method and when make install-{domserver,judgehost} is run as root. The webserver group can be set with configure --with-webserver-group=GROUP; by default it is tried to be determined from groups available on the system, e.g. www-data or apache.

Judgehosts and the domserver communicate with each other over HTTP. Also all parties accessing the domserver web interface obviously use this protocol. We advise to setup HTTPS so interactions between domserver, judgehosts and teams are all protected. If you need to use a self-signed certificate, you can consider to install it on the team workstations beforehand to minimize hassle.

When using IP address authentication, one has to be careful that teams are not able to spoof their IP (for which they normally need root/administrator privileges), as they would then be able to view other teams' submission info (not their code) and clarifications and submit as that team. Note: This means that care has to be taken e.g. that teams cannot simply login onto one another's computer and spoof their identity.

Problem texts can be uploaded to DOMjudge. No filtering is performed there, so make sure they are from trusted sources to, in the case of HTML, prevent cross site scripting code to be injected.

7.3 Root privileges

A difficult issue is the securing of submitted programs run by the jury. We do not have any control over these sources and do not want to rely on checking them manually or filtering on things like system calls (which can be obscured and are different per language).

Therefore we decided to tackle this issue by running these programs in a environment as restrictive as possible. This is done by setting up a minimal chroot environment with Linux cgroup process control. For this, root privileges on the judgehosts and statically compiled programs are needed. By also limiting all kinds of system resources (memory, processes, time, unprivileged user and network access) we protect the system from programs which try to hack or could crash the system.

7.4 File system privileges

Of course you must make sure that the file system privileges are set such that there's no unauthorised access to sensitive data, like submitted solutions or passwords. This is quite system dependent. At least <judgehost_judgedir> should not be readable by other users than DOMjudge.

Permissions for the web server

The default installation sets permissions correctly for the web server user (commonly www-data or apache). The following information is for those who want to verify the setup or make modifications to the settings.

Care should be taken with the etc directory: the domserver-{config,static}.php, dbpasswords.secret and restapi.secret files should all be readable, but dbpasswords.secret and restapi.secret should not be readable by anyone else. This can be done for example by setting the etc directory to owner:group <DOMjudge account>:<Web server group> and permissions drwxr-x---, denying users other than yourself and the web server group access to the configuration and password files.

If you want the web server to also store incoming submission sources on the file system (next to the database), then <domserver_submitdir> must be writable for the web server, see also storage of submissions.

7.5 External security

The following security issues are not handled by DOMjudge, but left to the administrator to set up.

Network traffic between team computers, domserver and the internet should be limited to what is allowed. Possible ways of enforcing this might be: monitor traffic, modify firewall rules on team computers or (what we implemented with great satisfaction) put all team computers behind a firewalling router.

Solutions are run within a restricted (chroot/cgroup) environment on the judgehosts which restricts outgoing network access.

Next Previous Contents