CAPSICUM(4)

📦
version 15.1 · 2 versions
, in freebsd 14.5, freebsd 15.1

💅 CAPSICUM(4) — like, the capability & sandbox framework, bestie

okay so real talk, this is the CAPSICUM page from the Kernel Interfaces Manual, and it's genuinely one of the most iconic kernel features ever. let's get into it 🫶

✨ NAME ✨

Capsicum — the lightweight OS capability and sandbox framework. yes, that's the whole name. she's lowkey humble about it 💅

🌸 SYNOPSIS 🌸

options CAPABILITY_MODE
options CAPABILITIES

yep, that's it. two kernel options. that's the whole vibe check 🎀

🦋 DESCRIPTION 🦋

so Capsicum is a lightweight OS capability and sandbox framework that implements a hybrid capability system model. and the way it does this? it deliberately blends capabilities with UNIX. like, she's not trying to replace UNIX, she's trying to sit next to her at lunch 💖

this approach gets you a bunch of the benefits of least-privilege operation, while keeping existing UNIX APIs and performance intact. and it also hands application authors an actual adoption path for capability-oriented design — no cap, that's the good part.

Capabilities are unforgeable tokens of authority. they can be delegated, and you must present them to perform an action. Capsicum makes file descriptors into capabilities. periodt ✨

Capsicum is used for application and library compartmentalisation — that's the decomposition of larger bodies of software into isolated (sandboxed) components, so you can actually implement security policies and limit the impact of software vulnerabilities. very demure, very mindful, very secure 🧚

💜 the two core kernel primitives

capability mode

a process mode, entered by invoking cap_enter(2), where access to global OS namespaces (think the file system and PID namespaces) is restricted. only explicitly delegated rights — the ones referenced by memory mappings or file descriptors — may be used. once the flag is set, it's inherited by future children processes, and it may not be cleared. like, it's forever, bestie. no take-backs 💀

access to system calls in capability mode is restricted: some system calls that need global namespace access are just unavailable, and others get constrained. for instance, sysctl(2) can query process-local info like address space layout, but it can also monitor a system's network connections. so sysctl(2) is constrained by explicitly marking about 60 of over 15000 parameters as permitted in capability mode — every other one is denied. roughly 60 out of 15000. that's not a vibe check, that's a vibe massacre 😭

the system calls that require constraints are sysctl(2), shm_open(2) (which is allowed to create anonymous memory objects but not named ones), and the openat(2) family of system calls. the openat(2) calls already accept a file descriptor argument as the directory to perform the open(2), rename(2), etc. relative to — and in capability mode the openat(2) family gets constrained so they can only operate on objects “under” the provided file descriptor. under. like underneath. stay in your lane, bestie 🎀

capabilities

these limit the operations you can call on file descriptors. example time: a file descriptor returned by open(2) can be refined using cap_rights_limit(2) so that only read(2) and write(2) can be called on it — but not fchmod(2). she can read, she can write, she cannot fchmod. main character energy with boundaries 💅

the complete list of capability rights lives in the rights(4) manual page. go read it, iykyk.

🌈 sometimes Capsicum needs alternatives to classic POSIX APIs

in some cases, Capsicum requires you to use alternatives to traditional POSIX APIs in order to name objects using capabilities instead of global namespaces:

  • process descriptors — file descriptors representing processes! these let parent processes manage child processes without needing access to the PID namespace. the full tea is in procdesc(4).
  • anonymous shared memory — an extension to the POSIX shared memory API that supports anonymous swap objects associated with file descriptors. again, shm_open(2) has the details.

⭐ and sometimes Capsicum limits your parameter values

in some cases, Capsicum limits the valid values of some parameters to traditional APIs in order to restrict access to global namespaces:

  • process IDs — processes can only act upon their own process ID with syscalls such as cpuset_setaffinity(2). mind your own business, honestly 🙈

💖 bonus FreeBSD functionality (not part of Capsicum itself)

FreeBSD provides some extra functionality to support application sandboxing that is not part of Capsicum itself:

  • capsicum_helpers(3) — a set of inline functions which simplify modifying programs to use Capsicum. she's a little helper 🥺
  • libcasper(3) — a library that provides services for sandboxed applications, like operating on files specified on a command line, or establishing network connections. iconic behaviour fr fr

🔥 SEE ALSO 🔥

cap_enter(2), cap_fcntls_limit(2), cap_getmode(2), cap_ioctls_limit(2), cap_rights_limit(2), fchmod(2), open(2), pdfork(2), pdgetpid(2), pdkill(2), pdwait4(2), read(2), shm_open(2), write(2), cap_rights_get(3), capsicum_helpers(3), libcasper(3), procdesc(4)

🌸 HISTORY 🌸

Capsicum first appeared in FreeBSD 9.0, and was developed at the University of Cambridge. academic baddie behaviour 🎓

👑 AUTHORS 👑

Capsicum was developed by:

  • Robert Watson <rwatson@FreeBSD.org>
  • Jonathan Anderson <jonathan@FreeBSD.org>

…at the University of Cambridge, plus:

  • Ben Laurie <benl@FreeBSD.org>
  • Kris Kennaway <kris@FreeBSD.org>

…at Google, Inc., and:

  • Pawel Jakub Dawidek <pawel@dawidek.net>

also! portions of this manual page are drawn from Robert N. M. Watson, Jonathan Anderson, Ben Laurie, and Kris Kennaway, “Capsicum: practical capabilities for UNIX”, USENIX Security Symposium, August 2010, DOI: 10.5555/1929820.1929824. cite your sources, besties 💖

ok that's the whole page 🫶 go sandbox something and stay safe out there. remember: capability mode is forever, and so is this hyperfixation.

Debian · January 23, 2026 · CAPSICUM(4) — mwah, love u, bye 💋🎀

📦 where this page comes from