A capability bounding set limits what root can regain
Linux capabilities split traditional root privilege into named units. A process can hold capabilities directly, inherit them across execve, or receive them from file metadata. The bounding set is the mask that limits which capabilities may be inherited across execution. It is one of the reasons a container running as user zero does not necessarily have every kernel privilege.
That relationship is frequently misunderstood. Teams inspect the effective capability set, see a reduced list, and conclude that the process is contained. They may not inspect the bounding set, the file capabilities on executables, the ambient set, or the user namespace. A process can look ordinary until it executes a privileged binary and the kernel computes a new capability state.
The sets answer different questions
The Linux capabilities manual describes permitted, inheritable, effective, ambient, and bounding sets. The permitted set is the capabilities the thread may use. The effective set is the subset currently active. The inheritable set participates in inheritance. The ambient set preserves selected capabilities across non-privileged execution. The bounding set limits what may be added to the inheritable set across execve, especially when a binary executes with UID 0 or file capabilities.
The exact transitions are subtle. That is why a review should not infer the final state from configuration alone. Use the runtime's own tooling to print the current process status before and after the application starts. For a container, inspect the process inside the container, not only the pod or task specification.
Root is not one capability
CAP_CHOWN, CAP_NET_ADMIN, CAP_SYS_ADMIN, CAP_SYS_PTRACE, and CAP_DAC_READ_SEARCH expose very different powers. A web application may need to bind a low port, but that does not justify the full set of root capabilities. A monitoring agent may need packet inspection, which is still a network-level privilege that deserves a separate host or namespace.
The bounding set is useful as a backstop because it can remove capabilities that a privileged executable might otherwise gain. It is not a complete application sandbox. A process with CAP_SYS_ADMIN may have broad ability to change namespaces or mount state depending on the kernel and surrounding policy. Dropping one capability does not make a set of unrelated privileges harmless.
File capabilities deserve their own inventory. A binary can carry capabilities even when the caller is not root. An application that can execute an arbitrary path, load a plugin, or call a shell can turn an allowed capability into a different privilege if a file with capabilities is reachable. Bind mounts, writable /usr, and shared host filesystems change what "reachable" means.
Containers and delegated namespaces
Container runtimes typically configure a default capability set and a bounding set. The container may also run in a user namespace, where capabilities are scoped to that namespace. The security result depends on both. A process that appears to hold CAP_NET_ADMIN inside a user namespace may not control the host network, but it may control a network namespace that the application can reshape.
Review the runtime configuration, the container image, and the process state as a chain. Check whether the image contains setuid or file-capability binaries. Check whether the application can write to directories that hold executables. Check whether privileged helper processes are started by the same controller. Then verify the effective and bounding sets in the running instance.
Do not grant a broad capability merely to avoid changing an application. A service that needs to bind port 80 can receive the port through a service manager or a low-port capability instead of being granted CAP_NET_RAW or CAP_SYS_ADMIN. A backup job can run in a separate identity with access to the backup path instead of being made a general-purpose privileged container.
Audit and change control
Record the expected capability set as a security baseline. The baseline should state why each capability is needed, which process uses it, which files can be executed, and how a test detects a new grant. Alert on changes that add capabilities or remove a drop rule, especially in production workloads that previously passed review.
Examine the bounding set during incident response. If an attacker gains code execution, the next step often involves checking what privileges can be obtained after execution. A missing capability does not prevent data theft through application credentials, but it can prevent a persistent privileged path. The inventory should distinguish those cases.
The review should also cover kernel and runtime updates. A change to the container runtime's default set, a new helper binary, or a base-image update can alter the effective state. Re-run the process-level test after upgrades rather than treating the deployment manifest as permanent evidence.
What to document
For each workload, record the container or service identity, UID, user namespace, permitted and effective sets, ambient and inheritable sets, bounding set, file capabilities, writable executable paths, and the reason for every retained capability. Include the command used to inspect the live process and the runtime version.
The final question is not whether the process runs as root. It is which powers remain reachable after the next execve. A bounding set gives defenders a useful way to reduce that reach. It becomes a reliable control when it is tested against the actual binary path and paired with a narrow filesystem, a non-root identity where possible, and a process-specific policy.
