Landlock Usage Checklist

This is a checklist of things to consider when using Landlock.

Design decisions

Understand which of the two main use cases your program falls into:

Case 1: Opportunistic Use

In the Opportunistic use case, the goal is to use Landlock restrictions opportunistically, but fall back to weaker enforcement if necessary.

• In this case, you’ll want to use a “best effort” fallback approach, falling back to “no enforcement” if Landlock is unavailable.
• This is sometimes necessary if your programs are deployed very widely, also on platforms where Landlock is not available.

Case 2: Giving strong guarantees

If you want to rely on Landlock to give certain guarantees, you want to make sure that:

1. Landlock was present during enforcement at a fixed minimum Landlock ABI version.
2. Fail the enforcement (and possibly the subsequent program execution) otherwise.

Have an upgrade plan

• Make use of new Landlock ABI versions if you can.
  • The higher the ABI version, the more you can restrict your process.
• Revisit your implementation periodically and see whether you can make use of more restriction features.
  • For compatibility reasons, the use of new Landlock restriction features requires a conscious code change, both in the system call API and in the official Landlock libraries.

Language-specific guidance

• In Go, we recommend using the offical Go-Landlock library.
  • Usage and upgrade guidelines are linked from the Go-Landlock README file.
  • Users who have already started out with using raw syscalls can check their implementation against the Go-specific recommendations for Raw Syscall use.
• In Rust, we recommend using the offical Rust Landlock library.
  • Documentation is linked from the Rust-Landlock README file.

Checklist and corner cases

• Treat LANDLOCK_ACCESS_FS_WRITE_FILE and LANDLOCK_ACCESS_FS_TRUNCATE the same
  • If you restrict *_WRITE_FILE, also restrict *_TRUNCATE and vice versa.
  • If you allow *_WRITE_FILE with a rule, also allow *_TRUNCATE and vice versa.
  • Exception: If you have to fall back to ABI v2 (before *_TRUNCATE existed), you can not use the *_TRUNCATE access right.
• Do not fall back to ABI v1 if you require renaming or linking of files across directories.
  • LANDLOCK_ACCESS_FS_REFER covers rename and linking operations between separate parent directories. When using Landlock at ABI v1 level, these operations are always restricted, even when LANDLOCK_ACCESS_FS_REFER is not “handled” in the ruleset.
  • The Go-Landlock and Rust-Landlock libraries handle this transparently in their best-effort handling.
• Multithreading: In multithreaded programs, make sure that all threads are restricted into the same Landlock domain. Threads do not generally have good security boundaries between each other.
  • Solution A: Enforce the Landlock ruleset before any of the threads are spawned. That way, new threads are inheriting their Landlock domain from the spawning thread.
  • Solution B: If the program is already multithreaded at the time of enforcement, use LANDLOCK_RESTRICT_SELF_TSYNC to apply the ruleset to all threads in the process. (Requires Landlock ABI v8+)
    • Before ABI v8, you can use libpsx to apply single-threaded enforcement to all threads in a process in parallel.
• Networking: The Landlock support for TCP and UDP port bind(2) and connect(2) only covers these operations for these specific protocols. Specifically, other protocols are not restricted in the same way and must be dealt with separately (e.g., with seccomp-bpf, see below).

Known gaps

Landlock provides a growing list of building blocks for sandboxes, but at the time of writing (2026-11), it does not provide full confinement. Commonly, it is therefore combined with Seccomp-BPF rulesets that cover the remaining gaps.

The following list documents suggested system calls which Landlock does not currently adequately confine and which can be addressed with Seccomp-BPF.

The list of Linux system calls is growing over time and your program might eventually run on a Linux kernel that has more system calls than existed at the time of policy definition.

It is therefore recommended to use allow-lists (not deny-lists) with Seccomp-BPF.

Inotify and Fanotify

The inotify(7) and fanotify(7) interfaces let a process watch files and directories for activity. They are not restrictable with Landlock at the moment.

• inotify_init
• inotify_init1
• inotify_add_watch
• inotify_rm_watch
• fanotify_init
• fanotify_mark

Non-socket local IPC

These IPC mechanisms are not currently restrictable with Landlock and should be turned off if they are not required:

For POSIX message queues, please see: LandlockPosixMessageQueueControl

File Metadata

Read and write access to file metadata is not restrictable with Landlock yet.

• Read: Stat/Statfs family
  • stat
  • lstat
  • fstat
  • newfstatat
  • statx
  • statfs
  • fstatfs
• Read: Existence and permission probing
  • access
  • faccessat
  • faccessat2
• Read: Others
  • readlink
  • readlinkat
  • name_to_handle_at
  • statmount
  • listmount
• Read/Write: Quota accounting
  • quotactl
  • quotactl_fd
• Read: Extended attributes
  • getxattr, lgetxattr, fgetxattr, getxattrat
  • listxattr, llistxattr, flistxattr, listxattrat
• Write: Extended attributes
  • setxattr, lsetxattr, fsetxattr, setxattrat
  • removexattr, lremovexattr, fremovexattr, removexattrat
• Modify: Timestamps
  • utime, utimes, futimesat, utimensat
• Modify: Chmod and Chown variants
  • chmod, fchmod, fchmodat fchmodat2
  • chown, lchown, fchown, fchownat

An ongoing related patch set: LandlockMetadataControl

Networking Gaps

• Block socket(2) calls depending on parameters: Entry point for the use of sockets; this decides the socket family and type, so you can block out network protocols that you don’t need; has been discussed as Landlock feature in LandlockSocketTypeControl
  • Recommendation: Only allow socket(2) operations with family, type and protocol values that your program actually uses.
  • Recommendation: Also make sure that io_uring can not be used to create sockets (e.g., by restricting io_uring altogether, see below).
• Block listen(2): Landlock only blocks bind(2), not listen(2), so you can still listen on ephemeral ports

An ongoing related effort: BigLandlockNetworkingFix

io_uring

io_uring is an asynchronous command multiplexer which can be used to do the equivalent of system calls. Commands issued through io_uring are not subject to regular Seccomp-BPF filters.

If you do not use io_uring, you might want to restrict its creation by blocking:

• io_uring_setup
• io_uring_enter
• io_uring_register

Another problem: It is possible to set up io_urings which capture the process credentials at creation time and where the actions performed later through the io_uring then use these older credentials. If such an io_uring exists in the process, a later Landlock confinement will have no effect on the operations done through that io_uring.

Access to other processes

• capget – can read the capabilities(7) of other processes
• getpgid, getsid – can read process group and session IDs of other processes

Please report bugs to gnoack3000@gmail.com.