Landlock-Ing Linux

Would you mind sharing your source code?

I was just playing with bwrap for isolating npm project actions from the rest of my system.

    bwrap --unshare-pid --dev-bind / / --tmpfs /home --bind "$(pwd)" "$(pwd)" bash

> A quick search makes it seem like CRIs are trying to define their own custom Landlock interface.

Are you referring to [0, 1]?

> But if the CRI just blocks the syscalls by default

Does it? Where are you getting this from?

> I might be missing the whole idea here, but I really don't see why we need some custom layer in the middle instead of having container runtimes let the security syscalls through?

Because in the latter case you have to trust the application it will actually do the appropriate locking?

[0]: https://github.com/opencontainers/runc/issues/2859

[1]: https://github.com/opencontainers/runtime-spec/issues/1110

I don't think this is really intended for container runtimes. You might be able to make it work in a square-peg-round-hole sort of way but the core use case is different.

The first and foremost interface of the kernel is the syscall interface aka the uapi. libc and other C libraries like liburing or libcap are downstream of that. Many syscalls still don't have wrappers in libc after years of use.

It's pretty subtle but it's referring to The C Library, libc.{a,so,dll,etc}. The library provided by your toolchain that supports the language.

Meaning glibc or musl or your favorite C library probably doesn't have this yet, but since the system calls are well defined you can use A C library (create your own header file using the _syscallN macro for example).

