Landlock lets a process lock the door behind itself

Mickaël Salaün presents Landlock's compatibility model in the FOSDEM 2023 Rust devroom. Photograph by Thomas Debesse, cropped, CC BY 4.0.[7]

Most Linux security policy is written from above. An administrator configures an LSM, a container runtime assembles namespaces, or a service manager decides which resources a unit may touch. Landlock makes a different move: an ordinary process can tell the kernel to reduce its own ambient access, then continue running with no way to take that decision back.

That asymmetry is the project’s center of gravity. Landlock cannot grant a file permission, weaken SELinux, or climb out of a parent policy. It can only add another layer of refusal. The result is an access-control mechanism that application developers can ship beside the behavior it protects, without acquiring administrative authority. Mickaël Salaün’s Open Source Summit Europe 2024 talk is worth watching because it explains both halves of that contract: why self-sandboxing can be safe, and why a safe kernel feature can still be integrated badly.[1][2]

The talk is also a study in API restraint. Its practical interface is three Landlock system calls, a ruleset file descriptor, explicit rights masks, and an irreversible transition. Yet the engineering work sits around those small pieces: deciding when to enter the sandbox, probing what the running kernel understands, handling older kernels honestly, and ensuring that every relevant thread crosses the boundary.

Image context: the cover is a real photograph from Salaün’s FOSDEM 2023 session on backward and forward compatibility for security features, illustrated with Landlock. It predates the embedded 2024 talk but shows the same maintainer teaching the same compatibility problem.[7]

The Linux Foundation recorded the following session in Vienna on September 17, 2024 and published it on its official channel. The accompanying slide deck supplies the talk’s code fragments and adoption lists.[1][2]

Around 03:19 — Access control is not the same as packaging

Early in the talk, Salaün moves through virtual machines, containers, system-wide LSM policy, BPF LSM, and seccomp. This is not a winner-takes-all comparison. Each mechanism answers a different question. A VM or container changes an execution environment. Seccomp reduces the syscall surface. SELinux and AppArmor can express system-wide access rules. Landlock instead lets a process restrict access to kernel objects using application-owned policy.[2][4]

The distinction matters because “run it in a container” often collapses several boundaries into one phrase. A container may give a program a narrower view of the filesystem, but the application normally does not own that deployment configuration. A seccomp filter can reject a call by syscall number and arguments, but it is deliberately not a semantic file-authorization system. Landlock can attach allowed filesystem actions to a hierarchy below a path, and its network rules can describe ports. It complements those tools; it does not turn into them. At 07:42, the talk’s sandboxing definition makes the real requirement explicit: the environment should expose only the resources the software is authorized to use.[2]

This framing also explains why Landlock took years to reach mainline. The kernel had to accept policy from a possibly compromised, unprivileged caller without allowing that caller to interfere with other processes or reveal a new privilege-escalation surface. The design converged on rules that only restrict the caller’s domain, stack with existing access controls, and become more restrictive when layers are combined. The maintainer’s design paper and LWN’s account of the upstreaming history make that constraint more visible than a feature checklist does.[5][6]

Around 09:01 — The process may subtract rights, never mint them

The talk’s most important security property appears before its syscall walkthrough: a Landlock policy is monotonic. Around 09:01, Salaün shows nested policies composing; at 14:30, he reduces the idea to descendant inheritance and a one-way set of restrictions. Once a thread enters a Landlock domain, it cannot remove that policy. New rulesets may be layered on later, but access is permitted only when every enforced layer—and the system’s ordinary DAC and other LSM checks—allows it. Newly created child threads inherit the parent’s domain.[2][3][4]

That gives unprivileged self-sandboxing a clean threat model. Imagine an archive extractor that needs to read one input tree and write one output tree. It can finish initialization, describe those two hierarchies, enter its domain, and then parse attacker-controlled bytes. If exploitation redirects the parser toward a credential directory, the compromised process does not possess a Landlock operation that restores its former ambient reach.

Inheritance turns the rule from a one-function guard into a process-tree boundary. But it is not retroactive magic. In the interface shown in the 2024 talk, restricting one thread does not automatically restrict sibling threads that already exist; the calling thread and its future children are covered. Current upstream documentation adds the LANDLOCK_RESTRICT_SELF_TSYNC flag for kernels with ABI 8, allowing synchronized enforcement across the thread group. On older ABIs, an adopter should enter the domain while still single-threaded or deliberately coordinate every thread. “The main thread is landlocked” is not a synonym for “the process is landlocked.”[2][3]

17:10–19:03 — Three syscalls create a domain

The interface section is compact enough to hold in one mental model:

Call landlock_create_ruleset to create a ruleset file descriptor whose handled_access_fs, handled_access_net, and related fields say which kinds of access the policy will govern.
Add object-specific allowances with landlock_add_rule. A LANDLOCK_RULE_PATH_BENEATH rule can allow selected actions below an O_PATH file descriptor; a network-port rule can allow selected binds or connections.
Set PR_SET_NO_NEW_PRIVS when enforcing as an unprivileged process, then call landlock_restrict_self. Close the ruleset descriptor after successful enforcement.

