A service may start with every filesystem permission granted to its Unix identity, yet only need a small subset after initialization. Changing the service account or mount topology can reduce that authority, but both are deployment-wide decisions. Linux Landlock provides a different boundary: a process can add restrictions to itself and its descendants without receiving privilege to grant new access.
Landlock is a stackable Linux Security Module. Its rules are additional constraints, not replacements for discretionary access control, capabilities, or other active LSM policy. A Landlock rule cannot turn a denied operation into an allowed one. It can only remove authority that the process would otherwise possess.
Restriction is additive and one-way for a domain
A process constructs a ruleset, adds rules, then calls landlock_restrict_self() to enter the resulting Landlock domain. The ruleset identifies access classes that the layer handles and exceptions that remain permitted within those classes.
Once enforced, the domain cannot be relaxed by the restricted thread. Additional Landlock layers can narrow access further. Threads created from a restricted thread inherit its Landlock restrictions, so a launcher can establish a boundary before executing less-trusted application code.
This monotonic property is central to the security model. Landlock does not require an unprivileged process to become an access-control administrator. The process can reduce its own ambient authority, but it cannot use Landlock to enlarge that authority or remove restrictions inherited from an ancestor.
Landlock restrictions also compose with ordinary kernel checks. A path permitted by a Landlock ruleset can still fail because Unix mode bits, ACLs, mount state, another LSM, or another kernel policy denies the operation.
handled_access_fs defines the deny surface
Filesystem rulesets do not implicitly mediate every possible filesystem action. At ruleset creation, handled_access_fs declares the filesystem access rights that the ruleset intends to handle. For handled rights, access is denied unless a matching rule grants the requested operation. Rights outside that handled set are generally outside that layer’s decision surface.
This distinction makes ABI negotiation security-relevant. New Landlock ABI versions add access rights. Software built with newer headers must query the running kernel’s Landlock ABI and restrict its requested rights to features actually supported there. Kernel version strings are not a reliable substitute because features may be backported.
LANDLOCK_ACCESS_FS_REFER has a historical special case: cross-directory reparenting is denied by Landlock rulesets even when that bit is not declared as handled. Granting it requires explicit handling and a matching rule. Code that performs cross-directory rename or hard-link operations therefore needs deliberate compatibility behavior on older Landlock ABIs.
A policy that silently omits an unsupported right has a precise consequence: that Landlock layer cannot enforce the omitted restriction. Graceful compatibility may be operationally useful, but it must not be described as equivalent confinement.
Path-beneath rules attach policy to file hierarchies
Filesystem exceptions are commonly added with LANDLOCK_RULE_PATH_BENEATH. The rule refers to a directory or file through an opened file descriptor and grants selected access beneath that hierarchy.
The policy is hierarchy-oriented rather than a string-prefix filter. This matters for hard links, renames, mounts, and other namespace behavior. Access rights are tied to kernel objects and hierarchy relationships, not to a textual pathname captured at policy construction time.
Directory rights also have distinct scopes. LANDLOCK_ACCESS_FS_READ_DIR applies to reading directory contents, while rights such as LANDLOCK_ACCESS_FS_REMOVE_FILE, LANDLOCK_ACCESS_FS_MAKE_REG, and LANDLOCK_ACCESS_FS_REFER govern operations involving entries in a directory. Permission to list a directory does not itself grant permission to open every file listed there.
Landlock therefore does not collapse filesystem authorization into a single read/write flag. A useful boundary depends on the actual operations the process performs: traversal and listing, opening file contents, creating names, deleting names, executing files, truncating data, moving objects between directories, and device-specific operations can occupy different access classes.
Open file descriptors can cross the policy transition
Applying a Landlock domain does not retroactively revoke ordinary read or write authority already embodied in file descriptors opened before restriction. Kernel documentation explicitly treats files opened before sandboxing as outside those filesystem restrictions for subsequent ordinary file access.
This creates an important transition boundary. A process that opens a sensitive file, enters a Landlock domain that would deny opening that path, and retains the descriptor may still be able to use the pre-existing descriptor according to the permissions established when it was opened.
Some newer Landlock rights are associated with descriptors at open time. For example, the ability to use ftruncate() under LANDLOCK_ACCESS_FS_TRUNCATE, and device ioctl() mediation where supported, depends on rights associated with the opened file description. Two descriptors referring to the same inode can therefore carry different Landlock-relevant authority when they were opened across a policy transition.
Descriptor passing preserves this concern across process boundaries. A filesystem sandbox should consequently account for descriptors inherited through fork() or execve(), received over Unix sockets, or deliberately retained by a launcher. Path policy and descriptor inventory are separate parts of the same confinement design.
Rename and link operations span two hierarchy decisions
Moving a filesystem object between directories is not equivalent to opening a file in one directory. The operation changes the hierarchy that governs future access. Landlock consequently applies additional constraints to cross-directory rename and link operations through LANDLOCK_ACCESS_FS_REFER.
For a permitted reparenting operation, relevant source and destination hierarchy rights must be present. The destination also must not give the moved object more Landlock access than it had at the source. An attempted move that would gain rights can fail with EXDEV; missing create or remove permissions can instead produce EACCES.
This prevents a writable low-authority hierarchy from becoming a route for placing an object into a hierarchy with broader Landlock grants. It also means application behavior that relies heavily on atomic rename between staging and destination directories must be represented explicitly in the policy rather than treated as ordinary write access.
Landlock does not mediate every filesystem operation
The boundary is intentionally incomplete and evolves by ABI. Current kernel documentation lists filesystem operation families that are not fully restrictable through Landlock access rights, including operations associated with chdir(), stat(), flock(), chmod(), chown(), extended attributes, timestamps, fcntl(), and access().
That limitation changes the claim a deployment can make. A Landlock filesystem policy can constrain the access classes supported by the running ABI; it is not a universal reference monitor for every property or metadata operation on a filesystem object.
The same precision applies beyond files. Later Landlock ABIs add selected network restrictions and IPC scopes. Their presence must be detected through the ABI and configured explicitly. A filesystem-only ruleset does not imply network isolation, and a process in a Landlock domain is not automatically separated from every IPC mechanism.
Domain placement determines which execution inherits the boundary
Landlock restriction is attached to the calling thread and inherited by descendants. It is not automatically imposed on already-existing sibling threads. In multithreaded software, applying a policy after worker creation can therefore leave threads in different Landlock domains.
A launcher model avoids that ambiguity: establish required resources, close unintended descriptors, create and populate the ruleset, restrict the launcher thread, then create descendants or execute the target program. Application-integrated designs can also work, but thread creation order becomes part of the security contract.
The same inheritance property supports composition. A parent can establish a broad sandbox, and a child can add a narrower Landlock layer for one phase of work. The child cannot escape the parent’s layer merely by constructing a different ruleset.
Landlock narrows ambient authority without redefining ownership
Landlock’s strongest architectural property is separation between possession of operating-system credentials and possession of usable authority inside a process subtree. The Unix identity may retain permission to a broad filesystem, while a Landlock domain removes selected operations from one execution branch.
That separation is useful only when its boundaries remain explicit. ABI support determines which actions can be mediated. The handled-rights mask determines which supported actions this layer denies by default. Path rules determine permitted hierarchy operations. Existing descriptors can retain authority across the transition, and unrelated kernel access-control layers continue to make independent decisions.
The result is a process-local restriction mechanism rather than a new source of privilege. Its security value comes from making ambient authority smaller at the point where application code no longer needs it.