README
¶
redpwn/jail
An nsjail Docker image for CTF pwnables. Easily create secure, isolated xinetd/inetd-style services.
Playing a CTF that uses redpwn/jail? Read the Competitor FAQ.
Want to use redpwn/jail in your CTF? Read the the Challenge Author Guide.
Features
- Efficiently start a new container-like jail for each incoming TCP connection
- Route each connection to the jail's stdio
- Enforce per-connection CPU/memory/PID/disk resource limits
- Optionally require a proof of work for each connection
Quick start
Create a Dockerfile:
# use the jail base image
FROM pwn.red/jail
# copy the root files from any Docker image
COPY --from=ubuntu / /srv
# setup the binary to run
RUN mkdir /srv/app && ln -s /bin/sh /srv/app/run
Then, build and run the container with:
docker run -p 5000:5000 --privileged $(docker build -q .)
To connect, run:
nc localhost 5000
You're now connected to a shell that's fully sandboxed by redpwn/jail! You can run any command you like.
For an example of installing packages inside the jail, see examples/cowsay.
For a Python example with environment configuration, see examples/python.
Background
Turning an executable into a sandboxed network service is not an easy task. Traditionally, this involved a long Dockerfile based on xinetd, which has a very limited feature set. Ideally, we would also want complete isolation between connections and be able to set strict limits so resources are not exhausted by a single competitor. Many challenges, particularly pwnables, will result in remote code execution. This makes isolation even more challenging.
Google's nsjail provides the server and strong isolation we need. Unfortunately, nsjail provides limited defense-in-depth, has many complex options, and doesn't work in every environment. redpwn/jail is a wrapper around nsjail with sensible default configuration for CTF challenges that exposes a small set of options a CTF challenge may require. It also includes a proof-of-work system that can be enabled with one environment variable.
Configuration Reference
For an overview of using redpwn/jail in a CTF, read the Challenge Author Guide.
redpwn/jail mounts /srv in the container to / in each jail, then executes /app/run (so /srv/app/run outside the jail) with a working directory of /app.
To configure these, use ENV in your Dockerfile. To remove a limit, set its value to 0.
| Name | Default | Description |
|---|---|---|
JAIL_TIME |
20 |
Maximum wall seconds per connection |
JAIL_CONNS |
0 |
Maximum concurrent connections across all IPs |
JAIL_CONNS_PER_IP |
0 |
Maximum concurrent connections for each IP |
JAIL_PIDS |
5 |
Maximum PIDs in use per connection |
JAIL_MEM |
5M |
Maximum memory per connection |
JAIL_CPU |
100 |
Maximum CPU milliseconds per wall second per connection. For example, 100 means each connection can use 10% of a CPU core |
JAIL_POW |
0 |
Proof of work difficulty |
JAIL_PORT |
5000 |
Port number to bind to |
JAIL_DEV |
null,zero,urandom |
Device files available in /dev separated by , |
JAIL_SYSCALLS |
(none) | Additional allowed syscall names separated by , |
JAIL_TMP_SIZE |
0 |
Maximum size of writable /tmp directory in each jail. If set to 0, the writable /tmp directory is unavailable. |
JAIL_ENV_* |
(none) | Environment variables available in each jail (with the JAIL_ENV_ prefix removed) |
If it exists, /jail/hook.sh is executed before the jail starts. Use this script to configure nsjail options or the execution environment.
Files specified in JAIL_DEV are only available if /srv/dev exists.
In each jail, procfs is only mounted to /proc if /srv/proc exists.
Proof of Work
To require a proof of work from clients for every connection, set JAIL_POW to a nonzero difficulty value. Each difficulty increase of 1500 requires approximately 1 second of CPU time on a modern processor. The proof of work system is designed to not be parallelizable.
End users are instructed to use the script at pwn.red/pow to download, cache, and run a prebuilt solver.
Directories