For most rights, the default inside a handled class is denial. If a ruleset says it handles file reads but adds read allowances only beneath /usr and an application-data directory, other file reads are refused. Conversely, a right omitted from the handled mask is generally outside that layer’s policy; it is not silently denied. LANDLOCK_ACCESS_FS_REFER is an intentional historical exception and may be denied even when it is not named as handled. This makes the handled mask—and each ABI-specific semantic—part of the security claim, not boilerplate around the rules.[2][3]

The ordering is equally important. Landlock does not rewind resources already acquired. Upstream documentation is explicit that files or directories opened before sandboxing are not newly subjected to its filesystem restrictions, and access associated with a file descriptor is generally determined when that descriptor is opened. A program should therefore close unintended descriptors and enter its domain before it begins processing untrusted work. Sandboxing after a parser has opened the world is a smaller boundary than the policy text suggests.[3][4]

Rewind to 16:44 — ABI negotiation is a policy decision

Salaün begins the code path by calling landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION). That probe returns the highest Landlock ABI supported by the running kernel. The application then removes rights that older ABIs do not understand before creating its actual ruleset. For example, TCP bind and connect controls begin at ABI 4; the current documentation also describes UDP controls beginning at ABI 10.[2][3]

The subtle point is that compatibility determines what remains protected. Explicit handled rights ensure that a newer kernel does not unexpectedly make an existing application’s sandbox stricter and break it. They also mean an older kernel may enforce only the subset it knows. A program that wants best-effort hardening can mask unsupported rights, log the reduced boundary, and continue. A high-assurance mode may instead decide that the missing right is essential and fail closed. Simply probing an ABI and ignoring the result is neither policy.

The same choice applies when the probe fails. Current documentation distinguishes a kernel without the system call from one where Landlock is disabled. A desktop document viewer might reasonably preserve availability and report that hardening is absent; a tool whose promise is “open this hostile file without network reach” should not quietly run without the network restriction. The appropriate fallback depends on the product contract, but the branch must be explicit and tested.

The 2024 talk’s “current” feature set should also be read as a timestamp, not as frozen documentation. It shows filesystem rights, TCP-port rules, implicit ptrace and mount restrictions, and planned IPC scoping. Upstream documentation in 2026 includes later ABI additions such as signal and abstract-UNIX-socket scoping, thread synchronization, pathname UNIX-socket resolution, UDP rules, and an errata query. The stable lesson is the negotiation pattern; the list of available bits belongs to the headers and documentation shipped for the deployment target.[2][3]

Around 19:23 — Adoption succeeds at the lifecycle boundary

Salaün’s candidate list—parsers, renderers, network services, package tools, container runtimes—has a shared shape. Each can identify a phase after setup when its legitimate resource needs become much smaller. A network daemon may bind a socket, load keys and configuration, drop privileges, install a Landlock domain, and only then accept hostile requests. An image converter may allow one input tree and one output tree before decoding the file.[2]

That phase boundary is a better adoption test than project size. A small CLI with a crisp input/output contract may be an excellent fit. A large application with plug-ins, user-selected paths, late-loaded drivers, and helper processes may need several nested domains or may not yet have a stable point at which to close the door. Applying a broad rule late produces security theater; applying a narrow rule too early produces mysterious breakage.

For a production integration, four tests are more valuable than one happy-path demo:

Run on a kernel with Landlock unavailable and verify the intended fallback.
Run against the oldest supported ABI and assert which protections remain.
Deny each sensitive filesystem or network action and confirm the application fails safely.
Exercise thread creation, process spawning, exec, inherited descriptors, and late-opened resources around the exact enforcement point.

A maintained language wrapper can reduce the risk of hand-rolling version masks, but it cannot choose the product’s fallback or lifecycle boundary. Those decisions belong near the application semantics. Teams also need observable errors: a denied access should lead to a useful diagnostic, while an unexpected failure of landlock_restrict_self must never be treated as successful sandboxing.

Around 24:30 — Landlock is a layer, not a complete sandbox

The talk closes with adoption and roadmap slides, but the strongest conclusion is a boundary statement. Landlock restricts the object-access classes its running ABI supports. It does not validate memory safety, constrain CPU time, filter every syscall, replace UID separation, or make a kernel vulnerability harmless. A robust sandbox may still combine Landlock with seccomp, dropped capabilities, namespaces, resource limits, and a deliberately small privilege boundary.[2][4]

What Landlock changes is who can maintain one important layer. A project no longer has to wait for every distribution or operator to translate application behavior into an external filesystem and network policy. It can ship a testable restriction with the code, negotiate that restriction against the live kernel, and let parent and child policies compose.

The door metaphor is useful only if its hinges are inspected. The policy must be installed before hostile work, on every relevant thread, after unneeded descriptors are closed. Unsupported ABI rights must produce a conscious fallback. Negative tests must prove the forbidden paths really fail. Under those conditions, Landlock’s one-way transition becomes more than a clever kernel API: it gives an application a precise moment at which ambient authority stops being part of its design.

cronfeed.work