Sandbox¶

nexctf-sandbox adds two solution types that run code in a throwaway microVM: one where you write the code that grades the answer, one where the player writes the code being graded.

Both appear in the solution picker of a question once the plugin is installed, next to Match and Regex.

Requirements¶

The sandbox boots a real virtual machine per submission, which the host has to allow.

Nothing else: no added capability and no root. Network access is enforced by microsandbox's own network stack, not by firewall rules on the host.

Installing¶

The container runs as a non-root user, so passing the device in is not enough on its own: it also needs the group that owns /dev/kvm on the host.

$ stat -c '%g' /dev/kvm
994

Use that number, which differs from host to host:

services:
  app:
    environment:
      NEXCTF_PLUGINS: nexctf-sandbox==1.0.0
    devices:
      - /dev/kvm
    group_add:
      - "994"

$ docker compose up -d --force-recreate app

Then check the device is usable from inside the container:

$ docker compose exec app test -r /dev/kvm -a -w /dev/kvm && echo ok
ok

See Installing plugins for private indexes, custom CAs and removal.

Compatibility¶

The plugin declares the NexCTF versions it supports, so it will not install against another one: upgrade NexCTF and the plugin together, in the same container recreation.

Script checker¶

The answer is passed to a function you write, and whatever it returns decides the verdict.

def check(answer: str, team_id: str | None, team_fields: dict) -> bool:
    return answer.strip().lower() == "42"

answer is exactly what the player submitted. team_id is the submitting player's team, or None when they are not in one. Use it for per-team flags:

import hashlib

def check(answer: str, team_id: str | None, team_fields: dict) -> bool:
    expected = hashlib.sha256(f"s3cr3t{team_id}".encode()).hexdigest()[:16]
    return answer.strip() == f"NEX{{{expected}}}"

Anything the function prints is ignored, and an exception inside it counts as a wrong answer rather than an error the player sees, and so does a syntax error. A broken checker therefore rejects every player silently: submit a known-good answer yourself once after writing one. The checker code is admin-only, and never part of what the player-facing API returns.

Team custom fields¶

team_fields holds the submitting team's custom fields, keyed by field name. Private fields are included: the checker is admin code, and a per-team seed or secret is what the argument is for.

import hashlib

def check(answer: str, team_id: str | None, team_fields: dict) -> bool:
    seed = team_fields.get("seed", "")
    expected = hashlib.sha256(seed.encode()).hexdigest()[:16]
    return answer.strip() == f"NEX{{{expected}}}"

A field the team left empty is missing from the dictionary rather than set to None, so read it with .get(). A value stored before its field changed type, and no longer parsing as the new one, is passed as the raw string. A player with no team gets an empty dictionary.

A new checker starts from a template that lists the team custom fields defined on the instance, with their types, as a comment. Fields added later do not update an existing checker.

team_fields is optional. A checker declared without it, such as check(answer, team_id), keeps working unchanged: the argument is only passed to a function that can take it.

Code runner¶

The player submits code, the plugin runs it once per test case and compares what it printed.

The answer is accepted only when every test case passes. A test case passes when the program exits with status 0 and its standard output equals the expected output after stripping leading and trailing whitespace. A crash or a non-zero exit fails the case, whatever the program printed. Standard error is ignored.

A solution with no test cases rejects everything, so add at least one.

Settings¶

Admin → Plugins → Sandbox holds the microVM budget. It applies to every sandbox on the instance: none of it is set per challenge, where the only knob is the solution's own timeout.

Max concurrent microVMs sizes a semaphore built once at startup, so it only takes effect after a restart. Every other setting is read fresh per submission and applies to the next one.

Network access¶

Submitted code has no network at all by default. Opening it up is an instance-wide decision: every sandbox on the instance gets the same policy, for checkers and player code alike.

internet is for a challenge that genuinely has to fetch something: an API, a remote service you host, a package index. It stops deliberately short of all, because the host's network is where Redis and the Postgres holding your flags sit.

Limits¶

Fixed on every sandbox, whatever the settings say:

Submissions beyond the concurrency limit wait for a free slot rather than failing. A microVM takes about a second to boot, which is the floor on how fast one of these solutions can answer.

Timeouts¶

Code that runs past its timeout is killed. The submission is recorded as wrong, so the player sees a wrong answer and it counts towards malus. A solution.timeout entry is also written to the Events log with the solution and team involved.

Those events are the signal that a challenge is misconfigured: a checker doing real work on a slow instance, or a timeout set too tight for the algorithm the challenge asks for. Watch the log after opening a code challenge.