Landlock is a Linux API that lets applications explicitly declare which resources they are allowed to access. Its philosophy is similar to OpenBSD’s
unveil()and (less so)pledge(): programs can make a contract with the kernel stating, “I only need these files or resources — deny me everything else if I’m compromised.”It provides a simple, developer-friendly way to add defense-in-depth to applications. Compared to traditional Linux security mechanisms, Landlock is vastly easier to understand and integrate.
This post is meant to be an accessible introduction, and hopefully persuade you to give Landlock a try.
↫ prizrak.me blog
I had no idea this existed, even though it seems to plug a hole in the security and sandboxing landscape on Linux by not requiring any privileges and by being relatively simple and straightforward to use. There’s even an additional “supervisor” proposal that would bring Android-like permissions not just to, say, desktop applications (see Flatpak), but to every process trying to access anything for the first time.
I’m not knowledgeable enough to make any statements about Landlock compared to any other options we have for securing desktop Linux in a user-friendly, non-intrusive manner, but I definitely like its simplicity.
They mention Android, and it is … or rather a very similar thing is heavily used in there.
Android requires apps to declare intents (not sure the term is called). So, you want to access SD card? You have to declare that in the manifest. You want to serve ads? You need Internet access. Joking of course, it is enabled by default 🙂
But I’m not sure how this will work for Linux command line. By definition things get what they need to access from command line arguments, and many times by resolving config files. Yes, this could be useful for desktop applications “The Music Jukebox will only access its config, the graphical resources, and of course user selected music content”. But for ls? cat? find? git? Things become trickier…
(I get this is more for “sandboxed” execution of random things we install like npm, conda, or uv. But… that is an entirely different issue. If you don’t trust an installer of a library, how can you trust the library to do the right thing at runtime)?
Supposedly Android uses selinux to implement it.
Lennie,
I believe so as well.
Of course system enforced SELinux restrictions would be better than “self imposed” ones like landlock. However it would be in the “better than nothing” category for certain package managers.
I think we “lost the plot” when simple library managers became fully featured “chroot management systems”
Android makes a “user” for each application (in Linux terms).
The best permissions in a desktop OS are now available in macOS with Little Snitch (or another application firewall) installed. macOS allows you to control access to basic folders such as Desktop and Documents, and the firewall can control network access for each process, even if it is started from the command line.
We need to combine the “Android” and “macOS with app.firewall” approaches, and on top of that, give users the freedom to deceive any app with fake data if it refuses to work without it (such as fake contacts or GPS coordinates).
That would be real user freedom from the platforms and developers’ dictate. And that’s why it will never happen.
> Landlock is a Linux API that lets applications explicitly declare which resources they are allowed to access.
Sounds like a rather weak approach to me. So if an application is compromised, it could just skip the “declare Landlock” step, so nothing at all would be restricted.
Restrictions imo should come from the instance, providing the resources, even if that might be harder to establish. Having it the other way around feels like a design-fail to me.
Even to protect from e.g. memory exploits, it seems not to offer much to most user-facing applications, since e.g. most of these offer a generic save/load file dialog, so not possible to restrict file access for these.
However yea, it may fill some gap, for a rather limited number of use-cases.
Stitch,
The theory is that a “master” program will do the locking. Just like how ulimit works, you can only “reduce” what you see.
So, say … apt-get or npm forked process locks out directories outside of target install location… then any downstream post-install script will be unable to violate that sandbox.
However that does not resolve the situation where the installed program or library itself is compromised. Then your point will stand.
When the program starts it sets what it needs and can’t add anything new.
So if a running program gets compromised it will not start doing things it shouldn’t.