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 will probably 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. Database access is protected by passwords. The default permissions allow connections from all hosts, so make sure you restrict this appropriately or choose strong enough passwords.

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 which defaults to www-data.

Judgehosts and the domserver communicate with each other through the MySQL protocol. By default, MySQL does not encrypt these connections. Refer to the MySQL manual to configure SSL for the server and enable the option in common-config.php to enable it for client connections; alternatively you can employ an SSH tunnel or ensure in the network setup that these connections are separated from the team network.

The jury web interface is protected by HTTP Authentication. These credentials are essentially sent plain-text, so we advise to setup HTTPS at least for the jury interface, but preferably for all web interfaces. By default the domjudge_jury user will be given full access. You can choose to add more users to the file etc/htpasswd-jury. In etc/domserver-config.php you can add these users to the list DOMJUDGE_ADMINS. Most data-modification functions are restricted to only users in this list. See also the judge manual for some more details.

Secondly, the submitted sources should not be interceptable by other teams (even though that, if these would be sent clear-text, a team would normally need to be root/administrator on their computer to intercept this). This can be accomplished by using HTTPS for the web interface. The Dolstra submission method by default uses SSH to send files over the network.

There are multiple authentication methods for teams, each having its own issues to check for.

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.

When using PHP sessions or LDAP, authentication data is sent via HTTP, so we strongly advise to use HTTPS in that case.

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. 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) we protect the system from programs which try to hack or could crash the system. However, a chroot environment does not restrict network access, so there lies a possible security risk that has to be handled separately.

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). 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 dir: the domserver-{config,static}.php, htpasswd-* and dbpasswords.secret files should all be readable, but dbpasswords.secret and the htpasswd files 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 submission methods.

You should take care not to serve any files over the web that are not under the DOMjudge 'www/' directory, because they might contain sensitive data (e.g. those under etc/). DOMjudge comes with .htaccess files that try to prevent this, but double-check that it's not accessible.

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) environment on the judgehosts. This however does not restrict network access, so a team could try to send in a solution that tries to send input testdata back to them, access the internet, etc... A solution to this problem is to disallow all network traffic for the test user on the judgehosts. On Linux, this can be accomplished by modifying the iptables, adding a rule like:

iptables -I OUTPUT -m owner --uid-owner <testuser_uid> -j REJECT


Next Previous Contents