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 jury computers, 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.
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 jury computers.
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.
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: files on the jury account and in the SQL database. Files should be protected by preventing permission to the relevant directories. Furthermore, the (jury) web interface offers a view and allows modification of a lot of sensitive data.
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: database passwords are 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
.
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, authentication data is sent via HTTP, so we strongly advise to use HTTPS in that case.
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 judging computers 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.
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 JUDGEDIR
should not be readable by other users
than DOMjudge.
Make sure that the web server serving the DOMjudge web interface pages
has correct permissions to the www, lib, etc
directory trees. The www
and lib
trees can safely
set to be readable and accessible. 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 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.
The following security issues are not handled by DOMjudge, but left to the administrator to set up.
Network traffic between team- and jury-computers 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 judge computers. 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 judge computers. On Linux, this can be accomplished by modifying the iptables, adding a rule like:
iptables -I OUTPUT -o <network_interface> -m owner --uid-owner <testuser_uid> -j REJECT