Landlock confines a process from inside, with no root and no global policy

The process writes the policy that restricts it. Instead of an administrator maintaining a profile the kernel applies to a program, the program applies the restriction to itself while it runs, and the kernel enforces it from that point on, according to the dev.to post ^[3]. The post's worked example is a webserver told it may read and write only its own document root, with the rule set from the application process itself ^[4]. There is no central policy to maintain and no daemon to install ^[12], so there is nothing for an admin to sign off.

The walkthrough is where I slowed down. The command binds the whole host read-only, mounts /tmp/meine-dateien at /data, and hands /bin/vim to a tool the post calls landlock-create ^[5]. The post says that tool creates a policy allowing read access to /data and nothing else ^[7]. The stated goal was to run vim against a file in that directory without risking system files ^[15]. A read-only rule on the bound directory, sitting under a read-only bind of everything else, leaves the editor no path it can save to ^[1]. The demonstration the post prints is a denial: reaching outside the sandbox with :shell returns "Operation not permitted" ^[8].

Four names in the post are the ones a reader would actually type: the landlock command-line tool, which the post places in the bubblewrap package ^[6]; landlock-create ^[5]; a syscall given as landlock_add_restriction ^[10]; and liblandlock, described as a header-only C library that binds easily into Go or Python ^[11]. The post does not cite a man page or a package version for any of them ^[16]. It also lists AppArmor, SELinux and YaBBR as the well-known LSM implementations ^[9]; I have not met YaBBR. I would check each of those four names against the package contents and kernel headers on the machine meant to run them before pasting the block into a pipeline.

For the central claim to transfer, one thing has to hold on your hosts: the running kernel is 5.13 or newer ^[1]. The floor is the kernel, not the distribution, so an image pinned below that gets nothing from the API whatever packages are installed ^[3].

The author's own position is careful. He writes that he was initially skeptical whether such a feature would ever gain real relevance, since it sits in the defense-in-depth category, and that the more he uses it the more potential he sees, particularly for CI pipelines and local development environments where untested code is run often ^[13]. On the operational point he is flat: needing no background daemon and no maintained global policy is "ein riesiger Pluspunkt für den Daily Use" ^[12]. The in-application example he turns to next, a small service that reads a logfile, breaks off before any code appears ^[14].