How to Harden Services on FreeBSD with Capsicum
A practical walkthrough of Capsicum's capability mode — how to check if a program supports it, and how sandboxed services actually differ from ordinary ones at the syscall level.
Capsicum is FreeBSD’s native capability-based security framework — restricting a process to only the specific file descriptors and system calls it’s been explicitly granted, rather than the traditional Unix “everything the user can do” permission model.
Step 1: understand what capability mode actually restricts
Once a process enters Capsicum’s capability mode, it loses access to global namespaces entirely — it can no longer open arbitrary file paths, create new sockets to arbitrary addresses, or see other processes — and is limited to operating on file descriptors it was already holding before entering that mode.
Step 2: check which installed utilities already support Capsicum
man casper
ls /usr/lib/libcasper*A number of FreeBSD base system utilities (dhclient, tcpdump, parts of sshd) already run capability-sandboxed portions of their own code — Capsicum support is something individual programs opt into, not something applied blanket across the system.
Step 3: verify a program is actually running sandboxed
procstat -a <pid> | grep -i capprocstat can show a process’s capability-mode status directly, confirming whether a given running program is actually taking advantage of the sandboxing it supports.
Step 4: understand the Casper daemon’s role
Programs in capability mode still occasionally need controlled access to something global — DNS resolution, for instance. Casper is the trusted helper daemon that provides these specific, narrowly-scoped services to sandboxed processes without giving them back the full, unrestricted access Capsicum is designed to remove.
Step 5: use rctl alongside Capsicum for resource limits
rctl -a process:1234:vmemoryuse:deny=512MCapsicum restricts what a process can access; FreeBSD’s rctl framework separately restricts how much of a resource it can consume — combining both gives a sandboxed process both a narrow capability surface and a hard resource ceiling.
Step 6: check pkg-audit for services with existing Capsicum support before deploying
pkg info -x <package-name>Not every network-facing service ported to FreeBSD has been adapted to use Capsicum — checking whether a specific package has upstream Capsicum support (rather than assuming it does) is worth doing before relying on it for defense-in-depth.
Step 7: understand this as defense-in-depth, not a substitute for other hardening
Capsicum reduces what a compromised process can do — it doesn’t prevent the initial compromise. It’s meant to sit alongside, not replace, firewall rules, jails, and ordinary patching discipline.
Why capability-based security is a genuinely different model from traditional Unix permissions
Traditional Unix permissions ask “is this user allowed to do X” — a question answered once, broadly, at the user level. Capsicum asks “does this specific process currently hold a capability for X” — a much narrower, per-process, per-resource question, which is exactly why a compromised process in capability mode has dramatically less to work with than the same compromise would in an ordinary, unsandboxed process running as the same user.