The direct answer
Treat no_new_privs as an exec-transition restriction, not a mechanism that removes the launcher’s existing authority. Associate the successful setting with the actual launching context and its supported inheritance path before admitting a fixed native worker. Existing credentials, resources, security-policy compatibility and current input rights still need independent evidence.
Review the starting authority before the exec restriction
A fictional preprocessing service wants trusted native worker W-A to summarize an already admitted ordinary note I-A. An operator offers one reassuring statement: the launcher enables no_new_privs. The missing question is what the launcher can already do, and whether that exact restriction reaches the context that executes W-A.
The existing permission map and file and process guide still govern the worker’s authority. This worksheet adds one Linux-specific transition decision; it does not create a low-privilege identity or approve arbitrary programs.
Propose already restricted launching context L-A, a complete admitted native program and its execution dependencies, fixed arguments and environment, and current I-A authorization. Actual kernel, ABI, libc, security-policy and ownership support are unknown. These unimplemented prerequisites block real admission. All eight cards are PROPOSED_UNRUN: no syscall, credential, thread, process or executable was inspected or exercised.
Bind the successful API result to the calling context
The PR_SET_NO_NEW_PRIVS manual sets the calling thread’s attribute. Its documented call shape uses value 1L and three following zero-valued long arguments. Success returns zero; failure returns minus one with errno. Once set, the attribute cannot be unset; children created by fork or clone inherit it, and execve preserves it.
For L-A, record the exact setter contract, its supported result, actual calling-context association and the admitted transition to W-A. A setup component reporting success is insufficient when another unrelated thread or launch path actually starts the worker. The setting must not become a process-wide claim merely because the application has one convenient job identifier.
This worksheet supplies no threading, launch adapter, state query or inheritance implementation. A later report or intended ordering cannot establish the actual association by itself. If supported evidence is absent or the setter result is unknown, hold launch instead of retrying through an alternate helper.
State the exec privilege change that is suppressed
The execve manual describes file-mode changes to effective user and group IDs, and file capabilities. When no_new_privs is set for the calling thread, those file-based transformations are ignored. It also states that real IDs and supplementary groups are unchanged by execve.
Therefore, do not approve L-A because a file-based elevation path is constrained while ignoring its current authority. The useful baseline is independently restricted before this transition. This article provides no credential-drop sequence, supplementary-group update, capability-set arithmetic or proof of the resulting identity.
The kernel explanation separately warns that privilege changes outside execve are not prevented. A task that already has relevant power or a permitted channel may still exercise that authority. Keep access to files, sockets, credentials and application operations in their own review rather than labelling them revoked by this bit.
Check security-policy compatibility instead of assuming improvement
The same kernel documentation warns that Linux Security Modules might also fail to tighten constraints on exec in this mode. An expected tighter security transition must therefore be independently reconciled with the selected policy. Do not assert that adding this restriction universally improves every daemon’s confinement.
For W-A, propose review record P-A containing the admitted launcher authority revision, exact native program and dependency revision, setter result association, launch path and separately supported security-policy compatibility. Add current job/input rights and resource boundaries. None of those associations was collected from a live host here.
The two manuals identify Linux man-pages 6.19, dated 8 February 2026. The kernel page displays no current kernel-release marker. Those documentation revisions are not installed-runtime evidence. A different platform, wrapper, interpreter or security transition falls outside P-A rather than receiving a weaker automatic rerun.
Walk eight inert exec-policy admission cards
| Invented condition | Proposed disposition |
|---|---|
| Already restricted L-A; supported setter result and W-A association; all independent prerequisites hold | Admit the narrow exec-policy plan for separate authorized launch review. Claim no running or contained worker. |
| Setter fails, arguments differ or its result is unavailable | Hold the plan; intended flag presence is not success evidence. |
| L-A still has excessive identity, group, capability or resource authority | Reject the baseline independently; this setting is not a privilege-drop implementation. |
| An unrelated setup thread reports success while the actual launching context is unknown | Hold the inheritance claim rather than assuming all threads were changed. |
| A later program depends on file-based elevation | Reject that compatibility assumption under this profile; do not relax the restriction to make it work. |
| An existing permitted channel or credential enables a protected action | Review that authority separately; exec restrictions do not supply its revocation. |
| The plan assumes a reset or an unreviewed security-policy, wrapper or platform transition | Outside P-A; require a different review instead of inventing a supported reset. |
| Exec policy matches, but worker behavior, input rights or resource controls fail | Withhold launch or later use independently of the transition decision. |
These cards preserve a useful positive: an already admitted low-authority native worker remains eligible when the additional transition policy and every independent prerequisite match. They do not demonstrate an exploit, blocked elevation or measured process containment.
Keep resource possession and application outcomes separate
The descriptor worksheet asks which resources cross a different boundary. This article does not change that profile, close any descriptor or claim all existing access disappears. Likewise, stable input bytes and a trusted program are not established by an exec policy.
A future review record should use minimized profile, job and disposition references. Do not publish actual credentials, process metadata, protected paths or note contents to make the evidence look concrete. Actual authority, transition compatibility and output permission remain separate release requirements.
No prctl, execve, OS inspection, LSM operation, runtime import, fixture, API or model action occurred. Boundary is prelaunch and supplies no shipped native launcher or sandbox. Its synthetic policy evidence concerns different behavior.
Primary sources
Official references supporting the guidance. Examples in this guide are synthetic and are not reports of a production incident.