Process Security

Cybersecurity 19 Sep 2026 5 min read

no_new_privs Blocks Exec-Time Privilege Gain

A service may need to execute helper programs after it has accepted untrusted input. If one of those programs is set-user-ID, set-group-ID, or carries file capabilities, a normal execve() can cross a privilege boundary even when the calling process itself has no intent to acquire extra authority. Linux no_new_privs changes that transition: once set for a thread, later execve() calls cannot grant privileges that were absent from the caller at the point of execution.

Cybersecurity Linux

Linux 18 Sep 2026 5 min read

mseal Locks Memory Mapping Layout and Permissions

A process can establish a memory mapping with the intended address, size, and protection bits, then later alter that mapping with operations such as munmap(), mprotect(), or mremap(). Linux mseal() adds a one-way state transition: selected virtual memory areas can be sealed so a class of later mapping modifications is rejected by the kernel. The mechanism protects mapping structure rather than the bytes stored in the mapping. A writable sealed mapping remains writable through ordinary stores. Sealing instead constrains operations that could remove the mapping, relocate it, replace it, or change attributes covered by the sealing rules.

Linux Memory Management

Cybersecurity 17 Sep 2026 5 min read

no_new_privs Makes Exec-Time Privilege Gain Irreversible

no_new_privs Makes Exec-Time Privilege Gain Irreversible A Linux service may deliberately execute programs that carry set-user-ID bits or file capabilities while intending to remain at its existing privilege level. Without an explicit execution boundary, execve() can be a privilege transition: metadata on the executable may change effective credentials or contribute capabilities to the new program. The no_new_privs task attribute changes that transition. Once set, a successful execve() cannot grant the task privilege that it could not exercise before the call. The attribute is inherited by descendants, survives execution, and cannot be cleared. Those properties make it a one-way constraint on a process lineage rather than a temporary option around one executable.

Cybersecurity Linux

Cybersecurity 17 Sep 2026 5 min read

execveat Binds Program Execution to an Open File Reference

A launcher selects an executable from a directory, checks attributes or content, and then starts it. If selection and execution each resolve the pathname independently, a rename, symlink change, or directory replacement between those operations can make the executed object differ from the object that was checked. Linux execveat() can move that boundary from a second pathname lookup to an already acquired file reference. With AT_EMPTY_PATH, an empty pathname tells the kernel to execute the object referred to by dirfd. That descriptor may have been opened with O_PATH. The execution decision still passes through normal kernel permission and executable-format checks, but object selection no longer depends on resolving the original pathname again.

Cybersecurity Linux Security