It is working when processes cannot gain additional privileges through setuid, setgid or file capabilities after the flag is applied. You should see privilege escalation attempts fail and the process inherit no extra rights beyond what it started with. Verify it on the running container or process and test with a controlled escalation check.
What the flag changes at the process boundary
no new privileges is a process-level safeguard, so the main question is not whether a process still runs, but whether it can acquire more rights after the flag is in force. Evidence of success is behaviour at the privilege boundary: setuid and setgid paths stop elevating the process, file capabilities no longer add rights, and any attempted escalation remains constrained to the original privilege set.
A practical sign is that the process behaves the same before and after a controlled privilege check, with no unexpected expansion of effective UID, GID, or capability set. That tells you the kernel is honoring the restriction instead of allowing a later exec path to widen authority.
How to verify it on a live container or process
Verification should be done against the running workload, not just from configuration intent. Check the process state, confirm the flag is present, and then run a controlled escalation test that would normally raise privileges through setuid, setgid, or file capabilities. If the test fails as expected, the flag is working at runtime.
Good evidence is reproducible and local to the workload: the same container or process should refuse the escalation attempt every time, and the failure should occur even when the binary or capability marker is present. If the process can still gain extra rights, the flag is either missing, not inherited into the actual process path, or being bypassed by a different execution route.
What failure looks like and why it matters
When the flag is ineffective, the process can still become more privileged than intended during execution, which defeats the main containment value of the control. That matters most when a workload launches helpers, shells out, or loads components that would normally exploit setuid, setgid, or capability-based elevation.
This is why container hardening guidance should treat a successful negative test as proof of the control, and a successful privilege gain as a red flag for execution context, image content, or runtime configuration. For broader container hardening context, the Container Security Guide covers the runtime isolation and capability controls that make this flag meaningful.
Risk and Threat Considerations
The main risk is that a workload appears constrained on paper while still being able to widen its authority during execution. If an attacker reaches code execution inside the container or process, a missing or ineffective restriction can turn a small foothold into access to more sensitive files, commands, or downstream services.
Failure mechanism: The process inherits or regains privilege through an exec path, capability handoff, or helper binary that was expected to be blocked, so the privilege boundary no longer holds.
Impact: A compromised workload can exceed its intended permissions, increasing the chance of container breakout, host interaction, secret access, or lateral movement into adjacent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-5 — Account Management | Checks whether privilege gain paths are actually controlled at runtime. |
| Recommendation — Verify setuid, setgid, and capability-based escalation are blocked in the live workload. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | No New Privileges is a least-privilege enforcement mechanism for processes. |
| Recommendation — Restrict process privilege gain so execution cannot exceed its intended authority. | ||
| ISO/IEC 27001:2022 | A.8.2 — Privileged access rights | This flag limits privilege expansion, which is central to privileged access control. |
| Recommendation — Confirm runtime privilege boundaries prevent unintended elevation. | ||
| NIST CSF 2.0 | PR.AA-05 — Identity management, authentication and access authorisation are managed for assets and users | The control verifies access boundaries are enforced for a running workload. |
| Recommendation — Validate that the workload cannot obtain additional authorisation during execution. | ||
Practitioner Guidance
What to verify: Test the exact process path you expect to protect, not a substitute binary. A control that passes in one shell session but fails in the actual workload startup path is not reliable enough for production use.
Decision rule: If the workload can still gain rights through setuid, setgid, or file capabilities, treat that as a configuration failure and review the full runtime context before trusting any other isolation control.
Practitioner takeaway: The strongest evidence is a repeatable negative result, privilege escalation attempts should fail in the real running process, not just in a lab or in configuration review.