Landlock-Ing Linux

Role of Landlock vs Containers and Other Mechanisms

• Landlock is framed as a “building block” LSM, not a replacement for containers.
• Containers virtualize namespaces and filesystems; Landlock directly restricts what resources a process may access (files, sockets), and stacks with other LSMs.
• Compared to seccomp: seccomp limits syscalls, but a few file-related syscalls can still do a lot; Landlock focuses on per-object access control.
• It is unprivileged and stackable: it can only further restrict access, never grant more, and can be used inside containers.

Usage Patterns, Wrappers, and Tooling

• Main intended use today is inside application code to dynamically drop privileges (e.g., restrict a text editor to its current file, or a component after initialization).
• There is growing interest in using Landlock as a generic wrapper/launcher around untrusted programs (e.g., browsers, games, build tools, LLM agents), with small helper binaries in C/Go and integrations in tools like firejail and Nomad’s exec2 driver.
• Some question why use wrappers instead of systemd’s sandboxing; answer: systemd is admin-driven and static, Landlock lets the app self-adjust permissions at runtime.

APIs, C Library, and Syscalls

• Landlock is exposed via dedicated syscalls and kernel headers, not a central “official” userspace C library.
• Discussion highlights that on Linux the syscall ABI is the primary interface; libc wrappers are optional and often lag.
• Unofficial C, Go, Rust, Haskell libraries exist; kernel docs and sample code show how to use raw syscalls.

Threat Model and Security Philosophy

• Target is defense-in-depth against exploits in otherwise legitimate software, not malware that cooperates with nothing.
• Once restrictions are applied, they are irreversible for the lifetime of the process and its children, even by root.
• This is likened to OpenBSD’s pledge/unveil and macOS/iOS sandboxing: developers voluntarily lock down their own apps.
• Some criticize the idea as “relying on apps to handcuff themselves”; others respond that trusted parents restrict untrusted children, analogous to seatbelts rather than primary barriers.

Limitations, Gaps, and Open Issues

• Networking: current support mainly covers TCP binds; UDP and raw sockets are not yet enforced, seen as a major but acknowledged early-stage gap.
• Kernel design aims for forward-compatible, opt-in feature bits so older kernels are permissive rather than breaking apps.
• Known filesystem gotcha: rules refer to existing directory FDs, so denying paths that don’t yet exist (e.g., a future ~/.ssh) is tricky; workarounds and possible kernel changes are discussed.