This repository has been archived by the owner. It is now read-only.
A secure application sandbox built with modern Linux sandboxing features - no longer actively developed, but still works fine, use bubblewrap if you need more functionality
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
LICENSE update copyright year Mar 26, 2014
Makefile silence Clang's missing field initializers warning Nov 12, 2015
README.md document system call whitelisting Nov 4, 2015
playpen.c extend parameter auto-learning to prctl Dec 19, 2015

README.md

Playpen is a secure application sandbox built with modern Linux sandboxing features.

Features

  • The sandboxed application is spawned inside a systemd scope unit, providing integration with systemd tools like systemd-cgtop and robust control group management.
  • The application is contained inside a read-only root directory with chroot.
  • System call whitelisting forbids all but the execve call by default and includes support for parameter constraints. A learning mode is available to automatically generate a minimal whitelist based on the system calls and parameters used by the sandboxed process.
  • A mount namespace is leveraged to provide writable /tmp, /dev/tmp and home directories as in-memory (tmpfs) filesystems. Since these mounts are private, any number of Playpen instances can share the same root.
  • The memory of all contained processes is limited via the scope unit's memory control group. The memory control group will include usage of the private tmpfs mounts towards the total.
  • The number of tasks is limited via the scope unit's pids control group in addition to the indirect limitation via the memory control group.
  • Device whitelisting prevents reading, writing or creating any devices by default.
  • The initial process and any forked children can be reliably killed.
  • An optional timeout can take care of automatically killing the contained processes.
  • A process namespace hides all external processes from the sandbox.
  • A network namespace provides a private loopback and no external interfaces.
  • The system's hostname and IPC resources are hidden from the sandbox via namespaces.

System call whitelisting

A system call will only be permitted by the kernel if it matches one or more of the provided rules. Rules can be supplied either via a file (-S) or by passing rules on the command-line (-s).

Learning mode (-l) will append any missing rules to the whitelist file. It will add constraints on parameters specifying a sub-command, such as the request argument to ioctl. A coarser learning mode without parameter constraints is available (-L).

Syntax for the whitelist:

system_call
system_call: parameter operator value
system_call: parameter operator value, parameter operator value, [...]

Tabs and spaces are ignored. The command-line syntax uses semicolons as the separator between rules rather than expecting one rule per line.

The valid operators are !=, <, <=, >, >= and ==.

For example:

bar
foo: 2 == 100
foo: 2 == 200, 1 != 300, 1 != 400, 3 < 500

This permits the bar system call in all cases. The foo system call is permitted if either:

  • the second parameter is equal to 100
  • the second parameter is equal to 200, the first parameter is not equal to either 300 or 400 and the third parameter is less than 500

Example

# create a chroot
mkdir sandbox
pacstrap -cd sandbox

# run `ls -l` in the sandbox and create a system call whitelist
playpen sandbox -S whitelist -l -- ls -l /

# run it again, enforcing the learned system call whitelist
playpen sandbox -S whitelist -- ls -l /

Dependencies

  • Linux 3.8 or later
  • libseccomp 2.1.1 or later
  • systemd