Playpen is a secure application sandbox built with modern Linux sandboxing features.
- The sandboxed application is spawned inside a systemd scope unit, providing
integration with systemd tools like
systemd-cgtopand robust control group management.
- The application is contained inside a read-only root directory with
- System call whitelisting forbids all but the
execvecall 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 ==.
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
# 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 /
- Linux 3.8 or later
- libseccomp 2.1.1 or later