explaingit

division-36/z-jail

25CAudience · ops devopsComplexity · 3/5Setup · moderate

TLDR

A tiny Linux tool that wraps untrusted programs in seven overlapping security layers, resource limits, filesystem isolation, stripped capabilities, network cut-off, and a strict 15-syscall allowlist, to prevent them from harming the host system.

Mindmap

mindmap
  root((z-jail))
    What it does
      Sandboxes untrusted code
      Seven security layers
      Behavioral verdict engine
    Security Layers
      Resource caps
      Pivot root isolation
      Capability stripping
      Seccomp syscall filter
    Isolation
      No network access
      Separate PID namespace
      Separate hostname
    Use Cases
      CI pipelines
      CTF competition jails
      Code evaluation judges
Click or tap to explore — scroll the page freely

Code map

Detail Auto

An interactive map of this repo's files and how they connect — its source is parsed live in your browser. Click Visualize to build it.

filefunction / class

Things people build with this

USE CASE 1

Wrap untrusted code submissions in a secure sandbox for a competitive programming judge or code evaluation service.

USE CASE 2

Add z-jail to a CI pipeline to safely run build scripts from external contributors without risking host damage.

USE CASE 3

Use z-jail as a lightweight jail for capture-the-flag competitions where contestants run exploits in a controlled environment.

Tech stack

CLinuxseccomp-BPFMake

Getting it running

Difficulty · moderate Time to first run · 30min

Requires Linux 5.4 or newer, builds with a single make command but understanding seccomp and Linux namespaces helps when configuring allowed syscalls.

The explanation does not mention a license for this project.

In plain English

Z-Jail is a lightweight tool that creates a secure, isolated environment on Linux for running untrusted code. When you need to execute a program without risking damage to the host system, Z-Jail wraps it in multiple overlapping protections at once. The compiled binary is about 130 kilobytes and has no external dependencies beyond the Linux kernel itself. The tool applies seven layers of restriction in a specific order, each one strengthening the last. First, it caps CPU time, memory, and file usage. Then it severs the process from the host filesystem using a Linux feature called pivot_root, which is stricter than the older chroot approach. It strips all Linux capabilities from the process, disables any path by which the process could regain elevated privileges, and blocks all but 15 specific system calls using a filter called seccomp-BPF. Any system call outside that short list causes the process to be killed immediately. The sandbox also creates isolated namespaces for the network (giving the child process no network access), process IDs, shared memory, and the hostname. Each layer is applied before the next so that an earlier stage cannot be bypassed by code running in a later one. Z-Jail includes a component called Truthimatics, which the README describes as an evidence-based verdict engine. It collects weighted observations about how the executed binary behaved and assigns one of three verdicts: DETERMINISTIC, REJECT, or UNCERTAIN. All actions are logged to a JSON file with BLAKE2b hash values for auditability. The project targets use cases like continuous integration pipelines, capture-the-flag competition jails, and lightweight code evaluation environments where a full container runtime would be too heavy. A single make command builds it on Linux 5.4 or newer.

Copy-paste prompts

Prompt 1
I want to use z-jail to sandbox student code submissions. Show me the command to run a C binary inside z-jail with a 5-second CPU time limit and 128 MB memory cap.
Prompt 2
Explain how z-jail's seccomp-BPF filter works: what system calls are allowed and what happens when a blocked syscall is attempted?
Prompt 3
Help me integrate z-jail into a GitHub Actions workflow that runs user-submitted shell scripts without risking the runner host.
Prompt 4
What does z-jail's Truthimatics verdict engine output look like in the JSON audit log? Give me an example of a REJECT verdict and what behavior triggers it.
Open on GitHub → Explain another repo

← division-36 on gitmyhub — every repo by this author, as a profile.

Verify against the repo before relying on details.