Print this chapterPrint this chapter

CodeRunner Documentation (V2.4.2)

2.4 Sandbox Configuration

You next need to decide what particular sandbox or sandboxes you wish to use for running the student-submitted jobs. You can configure sandboxes via the Moodle administrator settings for the CodeRunner plugin, accessed via

Site administration  Plugins  Question types  CodeRunner.

Available sandboxes are as follows:

  1. The JobeSandbox.

    This is the only sandbox enabled by default. It makes use of a separate server, developed for use by CodeRunner, called Jobe. As explained at the end of the section on installing CodeRunner from scratch, the initial configuration uses the Jobe server at the University of Canterbury. This is not suitable for production use. Please switch to using your own Jobe server as soon as possible.

    Follow the instructions at https://github.com/trampgeek/jobe to build a Jobe server, then use the Moodle administrator interface for the CodeRunner plug-in to define the Jobe host name and perhaps port number. Depending on how you've chosen to configure your Jobe server, you may also need to supply an API-Key through the same interface. If you intend running unit tests you will also need to edit tests/config.php to set the correct URL for the Jobe server.

    Assuming you have built Jobe on a separate server, the JobeSandbox fully isolates student code from the Moodle server. However, Jobe can be installed on the Moodle server itself, rather than on a completely different machine. This works fine and is a bit more secure than using the Runguard Sandbox but is much less secure than running Jobe on a completely separate machine. If a student program manages to break out of the sandbox when it's running on a separate machine, the worst it can do is bring the sandbox server down, whereas a security breach on the Moodle server could be used to hack into the Moodle database, which contains student run results and marks. That said, our Computer Science department used the even less secure Runguard Sandbox for some years without any ill effects; Moodle keeps extensive logs of all activities, so a student deliberately breaching security is taking a huge risk.

  2. The Liu sandbox

    If you wish to run only C or C++ jobs and wish to avoid the complication of setting up and maintaining a separate Jobe server, you might wish to consider the Liu sandbox, which can be installed on the Moodle server itself. It runs all code with ptrace, and disallows any system call that might allow escape from the sandbox, including most file i/o. The job to be run is compiled and built as a static load module before being passed to the sandbox. While the possibility of an exploit can never be absolutely disregarded, the Liu sandbox does offer a high level of protection.

    The Liu sandbox can be obtained from here. Both the binary and the Python2 interface need to be installed. Note that CodeRunner does not currently work with the Python3 interface to the sandbox.

    The easiest way to install the Liu sandbox is by downloading appropriate .debs or .rpms of both libsandbox and pysandbox (for Python version 2). Note that the pysandbox download must be the one appropriate to the installed version of Python2 (currently typically 2.6 on RHEL systems or 2.7 on most other flavours of Linux).

    The Liu sandbox requires that C programs be compiled and built using static versions of the libraries rather than the usual dynamically-loaded libraries. Many versions of the C development packages no longer include static libraries by default, so you may need to download these separately. Before trying to use the Liu sandbox, check you can build a statically linked executable with a command like

    gcc -Wall -Werror -std=c99 -static src.c -lm
    

    It is also possible to use the Liu sandbox to run other languages, but it must be configured to allow any extra system calls required by those languages and also to access those parts of the file system that the language expects to access. These are many and varied so this approach is not recommended.

  3. The RunguardSandbox.

    [Note: The RunguardSandbox is no longer being maintained and will probably be deleted from CodeRunner in the near future.] The RunguardSandbox is the easiest one to use, as it requires no extra resources apart from whatever languages (Python3, Java etc) you wish to use in CodeRunner questions. However, the RunguardSandbox is also the least secure. It runs student submitted jobs on the Moodle server itself, so most certainly should not be used on an institutional Moodle server, but it is reasonably safe if a special-purpose quiz server is being used, assuming that server requires student login. Our own quiz server at the University of Canterbury made extensive use of the RunguardSandbox for two years with no known security failures. You should be aware that it does not prevent use of system calls like socket that might open connections to other servers behind your firewall and of course it depends on the Unix server being securely set up in the first place.

    The RunguardSandbox uses a program runguard, written by Jaap Eldering as part of the programming contest server DOMJudge. This program enforces various resource limitations, such as on CPU time and memory use, on the student program. It runs the code as the non-privileged user coderunner so student-submitted code can do even less than a student with a Linux account can do (as they can't create files outside the /tmp directory and have severe restrictions on cpu time, threads and memory use).