Skip to content

Security

Purgatory is built for a team that trusts each other's intentions but not each other's mistakes: it keeps one person's broken compose file, runaway container or exposed port from affecting everyone else. It is not a boundary against hostile code.

What it does:

  • each user gets their own Docker daemon, so their containers, images, volumes and networks are separate from everyone else's and from the host's Docker;
  • an app's private addresses are reachable only inside its own sandbox, and ports published on 127.0.0.1 only through its tunnel (see Isolation between sandboxes);
  • users see and change only their own sandboxes, through the UI, the API or a personal access token; the admin sees all;
  • with an https:// PUBLIC_URL, Purgatory refuses to start with default secrets.

On a shared server (several people, or agents running code you have not read): install sysbox on the host and set ALLOWED_RUNTIMES=sysbox in .env. New sandboxes then always run under sysbox, nobody can create a privileged dind one, and check-host.sh tells whether sysbox works on the machine. Sandboxes created before keep their runtime: recreate the dind ones.

What it does not do:

  • Without sysbox, sandboxes run privileged (the dind runtime). Code with root inside such a sandbox can escape to the host. By default (DEFAULT_RUNTIME=auto) new sandboxes use the sysbox runtime wherever sysbox is installed on the (Linux) host, which runs Docker in an unprivileged container; Docker Desktop cannot run sysbox, so there they fall back to dind, and Purgatory says so at startup. Only let people and agents you would give a shell on the host run code in dind sandboxes.
  • sysbox is not a VM: its sandboxes run unprivileged, in their own user namespace, but share the host's kernel, so a kernel exploit would still reach the host.
  • There is no network policy between a sandbox and the internet, and no hard disk quota per sandbox: only a warning above its disk limit (see Disk); CPU and memory limits exist (see CPU and memory).
  • The Purgatory container mounts the host's Docker socket, so whoever controls Purgatory controls the host.

For untrusted code (public sign-up, code from strangers), use sysbox or a microVM-based sandbox instead; a Kata Containers runtime (a VM per sandbox) is on the roadmap.

Found a vulnerability? See SECURITY.md.