Build1 publisher3 min readPublished
Landlock moves path enumeration out of the AppArmor profile and into the process itself
A dev.to write-up argues that Landlock's unprivileged self-confinement retires the profile-maintenance tax that AppArmor and SELinux impose, though the rules it describes are still paths, so somebody has to enumerate them.
The Engineer · Build desk
What happened
- Landlock is a Linux Security Module introduced in kernel 5.13 that lets a process strictly restrict its own access to files and network objects.
- The restricting call needs no root; according to the dev.to post, only loading the LSM requires privilege, after which unprivileged users work on their own.
- Rules are paths and rights masks, everything not explicitly allowed is blocked, and even /proc and /sys can be filtered, which the author says needs care.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Deciding what a script may read stops being a request to an administrator and becomes part of the command that launches it, so the rules are set by whoever knows the workload.
- constraint Because the rules are still paths, an update that relocates a cache directory can still break the confinement; the failure now surfaces in the launcher a user wrote instead of in a packaged profile.
- capability Running an untested repository or an unknown PDF gets a confinement option that does not require standing up a VM or an LXC container first.
- contradiction The article tells readers to forget static whitelists, then describes rules made of paths and rights masks with everything else denied. That is still a whitelist, only shorter.
Two properties make self-confinement safe to hand to a user with no privileges. Once a process has restricted itself, it cannot extend those rights again, and it cannot recover them through a child process [3]. The call only ever narrows what the caller can reach, and making it requires no root [4]. Root appears once in the sequence the post describes, when the LSM is loaded, and after that normal users work on their own [5][18].
The interface named in the article is a single syscall, landlock_add_restrictions, through which an application or a wrapper declares which directories may be read, written or executed [6]. Anything not explicitly allowed is blocked. Even /proc and /sys can be filtered, and the author advises caution there [7]. For trying it without writing code, the post points to firejail from version 0.9.68, and the supplied text breaks off mid-sentence at that point [14].
The cost the post is complaining about is specific. An AppArmor policy means anticipating every file path an application might touch [8]. When an update moves a config file or a cache directory, the application breaks hard, with an AVC denial [9]. There is no graceful degradation. The author, who wrote such profiles for distribution packages for years, put it as "nur um bei jedem Update zu beten, dass die Pfade nicht wechseln" - only to pray, with every update, that the paths had not changed [10].
What Landlock takes out of that loop is the administrator. The rules themselves are paths and rights masks [4], and the browser example in the post allows exactly two directories, the download directory and Firefox's own profile directory, after which a read of ~/.bash_history fails [15]. A packaged AppArmor profile needs privilege to configure [11] and breaks on every machine that took the update. A Landlock rule set sits in the launcher you wrote, and it breaks for you when you run the thing.
The author puts the learning time at hours, against months for SELinux [13]. For that to transfer, the program you are confining has to touch a small and findable set of directories. Firefox with a download directory and a profile directory is the easy case [15]; a build tool that shells out to four other tools is not. The estimate in the post is an estimate of the learning curve. It does not measure how long it takes to write a working rule set for your own workloads.
The article is clear about where it does not apply. Its author writes that the strength of MAC systems is protecting the host operating system against compromised standard services, the web server being the example given, and that they suit poorly as a dynamic sandbox for individual user actions [12]. In my view that boundary holds. For a long-running daemon with a packager-maintained profile, nothing here displaces AppArmor. For running an untested third-party library from your own account [16], you pay the setup cost and you get the protection.
What to watch
- Whether distributions begin shipping launchers that call Landlock by default, which would move the path list back into packaged wrappers.
- Whether the syscall name the post gives, landlock_add_restrictions, matches the interface readers find on the kernels they run.
- Whether anyone publishes a measured comparison of the time to write a working Landlock rule set against an AppArmor profile for the same program.