rustbox

rustbox is a secure process isolation system for competitive programming judges, inspired by IOI Isolate. It provides kernel-enforced sandboxing for untrusted code execution with deterministic resource enforcement and evidence-backed verdict provenance.

Built for anyone running code from strangers on the internet - online judges, code playgrounds, interview platforms, educational tools.

What it does

• Runs Python, C++, Java, JavaScript, and TypeScript in isolated sandboxes
• Enforces CPU time, wall time, memory, and process limits via the kernel (not userspace polling)
• Classifies verdicts (AC, TLE, MLE, RE, SIG) from kernel evidence, not guesswork
• Exposes a REST API with async polling, sync ?wait=true, and webhook delivery
• Ships as a 2.8MB static binary. No Docker, no VMs, no JVM dependency.

How it’s different

	rustbox	Judge0	Isolate (IOI)
Isolation	8 kernel layers	Docker container	cgroups + mount
Compile-time safety	Typestate chain	None	None
Verdict provenance	Kernel evidence bundle	Exit code heuristics	Exit code heuristics
Webhook support	Standard Webhooks + HMAC	No	No
Sync mode	?wait=true	No	No
Binary size	2.8MB	Docker image (~1GB)	~200KB (C)
Setup	cargo build	Docker Compose + Redis + PostgreSQL	make install

Security model at a glance

Layer	Primitive	What it prevents
1	PID namespace	Seeing host processes
2	Mount namespace + chroot	Accessing host filesystem
3	Network namespace	Network access
4	Cgroups v1/v2	Memory bombs, fork bombs, CPU hogging
5	Seccomp-BPF	Dangerous syscalls (ptrace, mount, bpf)
6	Capability drop	Privilege escalation
7	Credential drop	Running as root
8	NO_NEW_PRIVS	Regaining privileges via setuid

Design Note

Most sandboxing tools bolt security on as an afterthought. rustbox starts from the kernel and works up. The typestate chain makes it a compiler error to run code without applying all 8 layers first. See Architecture for the full story.

---

Installation

cargo build --release

Three binaries, same codebase:

• target/release/judge - judge-focused commands (recommended)
• target/release/isolate - sandbox-only commands
• target/release/rustbox - accepts all commands

System requirements

• Linux with cgroups v2 (or v1 fallback)
• Python 3, g++, OpenJDK 21 for the respective languages
• Root access for strict mode (permissive works without it)

judge check-deps --verbose

Your first execution

No root needed. Start with permissive mode.

# Python
judge execute-code --permissive --language python --code 'print(2 ** 10)'

# C++
judge execute-code --permissive --language cpp --code '#include<iostream>
int main(){std::cout<<42<<std::endl;}'

# Java
judge execute-code --permissive --language java --code 'public class Main {
    public static void main(String[] args) {
        System.out.println(42);
    }
}'

The output is a JSON verdict with stdout, stderr, timing, memory usage, and exit code.

Permissive vs Strict

	Permissive	Strict
Needs root	No	Yes
Namespaces	Skipped	PID + mount + network
Cgroups	Best-effort	Enforced
Seccomp	Applied	Applied
Credential drop	Skipped (can’t without root)	Enforced
Use case	Development, CI	Production

Design Note

Permissive mode isn’t “insecure mode”. It still applies seccomp filters, rlimits, and whatever controls it can without root. It gracefully degrades instead of failing. This lets you develop and test without sudo while strict mode guarantees the full chain in production.

Strict mode

sudo judge execute-code --strict --language python --code 'print(1)'

Strict mode fails closed. If any security control can’t be applied, the execution is rejected outright. There’s no “try anyway” path.