Landlock Adds Unprivileged Restrictions to Linux Process Authority

A Linux process normally receives authority from credentials, filesystem permissions, namespaces, capabilities, open descriptors, and system-wide security policy. Landlock adds a different control point: a process can voluntarily restrict its own future access, even without administrative privilege. The resulting policy is additive. It narrows what the process may do without granting access that another security mechanism would deny.

That property makes Landlock useful as an application-confinement layer. It also sets a precise boundary around the mechanism. Landlock is not a replacement for discretionary access control, other Linux Security Modules, seccomp, namespaces, or careful descriptor management. It composes with those controls.

A ruleset declares the access it governs

Landlock policy starts with a ruleset. The ruleset declares handled access rights, then rules grant selected handled rights to particular objects. Filesystem rules are associated with file hierarchies. Network rules can constrain supported TCP and UDP port operations when the running Landlock ABI provides those rights.

For an access right listed as handled by a ruleset, access is denied unless a matching rule grants it. Rights outside the handled set are not denied by that ruleset. Creating a ruleset therefore does not implicitly cover every current or future operation.

This distinction supports ABI compatibility. Landlock evolves by adding access rights and capabilities. Applications can query the running ABI and construct policy from the subset supported by that kernel. A binary built against newer definitions should not claim that an older kernel enforces rights it does not provide.

Enforcement can only narrow the current security position

A process creates a ruleset with landlock_create_ruleset(), adds rules with landlock_add_rule(), and applies it with landlock_restrict_self(). Once a thread enters a Landlock domain, that policy cannot be removed from the thread. Additional Landlock layers can impose more restrictions but cannot restore authority denied by an earlier layer.

This monotonic behavior is central to the privilege boundary. An unprivileged process can sandbox itself because Landlock cannot be used to acquire access. Effective access still includes ordinary filesystem permissions and other active controls. A Landlock rule that permits reading a hierarchy does not override a mode bit, ACL, capability check, or another LSM that rejects the operation.

Policy stacking follows the same principle. Within one layer, applicable rules can grant handled rights. Across enforced layers, every layer must permit the access. A child can become more confined than its parent, but a new layer cannot escape inherited restrictions.

no_new_privs closes an execution-time privilege transition

For an unprivileged process, Landlock enforcement requires protection against privilege gain across execution. Traditionally the process sets no_new_privs before landlock_restrict_self(). Newer Landlock ABIs also provide a restriction flag that can tie no_new_privs to successful ruleset enforcement.

Without this boundary, a process could restrict itself and then execute a set-user-ID, set-group-ID, or file-capability program in an environment that the privileged program did not expect. That program could become a confused deputy inside the caller’s imposed domain.

no_new_privs is irreversible and inherited across fork(), clone(), and execve(). Its execve() contract prevents that transition from granting privileges unavailable before execution. It does not remove existing privileges or revoke authority through resources already held by the process.

Filesystem rules follow hierarchy rather than pathname text

Landlock filesystem policy attaches access rights to file hierarchies. This differs materially from filtering pathname strings at a syscall boundary. The kernel evaluates access against filesystem objects and hierarchy relationships rather than trusting an application-level string comparison.

Handled rights distinguish operations such as reading files, reading directories, executing files, creating or removing entries, truncating files, and referring objects across directories when supported by the active ABI. Policy can therefore make one subtree readable, another writable, and leave handled access elsewhere denied.

Renaming and linking deserve special attention because they change namespace relationships. Landlock has dedicated handling for cross-directory refer operations so policy can constrain movement between hierarchies. Asymmetric source and destination rights need to account for those semantics rather than treating rename as an ordinary write.

Existing descriptors can preserve authority acquired earlier

Confinement timing affects the result. Landlock checks do not retroactively invalidate every file descriptor obtained before a domain was enforced. A process that opens a sensitive file and only then enters a restrictive domain may retain useful authority through that descriptor.

Policy applied after resource acquisition cannot be assumed to erase prior capability. Applications should establish confinement before accepting untrusted work and before opening resources that the confined phase should not retain.

Descriptor inheritance is equally relevant. Landlock can restrict future path-based acquisition while an inherited socket, directory descriptor, or writable file descriptor remains a direct route to an already-acquired resource. FD_CLOEXEC, explicit descriptor closure, process architecture, and Landlock policy address different parts of the same authority graph.

Thread scope makes setup order security-relevant

A basic Landlock restriction applies to the calling thread. Descendants created from that thread inherit its Landlock domain. Existing sibling threads are a different case: they are not automatically transformed merely because one thread restricts itself.

Current Landlock interfaces provide process-wide synchronization support when the running ABI implements it. Applications spanning multiple kernel generations still need an explicit compatibility strategy and must check enforcement results rather than assuming every thread entered the intended domain.

A controlled lifecycle reduces ambiguity: initialize required resources, construct policy compatible with the running kernel, enforce confinement, verify success, then expose the confined phase to untrusted input or less trusted components.

Network restrictions control port authority, not packets

Landlock has expanded beyond filesystem access. Supported ABIs can restrict TCP bind and connect operations, and newer ABIs add UDP controls. These rules govern port operations rather than arbitrary packet inspection.

A Landlock network policy is therefore not equivalent to a stateful firewall, packet filter, DNS policy engine, or full network namespace. It narrows selected socket operations available to a process while routing, packet filtering, peer authentication, and protocol semantics remain governed elsewhere.

ABI detection is part of correctness. A policy that depends on a network right introduced in a newer ABI must not describe an older kernel as enforcing that right. Best-effort compatibility can still provide useful hardening, but required security properties need explicit minimum capabilities.

Landlock and seccomp constrain different boundaries

Seccomp filters syscall entry according to syscall metadata and filter actions. Landlock makes access-control decisions about supported kernel objects and operations. Combining them can reduce attack surface in complementary ways.

A process can use seccomp to reject syscall families it never needs while Landlock limits which file hierarchies and network ports remain reachable through allowed syscalls. Neither layer carries the guarantees of the other. Allowing openat() in seccomp does not make every path accessible when Landlock denies it; permitting a hierarchy in Landlock does not require seccomp to allow the syscall used to reach it.

This separation turns a broad claim that a process is sandboxed into concrete questions about syscall surface, object authority, inherited descriptors, credentials, namespaces, and external services.

Compatibility policy determines the failure mode

Landlock is designed for applications that run across kernel versions with different ABI capabilities. Graceful degradation is possible, but it is not automatically a secure choice.

For optional defense in depth, an application may continue with fewer Landlock restrictions on an older kernel. If a required Landlock boundary is necessary before processing hostile data, absence of the needed ABI or failure of landlock_restrict_self() may instead need to be fatal. That decision belongs to the application’s threat model.

A robust integration records which rights were requested, which ABI was available, and whether enforcement succeeded. It avoids claiming protection for unsupported rights and keeps fallback behavior explicit. After successful enforcement, Landlock layers can only narrow process authority; the rest of Linux access control continues to participate in the relevant decisions.