Landlock is a Linux security feature that lets any process, including an unprivileged one, restrict its own access to parts of the filesystem and to certain network ports. Seccomp instead filters which system calls a process may make. Landlock limits what a process can touch, and seccomp limits what it can ask the kernel to do.
What the kernel documentation says
The Linux kernel's Landlock documentation states its goal as restricting ambient rights, such as global filesystem or network access, for a set of processes. It is a stackable Linux security module, so it adds a layer on top of the system wide access controls already in place. The aim is to mitigate the impact of bugs or malicious behavior in user space applications.
Two points make it useful for developer tools. First, a process needs no special privilege to apply it to itself. Second, restrictions apply to the thread that enforces them and to its future children, so a launcher can restrict itself and then start the risky program.
How rules work
A rule describes an action on an object. Rules are collected into a ruleset, which then restricts the enforcing thread. The documentation lists two rule types:
- Filesystem rules, where the object is a file hierarchy and the actions are filesystem access rights such as reading files or writing files.
- Network rules, where the object is a TCP or UDP port. The page says TCP rules arrived with ABI version 4 and UDP rules with version 10.
The ruleset must declare every kind of access it handles, and anything handled but not explicitly allowed is denied. This is done for compatibility between kernel and user space versions. The documentation recommends a best effort approach: detect the Landlock ABI version at run time and use only the rights the kernel supports.
You can check whether Landlock is active by looking for the message that it is up and running in kernel logs. Support depends on how the kernel was configured.
Landlock and seccomp compared
| Question | Seccomp | Landlock |
|---|---|---|
| What does it restrict? | Which system calls can be made | Access to file hierarchies and network ports |
| Unit of policy | A filter over call numbers and arguments | A ruleset of allowed paths and ports |
| Needs privilege to apply? | Needs no new privileges set, or an admin capability | Unprivileged processes can apply it to themselves |
| Typical use | Remove dangerous calls from reach | Confine a program to the folders and ports it needs |
The seccomp column follows the seccomp manual page, which requires either the admin capability or the no new privileges bit before a filter is installed.
Using them together
They guard different surfaces. Seccomp can remove system calls a tool never needs. Landlock can confine the same tool to its working folder and block network access it does not use. Neither is a complete sandbox on its own. The gVisor documentation points out that these kernel primitives still leave the workload talking to one shared kernel and need careful per workload configuration.
For developer tooling, a reasonable pattern is: set no new privileges, apply a Landlock ruleset limited to the project folder, apply a seccomp filter, and run as a non root user. For where a stricter boundary belongs, see which sandbox fits which code.
Safeguard does not enforce Landlock rules. It scans dependencies and images and can enforce policy gates, with a free scan at gold.safeguard.sh/scan.
Quick check
Does Landlock need root?
No. The documentation says it lets any process, including unprivileged ones, restrict itself.
Can Landlock replace seccomp?
They cover different things. Landlock controls access to files and ports, while seccomp controls system calls, so they are complements.
Sources
- Landlock: unprivileged access control, Linux kernel documentation
- seccomp(2), man7.org
- Introduction to gVisor security, gVisor
Last reviewed: 19 October 2026.
