I first wrote about Linux capabilities in 1999 as a foundation that was not yet operationally usable. Two years on, the situation has improved meaningfully. A status check is worth writing.
What has changed
Three main shifts.
File capabilities are in development. A patch set adding capability attributes to filesystem inodes — so that a binary can be marked as "runs with CAP_NET_RAW only" — is in active development. It is not yet in mainline; it is in the experimental kernels. Once it lands, the SUID-root pattern can finally be replaced.
Several daemons now drop capabilities at start. OpenSSH, Apache, several others have been updated to keep only the capabilities they need after their privileged setup. The pattern is becoming standard rather than experimental.
Userspace tooling has improved. libcap is now stable and reasonable. The cap_set_proc and friends are well-documented. Writing capability-aware programs is no longer the edge of the supported world.
What is now possible
For an operator who wants to deploy capability-restricted services:
A capability-aware wrapper. A small C program that takes a service binary, sets up the desired capabilities, and execs the service. The wrapper is setuid root but is small enough to audit. The service runs unprivileged-with-specific-capabilities.
Kernel-supported isolation. The combination of capabilities, chroot, and a dedicated user is now operationally robust. A daemon running in this configuration is well-contained.
Monitoring of capability-related kernel events. The kernel logs capability-related decisions (which can be configured); off-host log analysis can identify unusual capability usage patterns.
What is still missing
File capabilities not yet in mainline. The patches will land eventually; in the interim, the wrapper-program pattern is the workaround.
Distribution support is uneven. Some distributions ship capability-restricted versions of common daemons; others do not. The transition is happening; it is patchy.
Documentation is rough. The official kernel documentation about capabilities is dense and out of date in places. Operators have to read source or rely on third-party guides.
What I am doing on my own infrastructure
A few specific changes:
Capability-restricted tcpdump. A wrapper that runs tcpdump with only CAP_NET_RAW, accessible to non-root users I trust. The previous setup was running tcpdump as root manually; this is more convenient and more contained.
Capability-restricted DNS server. Running BIND with only the capabilities it needs (CAP_NET_BIND_SERVICE, CAP_DAC_OVERRIDE for the chroot setup) rather than full root. The compromise blast radius is smaller.
Periodic capability audits. A small script that lists every service running on each of my hosts and what capabilities each holds. The audit catches drift — services that have accumulated capabilities they do not need.
A small note on the trajectory
The shift from SUID-root to capability-aware deployment has been the slowest of the structural improvements I have been tracking. The technical foundation has been there since 1999; the operational maturation has taken years. By 2003 or 2004 I expect the SUID-root pattern to be largely replaced for new deployments. Existing deployments will lag; the transition is still slow.
This is the typical shape of these structural shifts. The kernel work is the smaller part; the userspace integration, documentation, distribution support, and operator habit-change are larger and slower.
More as the year develops.