Capabilities: remove authority from the right sets at the right time

The effective set supplies capabilities used for relevant permission checks. The permitted set bounds what the thread can make effective through the allowed operations. The inheritable set participates in exec capability derivation, while the bounding set limits certain capabilities gained through executable file capabilities. Ambient capabilities support carrying selected authority across a nonprivileged exec and must remain within both permitted and inheritable sets. These roles cannot be summarized accurately by counting how many capability names appear in a configuration file.

Capability checks also occur in a user-namespace context. A capability held in a child namespace does not automatically satisfy an initial-namespace check. Some capabilities are broad and cover many operations, while others are narrower; least privilege means reviewing required actions, not merely minimizing a numeric count. Inspect supported capability names on the actual kernel and runtime, because the available set has expanded over time. A runtime's accepted schema is not evidence that an impossible privilege was successfully granted.

Dropping a bit from the bounding set changes a future-gain restriction; it does not automatically erase the bit from the thread's existing permitted or effective sets. Dropping from permitted can be irreversible for that running thread under the applicable rules, and adjusting the bounding set itself requires the appropriate authority. Therefore a setup process must finish operations such as configuring groups, changing IDs, preparing mounts, or dropping bounding bits before discarding the capabilities those operations need. The correct sequence depends on the runtime's user-namespace and securebits design.

Clear unwanted ambient and inheritable state as part of the final policy, then verify permitted and effective sets after the intended UID and exec transitions. no_new_privs prevents exec from granting additional privileges under its contract and is inherited; once set, it cannot simply be unset by the task. It does not remove capabilities already held, close a privileged descriptor, or make current filesystem access harmless. Treat it as one constraint on future transitions, not a replacement for actively reducing existing authority.

Record the intended capability sets at setup, before exec, and in the actual application. Include supplementary groups, no_new_privs, securebits where relevant, and user-namespace identity. Test that a required narrow operation succeeds and an unrelated operation remains denied under the same mount and LSM context. A failed privileged operation alone does not identify which layer denied it. A broad runtime flag can restore several mechanisms at once and obscure the minimal permission actually required.

The probability lab illustrates why sampled permission tests do not prove a complete privilege policy. Reset, explicitly set p=0.20 and n=5, interpret success as detecting a hypothetical unwanted authority path, predict the zero-success bar, then Play or Step. For another independent toy run Reset and explicitly set p=0.20 and n=10. These assumed independent detections are not kernel capability checks. The lab neither represents the five sets nor validates exec transitions; inspect actual identities and set membership for that evidence.