A service can begin with ordinary filesystem permissions that are broader than the files it needs during steady-state operation. Changing ownership or mount topology may be impractical because the same host resources are shared with other processes. Linux Landlock addresses this gap by letting a process add a kernel-enforced access restriction to itself and, through inheritance, to descendants.
Landlock is a Linux Security Module designed for sandboxing. Its rules do not grant filesystem access that DAC, ACLs, capabilities, or another security mechanism would otherwise deny. They add another authorization layer. An operation succeeds only when the other applicable controls and the Landlock policy permit it.
That composition makes Landlock useful as a confinement boundary, but it also sets its main limit: a ruleset is not a replacement for the host’s primary ownership and privilege model.
The handled access set defines the policy surface
A filesystem ruleset declares access rights in handled_access_fs. These bits identify operations for which the ruleset intends to make decisions. Rights vary across Landlock ABI versions, so software must determine which ABI the running kernel supports and construct a compatible policy.
This distinction matters when a program built against newer headers runs on an older kernel. A right known to the program is not automatically enforced merely because its symbolic constant exists at build time. Policy construction has to account for the kernel ABI that is actually available.
Once a right is handled, access for that right is denied unless the ruleset grants it through an applicable rule. Rights outside the handled set are not restricted by that ruleset. A policy that omits a relevant right can therefore leave an operation outside the intended Landlock boundary even though nearby operations are constrained.
The security property comes from the exact handled set, not from the presence of a Landlock ruleset alone.
Path-beneath rules bind authority to filesystem objects
Filesystem policy is commonly expressed with LANDLOCK_RULE_PATH_BENEATH. The rule refers to a parent file descriptor and an allowed_access mask. This associates allowed actions with the referenced filesystem hierarchy rather than storing a textual pathname as the policy object.
That object-based model avoids treating a path string as permanent identity. Renames and mount behavior still require careful policy analysis, but the rule itself is attached using a file descriptor that the kernel resolves to a filesystem object.
A typical policy can grant read-oriented rights beneath one hierarchy and write-oriented rights beneath another. The granted mask for a rule must remain within rights the ruleset handles and rights supported for the relevant object and ABI.
Landlock does not make the parent file descriptor an application capability that bypasses other checks. The descriptor is used while constructing the rule. Subsequent filesystem operations remain subject to the composed kernel authorization path.
Restriction is applied to the calling thread
After creating a ruleset and adding its rules, a process applies it with landlock_restrict_self(). For an unprivileged caller, the documented setup includes setting no_new_privs before restricting itself. This prevents a later executable transition from being used to gain privileges that would undermine the confinement model.
The restriction applies to the calling thread and is inherited by children created afterward. In a multithreaded program, policy installation therefore has to be placed deliberately in the process lifecycle. Restricting one thread does not retroactively transform unrelated threads into a single atomic sandboxed unit.
A robust architecture installs confinement before untrusted work begins and before worker creation when all workers are intended to share the same boundary. The placement of landlock_restrict_self() is part of the security design, not merely initialization detail.
Rulesets can tighten authority but cannot restore it
Landlock restrictions compose so that additional layers can further reduce permitted operations. A process cannot use a later Landlock ruleset to recover access removed by an earlier one.
This monotonic property is valuable for staged applications. A launcher can impose a broad outer boundary, then a worker can add a narrower policy for a specific task. The worker does not need authority to rewrite the launcher’s policy.
The same property means policy mistakes cannot be repaired inside the confined process by installing a more permissive layer. If required access was removed, the process must operate within that restriction or be replaced by a process created under the intended policy.
Landlock therefore works well when privilege reduction follows application phases: acquire resources, establish the sandbox, then execute code that should operate with a smaller filesystem surface.
Existing descriptors remain a separate authority channel
A filesystem sandbox has to account for file descriptors opened before confinement. Landlock’s pathname-oriented filesystem mediation does not imply that every operation on every already-open descriptor is revoked at ruleset installation.
This is a broader sandbox design issue: access obtained before a boundary can survive in kernel objects already held by the process. Open files, sockets, memory mappings, and other handles need explicit lifecycle treatment according to the guarantees of the mechanisms governing them.
A service that opens a sensitive file and then installs a Landlock policy excluding its pathname should not infer that the earlier descriptor has become harmless. Descriptor inheritance and pre-opened resources must be audited separately.
The practical boundary is therefore the combination of Landlock policy and the authority already present in the process at the moment confinement is applied.
Filesystem topology still affects policy meaning
Path-beneath rules are evaluated against kernel filesystem objects, but deployment topology still matters. Bind mounts, separate mounts, runtime-created directories, and filesystem changes can alter which objects are reachable through application paths.
A policy should be derived from the filesystem view visible to the confined process. If mount namespaces are also used, the order in which the namespace is assembled and Landlock is applied affects the resulting environment. Landlock does not create a mount namespace or hide directory entries by itself.
This separates two properties that are often conflated. Namespace mechanisms shape what filesystem tree a process can see; Landlock constrains selected actions against objects in that environment. Combining them can produce a tighter sandbox, but each mechanism retains its own enforcement semantics.
ABI negotiation is part of the security contract
Landlock has evolved through ABI versions that add access rights and features. Portable software should query the supported ABI and map its intended policy to capabilities available on that kernel.
Fallback behavior must be explicit. If a required right is unavailable, silently dropping it can produce a weaker boundary than the application assumes. Depending on the threat model, a safer response can be to reject startup, select a deliberately reduced feature mode, or use another confinement mechanism.
This is not only a compatibility concern. The policy expected by application code and the policy enforced by the running kernel must match closely enough for the stated security boundary to remain valid.
Landlock is strongest when treated as a precise reduction of existing authority: the application identifies the filesystem actions that matter, verifies kernel support, installs object-based rules, removes unnecessary pre-existing handles, and enters the restricted phase. The kernel then enforces that added boundary alongside the system’s other access controls.