Process Security on Nalar

mseal Locks Memory Mapping Layout and Permissions

Fri, 18 Sep 2026 00:00:00 +0000

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.

execveat Binds Program Execution to an Open File Reference

Thu, 17 Sep 2026 00:00:00 +0000

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.

no_new_privs Makes Exec-Time Privilege Gain Irreversible

Thu, 17 Sep 2026 00:00:00 +0000

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.