Landlock Rulesets Restrict Future Path Access, Not Open File Authority

A process opens a writable configuration file, installs a restrictive Landlock ruleset, and then continues running code that should have access only to a small working directory. The later policy can block a fresh attempt to open that configuration path, yet the descriptor obtained before confinement remains usable. The filesystem view has narrowed, but authority already materialized as an open file has not vanished.

That distinction defines an important Landlock boundary. Landlock is a stackable Linux Security Module designed so processes, including unprivileged ones, can add access restrictions to themselves and their descendants. Its rules govern supported object-access decisions. They do not retroactively revoke every capability represented by resources acquired before the domain was entered.

Rulesets add restrictions instead of replacing system policy

A Landlock ruleset declares access rights that the ruleset handles and attaches rules to supported objects. For filesystem policy, a path-beneath rule can grant selected handled rights beneath a directory. Once the ruleset is enforced, handled operations not granted by matching rules are denied, subject to the semantics of each access right.

This policy is additive to existing controls. Traditional discretionary access control, other Linux Security Modules, mount properties, and object-specific checks continue to apply. A Landlock rule cannot grant an operation that another active control denies. Its role is to remove authority from the process’s effective operating space, not to create an alternate permission universe.

The restriction is also monotonic for a confined thread. Enforcing another ruleset adds another Landlock layer; it does not remove an inherited layer. Children created after enforcement inherit the resulting domain. This property lets an application reduce its own authority as execution progresses without requiring a privileged policy manager to keep the restriction in force.

For an unprivileged process, enforcement normally requires no_new_privs, preventing a later execve() transition from acquiring privilege in a way that could turn the self-imposed policy into a confused-deputy condition. Current Landlock ABIs also define flags that can tie this state transition to successful ruleset enforcement. Applications must negotiate the running kernel’s Landlock ABI rather than assuming that interfaces introduced by a newer ABI exist everywhere.

Handled rights define the policy’s denial surface

Landlock does not treat every conceivable filesystem action as implicitly denied. At ruleset creation, the process identifies supported access rights that the ruleset will handle. Those handled rights form the actions for which the layer can impose default denial outside granted rules.

This detail matters across kernel versions. Newer Landlock ABIs add access rights and other capabilities. A binary built with newer headers may know about rights that an older running kernel does not support. Robust policy construction queries the Landlock ABI and limits its requested feature set accordingly. Silently omitting a right can leave an operation outside that layer’s control; blindly requesting unsupported bits can make ruleset creation fail.

Filesystem rights are also more granular than a simple read-versus-write split. Execution, file reads, directory reads, writes, truncation, removal, creation of different object types, and cross-directory reparenting have distinct policy semantics. An application that grants write access but neglects the separate operation relevant to its workload can fail unexpectedly. The inverse is more serious for confinement: an operation not represented among the rights handled by the active ABI cannot be treated as blocked merely because nearby operations are restricted.

Kernel documentation explicitly lists filesystem actions that Landlock does not currently mediate. The set changes as the interface evolves, so a deployment’s security claim has to be tied to the ABI and kernel behavior it actually runs.

Open descriptors cross the path-policy transition

Filesystem confinement often gets described in path terms because rules are attached beneath filesystem objects. Open file descriptors expose a different lifetime. Linux resolves a pathname during operations such as open(), performs relevant access checks, and returns a descriptor referring to the opened file description. Later I/O can proceed through that descriptor without repeating the original pathname lookup.

Landlock follows that object lifetime. Files opened before sandboxing are not retroactively subjected to the later filesystem restrictions. If a process intentionally or accidentally keeps a writable descriptor to a file outside its new domain, ordinary operations permitted by that descriptor can remain available after landlock_restrict_self() succeeds.

Some Landlock rights are checked when a file is opened and become associated with what may later be done through the descriptor. That design keeps equivalent operation sequences consistent inside a domain, but it does not convert confinement into descriptor revocation. The moment at which the resource is acquired remains part of the security model.

Descriptor inheritance extends the issue across process boundaries. A descriptor without close-on-exec protection can survive execve(). A launcher that enters a narrow Landlock domain and then executes less-trusted code therefore has to account for every inherited descriptor, not only the paths visible to the executed program. Landlock and descriptor hygiene protect different dimensions of the same authority graph.

Path-based policy becomes more subtle when filesystem objects can move between directories or gain additional names. Landlock models cross-directory reparenting with LANDLOCK_ACCESS_FS_REFER, while creation and removal rights still apply at the destination and source as appropriate.

The kernel also prevents a reparenting operation from giving an object more Landlock access through its destination than it had through its source. This constraint avoids using rename or link operations as a route to expand authority inside a confined domain. Depending on the failed condition, the operation can produce EACCES or EXDEV, so application error handling should not assume that every policy denial has one uniform errno.

These semantics show that a directory rule is not merely a textual pathname prefix. Landlock participates in kernel object and hierarchy checks. Hard links, mount topology, rename behavior, and descriptor lifetime all make filesystem authority richer than string matching.

Landlock and seccomp constrain different boundaries

Seccomp filters system-call entry according to syscall metadata. Landlock mediates supported access to kernel objects according to an access-control policy. The distinction is operational rather than cosmetic.

A seccomp profile might permit openat() because an application needs to open files, while Landlock narrows which filesystem objects those permitted calls can reach. Conversely, a Landlock domain can restrict file access while leaving a broad syscall surface available. Neither mechanism subsumes the other.

The same composition principle applies to credentials, namespaces, network policy, and other LSM controls. Landlock can add a meaningful object-access boundary without proving that the entire process is isolated. Its protection is limited to the object classes, rights, scopes, and ABI features that the running kernel supports and the application actually configures.

Confinement begins before the ruleset is enforced

A self-restricting process has a setup phase in which it still possesses the authority needed to initialize itself. Files opened, sockets connected, memory mappings created, and descriptors inherited during that phase can shape what remains possible later. Calling landlock_restrict_self() is therefore a boundary in an authority lifecycle, not a mechanism that erases earlier state.

A credible design inventories resources before that transition, closes descriptors that should not survive it, uses close-on-exec semantics where appropriate, and treats successful ruleset enforcement as a checked condition. It also defines fallback behavior for kernels where the required Landlock ABI or access rights are unavailable. Continuing without the intended restriction can be acceptable for compatibility in some applications, but it is not equivalent to successful confinement and should not be represented as such.

Landlock’s value comes from a narrow property: an application can irreversibly add supported access-control restrictions to its own execution domain without requiring those restrictions to replace the system’s existing policy. The boundary becomes precise only when pre-existing descriptors, ABI coverage, unmediated operations, and inherited authority remain visible in the security model.

Cybersecurity Linux Security Landlock Sandboxing