A service starts with ordinary filesystem access inherited from its credentials, loads configuration, opens several resources, then begins processing data that may be hostile. Changing UID or entering a container can alter the surrounding authority model, but neither action by itself expresses a narrow rule such as “from this point onward, new reads are limited to these hierarchies and writes are limited to that directory.”
Linux Landlock provides a process-controlled restriction layer for this boundary. A process creates a ruleset, adds object rules, and enforces the ruleset on itself. The resulting Landlock domain is stacked with existing discretionary access control and other Linux Security Module decisions. Landlock can remove access that those mechanisms would otherwise permit; it does not grant access they deny.
Handled rights define the denial surface
A filesystem ruleset begins with landlock_create_ruleset(). Its handled_access_fs mask declares the filesystem actions that this layer intends to control. For most handled actions, an access that is not granted by a matching rule is denied after the ruleset is enforced.
This detail makes the mask part of the security boundary rather than a declaration used only for documentation. If a program omits a supported right from handled_access_fs, that ruleset generally does not restrict that action. LANDLOCK_ACCESS_FS_REFER has special historical semantics: reparenting across directories is denied by a ruleset even when that bit was not declared as handled, while granting it still requires explicit handling and matching rules.
Landlock evolves through ABI versions. Programs can query the running kernel with LANDLOCK_CREATE_RULESET_VERSION and intersect their policy with rights supported by that ABI. Compatibility code must preserve the intended security floor: silently dropping a right can mean the running kernel enforces a narrower policy than the application assumes.
Path-beneath rules attach access to hierarchy objects
Filesystem allowances are commonly added with LANDLOCK_RULE_PATH_BENEATH. The rule references a directory or file through a descriptor and supplies an allowed_access mask that must be a subset of the ruleset’s handled rights.
The rule is object-oriented rather than a permanent string-prefix comparison. Directory rules govern the relevant hierarchy according to Landlock’s filesystem semantics. This avoids treating textual path normalization as the enforcement primitive, while mount topology and filesystem object relationships still matter to the kernel’s access decision.
Rights are deliberately granular. Reading file contents, listing directories, creating regular files, removing files, executing files, truncating files, and reparenting objects are represented separately. A directory that permits LANDLOCK_ACCESS_FS_READ_DIR therefore does not automatically grant LANDLOCK_ACCESS_FS_READ_FILE for every listed entry.
The distinction becomes operationally important for write policy. LANDLOCK_ACCESS_FS_WRITE_FILE controls opening a file for write access, while LANDLOCK_ACCESS_FS_TRUNCATE separately covers truncation behavior on kernels whose Landlock ABI supports that right. A policy that intends to constrain destructive writes needs to account for both operations rather than treating “write” as one indivisible permission.
Enforcement is monotonic within the domain stack
landlock_restrict_self() attaches the ruleset to the calling thread and creates a new Landlock domain layer. Descendants inherit the restrictions. Additional Landlock layers can further reduce authority, but a later ruleset cannot restore access removed by an earlier layer.
This monotonic property permits unprivileged self-restriction without turning Landlock into a mechanism for overriding administrator policy. The effective decision remains the intersection of Landlock layers and the system’s other access-control mechanisms.
Historically, unprivileged enforcement required the caller to set no_new_privs before landlock_restrict_self(), unless it had the relevant privilege. Newer Landlock ABIs add an enforcement flag that can set no_new_privs as part of successful restriction. Software supporting multiple ABIs must follow the contract available on the running kernel rather than assuming the newest interface exists.
Landlock also limits the number of stacked ruleset layers. Repeatedly adding domains throughout a long process tree can therefore become an architectural constraint. Applications that control process creation benefit from treating domain creation as a deliberate lifecycle transition instead of an unbounded per-operation action.
Existing file descriptors preserve earlier authority
Filesystem sandboxing often occurs after startup so a process can open libraries, configuration, logs, or IPC endpoints first. That ordering creates a precise limitation: files or directories opened before Landlock restriction are not retroactively subjected to the new path restrictions in the same manner as new path-based acquisition.
An already-held descriptor can therefore carry authority across the sandbox transition. This is not a policy bypass in the kernel’s model; it is part of the interface contract. The application must decide which descriptors are intentionally retained before entering the restricted domain.
For rights checked and attached at open time, Landlock can also retain restrictions on a descriptor when it is passed to another process. Current kernel design uses this property for operations such as truncation and device ioctl control covered by Landlock rights. Descriptor transfer does not necessarily erase the access constraints associated with acquisition.
This makes descriptor inventory a separate security surface from path rules. A tight hierarchy policy cannot compensate for a privileged descriptor that the process deliberately kept open before restriction.
Filesystem topology and unsupported actions bound the guarantee
Landlock does not mediate every filesystem-related operation. Current kernel documentation lists actions such as chdir(), stat(), chmod(), chown(), and several metadata interfaces among operations that are not fully restrictable through existing filesystem rights. A deployment must state its guarantee in terms of the rights Landlock actually handles.
Sandboxed threads with filesystem restrictions cannot use mount operations to rewrite filesystem topology, which protects the meaning of hierarchy restrictions against that class of modification. chroot() has different semantics and is not itself denied by Landlock.
Special kernel objects also require care. Pipes, sockets, namespace descriptors, and resources exposed through special filesystems do not all behave like regular files governed by path-beneath rules. Landlock has gained separate network and IPC-related controls across later ABI versions, but those mechanisms should not be conflated with filesystem hierarchy policy.
The boundary starts at restriction time, not process birth
Landlock is strongest when the application defines a clear transition from setup authority to runtime authority. Before the transition, the process can acquire the descriptors and data required for operation. At the transition, it constructs a ruleset whose handled rights match the security claim, adds narrowly scoped allowances, and enters the domain. Afterward, new access is constrained by the stacked policy while retained descriptors remain explicit exceptions carried across the boundary.
That model differs from a container-wide policy administered externally. Landlock lets a process narrow its own ambient authority without replacing DAC, capabilities, seccomp, or another LSM. Its useful security property is compositional: each enforced layer can only add restrictions, and the application can place that irreversible reduction at a point where its resource requirements have become smaller and more predictable.