No New Privileges Flag (Linux no_new_privs)

What the No New Privileges flag changes

The no new privileges flag changes the privilege model of a running process by making privilege gains one-way: once enabled, neither the process nor its descendants can acquire extra privilege through setuid, setgid, file capabilities, or other privilege transitions.

This matters because many escalation paths depend on a later transition to a more privileged execution context. With the flag set, the workload can still run, but it is prevented from crossing privilege boundaries that would normally be available to a process with a different effective identity or capability set.

Why it is used in hardened Linux workloads

Defenders often apply no_new_privs to services, containers, and other execution environments that run untrusted or partially trusted code. It is a containment control, not a full isolation boundary, so it is most useful when paired with other restrictions that already reduce the process’s ambient authority.

In practice, it helps limit the blast radius of code execution bugs, command injection, and post-exploitation privilege escalation attempts. That makes it especially relevant in container runtimes and service managers where a process may inherit useful filesystem, network, or launch-time access even though it should never be able to become more privileged than it started.

How it interacts with Linux privilege mechanisms

The flag does not remove the privileges a process already has, and it does not block every security-relevant action. Instead, it prevents the process from taking advantage of mechanisms that would normally raise privilege after execution begins.

That distinction is important. A workload can still be dangerous if it already has broad filesystem access, powerful capabilities, writable mounts, or access to sensitive sockets. No New Privileges narrows escalation paths, but it does not replace least privilege, namespace isolation, syscall filtering, or careful service account design.

What to verify when you rely on it

Organisations should verify where the flag is actually set, because its protection only exists when the runtime, service definition, or container policy applies it consistently. It is also worth checking whether the workload depends on any legitimate privilege transition, because enabling the flag can break software that expects to elevate at runtime.

It is useful to think of no_new_privs as a guardrail around execution context rather than a complete hardening strategy. When it is present, it should be part of a broader containment design that also considers Container Security Guide guidance on runtime isolation and hardening, and Service Account Security Guide practices for controlling what the workload can do before any escalation path exists.

Risk and Threat Considerations

When no_new_privs is absent, an attacker who achieves code execution may have a clearer path to privilege escalation through setuid binaries, file capabilities, or helper processes that were intended to be safe. That is especially relevant in containerised or service-based environments where the initial foothold is low privilege but the host or adjacent workload still contains valuable execution paths.

Failure mechanism: The process inherits or reaches a privilege transition point that was assumed to be unavailable, allowing post-exploitation escalation or broader system access.

Impact: A local compromise can become a higher-value compromise, including access to protected files, credentials, host resources, or neighbouring workloads.

Practitioner Guidance

Why practitioners should care: No New Privileges is most valuable where a workload may run code you do not fully trust but still needs enough authority to function. If you use it, treat it as a baseline containment control for services, containers, and automation paths that should never gain extra privilege during execution.

Common misunderstanding: It is easy to assume the flag makes a workload “safe” by itself. It does not, it only blocks one class of privilege gain. The workload can still be over-permissioned, exposed through writable mounts, or vulnerable to abuse through whatever authority it already has.

Practitioner takeaway: Use no_new_privs to remove privilege elevation as an attack step, then validate the rest of the runtime boundary separately.

Related resources from NHI Mgmt Group

• Who is accountable when feature flag governance allows unintended access to new functionality?
• What are the signs that Linux malware persistence is present even when endpoint scans do not flag the binaries?
• How should security teams harden Linux systems against ransomware that targets misconfigurations and weak privileges?
• Why do standing privileges and exposed services increase the risk of malware on internet-facing Linux servers?