The lack of a C API should not stop any C developers from using it, hopefully. The wrapper libraries are relatively simple (i.e. https://codeberg.org/git-bruh/landbox) and both Rust and Go can expose a C FFI in case developers would rather link against a more "official" library instead.

The Linux kernel has a relatively simple example on how to use the syscall even if you can't find a library to deal with it for you: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

There is no "liblandlock" or whatever, though there totally could be. The only reason Rust, Go, and Haskell have an easy-to-use API for this syscall is because someone bothered to implement a wrapper and publish it to the usual package managers. Whatever procedure distros use to add new libraries could just as easily be used to push a landlock library/header to use it in C.

> Since when is not a C API the first and foremost interface for developers when it comes to Linux kernel stuff?

Since the kernel developers don't make userland software?

https://man7.org/linux/man-pages/man7/landlock.7.html most is rly there.

There is a C API. man landlock_add_rule for example.

https://github.com/torvalds/linux/blob/master/include/uapi/l...

you can add simple one-line wrappers if you don't like using syscall() function.

I use this and have no problems with it: https://github.com/marty1885/landlock-unveil

Other LSMs are slowly switching to syscalls too, and while I in principle like (and have abused) the whole "everything is a file" principle, most security mechanisms really should be done via special-purpose syscalls. Way too many footguns with filesystem-based APIs. Also, you wouldn't be able to use Landlock to restrict filesystem access based on dirfds with a filesystem-based API.

The questions you have about seccomp depend on the rules. Well-written filters would return -ENOSYS in that case, so it would look to the program as though the syscall is unsupported.

You can restrict the landlock syscalls with seccomp.

I also don't think doing so is extraordinarily useful.

If you allow something in landlock, it's still subject to traditional DAC and other restrictions because its a stackable LSM. It can only restrict existing access, not allow new accesses.

Well that seems like a major oversight there...what is the reasoning for that?

Well you need root access, or at least the CAP_NET_RAW capability to use raw sockets. UDP seems pretty bad though.

They can be disabled by firewall, iptables can match outgoing sockets by owner uid. I know it's not the same thing as landlock, still can come in handy.

And raw sockets require elevated privileges anyway iirc.

Pretty big loophole!

oof! thats terrible... :/ good to know..... what a weird restriction.

The threat model here is not malware, but code-execution vulnerabilities in legitimate apps. If you're developing an application, you might use this API to deny yourself privileges that you know you won't need, so that if an attacker finds a code-execution vulnerability in your app, they can't use it to take over the user's machine.

It is not a suitable technology for sandboxing a program that wasn't designed to be sandboxed in this way. For that, you need one of the other technologies listed in the article.

I want to craft an environment where any program trying to read f.ex. anything inside ~/.ssh is automatically denied

That requires a MAC security model like apparmor [0] or selinux [1]. Those can deny filesystem access based on process environment data, such as the executable path or its security context. But these require the access rules to be enumerated externally, whereas landlock is about an application voluntarily limiting itself -- or limiting its children: e.g. it would be a very good idea for npm to restrict the scope of package post-install scripts to only the npm cache/build tree.

It seems that this software is well-positioned for us to write application launchers

Like OpenBSD's pledge[2], this API is primarily meant for application writers, not launchers. But where the Openbsd base system is maintained as a whole by the same group of people, Linux is a hodgepodge of different distributions using various software to construct a complete system. This means it's going to take a long while before landlock will reach anywhere close to the same coverage that pledge already has in OpenBSD. In the meantime, wrappers/launchers is the best that you can do on Linux.

[0] https://en.opensuse.org/SDB:AppArmor_geeks#Anatomy_of_a_prof...

[1] https://manpages.opensuse.org/Tumbleweed/selinux-policy-doc/...

[2] https://unix.stackexchange.com/a/411157

Mac and iOS have something that is almost exactly the same as this called sandboxing. When a daemon or app starts one of the first things it does (usually right inside of “main”) is enable the sandbox and declare which resources to whitelist, everything else is denied.

It is only useful for guarding your own process against someone using malicious inputs to get your process to do something you don’t intend. It is not a guard against programs written by malicious actors (malware), there exist other mechanisms to guard against malware.

> - How does this help with malware? I want to craft an environment where any program trying to read f.ex. anything inside ~/.ssh is automatically denied. I don't want a malicious build script to exfiltrate all my sensitive data!

Your package manager would specify a policy that only allows specific access by build scripts. Or you'd use a wrapper.

> - It seems that this software is well-positioned for us to write application launchers with, is that true? If so, well, I like the idea but it seems too manual.

It could be. It's for anyone who knows what their program does, basically.

Actually providing a method rather than documenting the syscall would be a good start. libc patches over a lot of syscall requirements and side effects, as well as keeping track of the individual syscall numbers for you.

I'm kind of surprised glibc doesn't provide a normal interface yet, but I suppose it has to do with non-Linux compatibility?

I think it's a reasonable question. The answer is that not everything does indeed run in a VM or a container: lots of things (notably on developer machines) run directly in a host user context, where they have access to all kinds of global state that they don't really need (developer credentials, browser state, etc.).

But also: even within a container (which isn't itself a sandbox) or a VM, you still have concentric circles of trust and/or privilege. If you're installing arbitrary dependencies from the Internet, for example, you probably want a basic initial defense of preventing those dependencies from exfiltrating your secrets at build time.

On your desktop/laptop, most tasks probably don't run inside VMs or containers. Perhaps some applications use Flatpak or snaps or similar, but the default state for many currently popular Linux distributions is "no sandboxing of any kind".

Linux holds on to a negligible share of the overall desktop market OS, but it is marginally more popular among tech savvy people, which have plenty of disposable income, meaning the platform has steadily growing interest for malware authors and distributors despite its relatively low usage.

Its a way for legitimate apps to add an extra protection layer to protect the system from bad inputs or compromised dependencies, and it's very easy to use (see https://github.com/landlock-lsm/go-landlock). As an app developer it's so easy to add landlock to your app.

Another benefit is that it makes it easier for fine-grain control of resources in the application lifecycle. Maybe on initialization the app needs credentials to fetch some data and later on the all doesnt need them. Landlock allows the app to remove its own access to those credentials.

Containers are NOT security wrappers. They are convenience to avoid dependency hell from lazy people.

VM's can be security wrappers, but if you expose all of $HOME to a VM, then there really isn't much security happening, in terms of your data.

This lets developers of applications harden themselves, it doesn't require the end-user to do anything(like put it in a VM).

Landlock isn't really an alternative to containers. You can use it as another layer of security, within or outside a container.

It could even be paired with a chroot to make a container runtime. It's more like a building block for process restrictions

One of the most annoying parts of being in a container is that you can't sandbox yourself further within that container. Normal approaches like namespaces, mounts, chroot, etc, are all incompatible with running in a container. Therefor, if you want to go further than what a container provides, landlock is a powerful solution.

Further, while "whole process" sandboxing like containerizing is very effective under some conditions, having more fine grained access and the ability to reduce permissions over time is incredible.

Consider that I may need to open a file in my program. The file path will be provided by an env var `CONFIG_PATH`. My program now has to have total file system read permissions if it is going to support reading arbitrary configuration file paths, even though it only has to read one file.

I can instead set my program up to read that file one time and then never again, or I can set things up to only ever need to read that single file and no others, etc. I can incrementally reduce permissions, and that's really cool. You can't do that with a container - containers get what they get.

> It provides a simple, developer-friendly way to add defense-in-depth to applications.

Defense in depth. Lock your valuables inside a safe, inside of your locked house. Why lock them in a safe when your house is already locked? Because if someone breaks into your house, you want additional defense "just in case". So just in case I wrote some shitty code and my server got hacked, lock the valuables in a safe anyway so that thief can't steal the expensive silverware (prod credentials).

Comparing landlock to containers isn't really an apples to apples comparison. Containers use a bunch of linux security mechanisms together like chroot seccomp and user namespaces to accomplish their goals. Landlock is just another building block that devs can use.

Fun fact: because landlock is unprivleged, you can even use it inside containers; or to build an unprivileged container runtime :)

seccomp is for restricting syscalls to the kernel. But because "everything is a file" on UNIX systems, you can do a lot of good and bad things just with `open`, `openat`, `read` and `write`.

> I'd love to see a comparison of landlock to restricted containers.

One thing to consider is that containers virtualize. You enter new "namespaces" where you aren't necessarily restricted within that namespace, but the namespace as a whole is sort of your own playground. So a PID namespace only allows you to see other processes within that namespace.

This is very distinct from a resource oriented approach like landlock. Landlock may allow you to say "you can do certain actions to certain processes" but you wouldn't get the same semantics as "I can only see specific processes to begin with". They would layer nicely.

Similarly, containers provide virtualized file systems. A write happens in a container and it's allowed, but the write is isolated from the host. Landlock would instead allow or deny that write.

They go very well together.

LWN's article on unveil() is a good explanation - the restrictions are permanently applied to the process and its children until termination: https://lwn.net/Articles/767137/

The kernel enforces that once the policy gets added it can't be removed.

So the restrictions are permanent for the life of the program. Even root can't undo them.

Since it can’t re-enable privileges during runtime, the compromise would have to modify its own code and restart; if you don’t allow the running process to access its own code, it couldn’t make any changes that would persist across a restart of the code.

Reading this as a web developer, it reminds me of Demo's permission system.

Deno is a JS runtime that often runs, at my behest, code that I did not myself write and haven't vetted. At run time, I can invoke Deno with --allow-read=$PWD and know that Deno will prevent all that untrusted JS from reading any files outside the current directory.

If Deno itself is compromised then yeah, that won't work. But that's a smaller attack surface than all my NPM packages.

Just one example of how something like this helps in practise.

As the article states. You can not give extra permissions only limit further.

> if the application were compromised in some way, wouldn't it simply un-restrict itself?

The API doesn't allow un-restriction, only restriction. Since one typically applies restrictions at program start, they will be applied before an attacker gains remote-execution, and the attacker is then limited in what they can do...

The kernel guarantees that once restricted, that process will stay restricted. The only way for it to un-restrict itself would be to also compromise the Linux kernel. So you have 2 things you have to compromise to own the machine, instead of just 1.

For sandboxes where the underlying software is assumed to be non-hostile (e.g. browser sandboxes), these kind of restrictions can be applied very early in a program's execution. If the program doesn't accept any untrusted input until after the restrictions are applied, it can still provide a strong defense against escalation in the event of a vulnerability.

codex-cli is a neat example of an open source Rust program that uses Landlock to run commands that an LLM comes up with when writing code (see [1]). The model is that a user trusts the agent program (codex-cli), but has much more limited trust of the commands the remote LLM asks codex-cli to run.

[1] https://developers.openai.com/codex/security/

The point is it can’t.

That’s not how userspace sandboxing works. The assumption is that privilege flows from a trusted parent process to an untrusted child, so the trusted parent is the one responsible for setting the access controls.

Not really. It's more like wearing seatbelts: the car is not supposed to crash, but in case something unforeseen happens, please don't let the passengers exit through the windshield.

I switched away from Nomad when HashiCorp moved from FOSS licenses to the BSL. But man, I do miss its simplicity.

Yup. There are tools that use landlock to accomplish just that.

https://github.com/Zouuup/landrun

All you gotta do is apply a policy and do a fork() exec(). There is also support in firejail.

Yeah, see e.g. sydbox: https://gitlab.exherbo.org/sydbox/sydbox

Is this a statement or a question?

I feel like I need to ask; did you write this comment and the code example yourself, or did you ask an AI to generate it? If it's AI, why didn't you disclose it? If it's the former, why the weird formatting etc instead of linking to one of the official examples at https://github.com/landlock-lsm/go-landlock/blob/main/exampl... ?

Yup. In the application code itself is where landlock shines at the moment.

It's becoming increasingly usable as a wrapper for untrusted applications as well.