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.

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==0.1.0
    devices:
      - /dev/kvm
    cap_add:
      - NET_ADMIN
    group_add:
      - "994"

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

Then check both the device and the capability are there from inside the container:

$ docker compose exec app test -r /dev/kvm -a -w /dev/kvm && echo ok
$ docker compose exec app python3 -c "print(bool(int(open('/proc/self/status').read().split('CapEff:')[1].split()[0], 16) >> 12 & 1))"
True

The second command is the plugin's own check, run by hand. False means the sandbox cannot filter the guest network: see Without NET_ADMIN.

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

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) -> 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) -> 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.

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.

Without NET_ADMIN¶

Egress filtering is done by firewall rules the sandbox programs itself. On a host that does not let it, microsandbox reports the policy as applied and leaves the guest unfiltered. Rather than trust that, the plugin checks for the capability before every boot:

A refusal does not reach the player as one, so it reads as a broken challenge rather than a misconfigured host:

• Script checker marks the answer wrong, and logs script.checker failed.
• Code runner answers the player with a server error.

The plugin says so at startup instead, once per worker. Check for it after deploying, and again after any change to the container's capabilities:

$ docker compose logs app | grep sandbox.network
sandbox.network host has no CAP_NET_ADMIN: microVM egress cannot be filtered, so ... only 'all' will boot

The capability is re-read on every boot, not cached, so a container that gains or loses it is honoured from the next submission on.

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.