Linux Landlock

What Landlock Changes About Filesystem Control

Linux Landlock adds unprivileged, per-process filesystem confinement on top of the normal Linux permission model. That matters because it lets software restrict itself after startup, reducing the blast radius if the process is later compromised.

How Landlock Fits with the Linux Security Model

Landlock is not a replacement for traditional discretionary access control or kernel hardening. It works as an additional containment layer, so the process still needs its ordinary permissions, but its future filesystem actions can be narrowed further by policy.

That makes Landlock especially useful when an application handles untrusted input, loads plugins, or executes code paths that should not keep broad file access for the life of the process. A process can keep running normally while being denied access to paths that are not needed for its task.

Practical Uses and Policy Boundaries

The most useful Landlock policies are narrow and task-specific. They are usually built around the idea that a process should be able to read only the files it needs, write only to approved locations, and avoid creating a reusable foothold in the broader filesystem if it is exploited.

Because Landlock focuses on filesystem operations, it is strongest when paired with other controls for network access, memory safety, privilege separation, and service isolation. It is a containment mechanism, not a full sandbox for every kind of resource.

Why Landlock Matters for Compromise Containment

Landlock becomes most valuable after a bug, deserialization flaw, plugin issue, or injected payload turns a legitimate process into an attacker-controlled one. If the process can no longer traverse sensitive directories or alter executable content, the attacker has less room to stage persistence or tamper with local assets.

The main security value is reducing what a compromised workload can do, even when the initial exploit cannot be prevented in time. That shifts the security goal from perfect prevention to limiting post-compromise damage.

Risk and Threat Considerations

Landlock can create a false sense of containment if teams assume filesystem sandboxing alone will stop compromise. If policy scope is too broad, or if the process still has other powerful paths such as inherited credentials, writable service directories, or indirect execution routes, an attacker may still achieve meaningful impact.

Failure mechanism: A policy that does not cover the files, directories, or writable paths the process can actually reach leaves room for data theft, tampering, or persistence even after confinement is enabled.

Impact: A compromised process may still read secrets, overwrite trusted files, or prepare a later-stage attack unless Landlock is combined with least privilege and complementary isolation controls.

Practitioner Guidance

What to watch for: Use Landlock where the application has a clear filesystem boundary, especially for tools that process uploads, render content, run extensions, or execute user-driven workflows. The policy should match the real file access pattern of the process, not an idealised one.

Governance implication: Treat Landlock as a defense-in-depth control that should be reviewed alongside application behavior, service ownership, and rollout testing. If a process needs broad file access to function, that design choice should be explicit rather than accidental.

Related resources from NHI Mgmt Group

• How should teams respond to a local Linux privilege escalation flaw in shared environments?
• How should security teams handle weak credentials on exposed Linux services?
• How can teams spot proxy abuse on compromised Linux systems?
• How should security teams govern SSH certificates in Linux environments?