5 ms·

Landlock-Ing Linux

291 points by razighter777 11mo ago

razighter777 11mo ago
[flagged]
- Cthulhu_ 11mo ago
  Is this a statement or a question?
  - razighter777 11mo ago
    whoops it got added by the post creation form. I thought it would appear as a subtitle not a comment lol
PeterWhittaker 11mo ago
So like using seccomp with a whitelist (fairly easy to do) with per-object access rights. I'd love to see a comparison of landlock to restricted containers.
- razighter777 11mo ago
  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 :)
- vaylian 11mo ago
  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`.
  - PeterWhittaker 11mo ago
    Of course, but you can also restrict those operations. The seccomp whitelist library I wrote only sealed itself after all FDs were opened for specific operations, and the API didn't expose the calls directly. Once sealed, the app got only those operations now specifically allowed.
- staticassertion 11mo ago
  > 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.
kosolam 11mo ago
So it works also by using some cli utility to run my software for example?
- razighter777 11mo ago
  Yup. There are tools that use landlock to accomplish just that. https://github.com/Zouuup/landrun https://github.com/Zouuup/landrun All you gotta do is apply a policy and do a fork() exec(). There is also support in firejail.
  - seethishat 11mo ago
    Firejail requires SUID, LandLock does not. Also, it's very easy to write your own LandLock policy in the programming language of your choice and wrap whatever program you like rather than downloading stuff from Github. Here's another example in Go: package main import ( "fmt" "github.com/landlock-lsm/go-landlock/landlock" "log" "os" "os/exec" ) func main() { // Define the LandLock policy err := landlock.V1.RestrictPaths(...) // Execute FireFox cmd := exec.Command("/usr/bin/firefox") }
    - butvacuum 11mo ago
      Isn't this example just "downloading stuff from GitHub,"(the external Go dependency) but with extra steps? (Having to write and compile a golang app)
    - pdimitar 11mo ago
      So you're basically writing a program launcher? In this case this program is what you'd want to have a desktop shortcut to and not to Firefox itself, is that it?
- codethief 11mo ago
  Yeah, see e.g. sydbox: https://gitlab.exherbo.org/sydbox/sydbox https://gitlab.exherbo.org/sydbox/sydbox
seethishat 11mo ago
LandLock is a Minor LSM intended for software developers. They incorporate it into their source code to limit where the programs may read/write. Here's a simple Go example: package main import ( "flag" "fmt" "github.com/landlock-lsm/go-landlock/landlock" "io/ioutil" "log" "os" ) // simple program that demonstrates how landlock works in Go on Linux systems. // Requires 5.13 or newer kernel and .config should look something like this: // CONFIG_SECURITY_LANDLOCK=y // CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" func main() { var help = flag.Bool("help", false, "landlock-example -f /path/to/file.txt") var file = flag.String("f", "", "the file path to read") flag.Parse() if *help || len(os.Args) == 1 { flag.PrintDefaults() return } // allow the program to read files in /home/user/tmp err := landlock.V1.RestrictPaths(landlock.RODirs("/home/user/tmp")) if err != nil { log.Fatal(err) } // attempt to read a file bytes, err := ioutil.ReadFile(*file) if err != nil { log.Fatal(err) } fmt.Println(string(bytes)) }
- razighter777 11mo ago
  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.
  - unsnap_biceps 11mo ago
    I don't understand why someone would wrap an untrusted application with their own code vs using something like Systemd's exec capabilities to do the same without having to have a binary wrapper. What benefits do you see over the systemd solution?
    - razighter777 11mo ago
      Systemd's exec capabilities are great, but don't allow the application developer to dynamically restrict access rights to resources. So you could restrict a text editor for instance to the file it was launched to edit, instead of a hardcoded directory.
fiiin 11mo ago
Interesting they added new syscalls, instead of handling configuration via /sys like with SELinux and AppArmor. I suppose it must be because of the no privilege principle. Can sysadmins disable access to Landlock syscalls via seccomp? Not that I can see why they'd want to, just wondering how this is layered. I suppose the problem might be if the system has been set up at some earlier point in time to whitelist a set of syscalls for a process and, as Landlock is newer, its syscall numbers won't be included. A program that has been updated to use Landlock while a seccomp policy that predates Landlock is applied would presumably be terminated with SIGSYS due to this? How can a program determine if Landlock is present without just trying the syscalls and seeing if they work?
- razighter777 11mo ago
  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.
- cyphar 11mo ago
  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.
smartmic 11mo ago
I am puzzled by this: > A official c library doesn’t exist yet unfortunately, but there’s several out there you can try. > Landlock is a Linux Security Module (LSM) available since Linux 5.13 Since when is not a C API the first and foremost interface for developers when it comes to Linux kernel stuff?
- muvlon 11mo ago
  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.
  - smartmic 11mo ago
    Thanks for clarification! I meant more, why isn't there a C API first, but Rust, Haskell, and Go before that — that's kind of surprising or new to me.
    - WJW 11mo ago
      I don't understand what you mean. There's no "official" Rust, Haskell and Go APIs for this thing either. All libraries available seem to be just what some third party made available. There's also several C libraries, just none that have been officially endorsed by the Linux kernel team.
    - wging 11mo ago
      I read the article as saying that there's no official C library but unofficial ones do exist. Quote below, emphasis mine. > A official c library doesn’t exist yet unfortunately, but there’s several out there you can try. Also, it looks like there is more than zero support for C programs calling Landlock APIs. Even without a 3rd-party library you're not just calling syscall() with a magic number: https://docs.kernel.org/userspace-api/landlock.html https://docs.kernel.org/userspace-api/landlock.html https://github.com/torvalds/linux/blob/6bda50f4/include/uapi/linux/landlock.h https://github.com/torvalds/linux/blob/6bda50f4/include/uapi... https://github.com/torvalds/linux/blob/6bda50f4/include/linux/syscalls.h#L980 https://github.com/torvalds/linux/blob/6bda50f4/include/linu...
tux3 11mo ago
What's the status of Landlock in container runtimes? A quick search makes it seem like CRIs are trying to define their own custom Landlock interface. That will inevitably lag behind what the kernel supports, but more importantly I don't foresee many container image packagers, Helm recipe maintainers and other YAML wranglers getting into the business of maintaining a Landlock sandbox policy. It makes sense for an application to use Landlock directly to sandbox some parser or other sensitive component. But if the CRI just blocks the syscalls by default, no infra person is going to take on the maintainance of their own sandbox policy for every app. The app will just see ENOSYS and not be sandboxed. 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?
- ameliaquining 11mo ago
  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.
  - als0 11mo ago
    If the application in the container wants to add more restrictive rules then it should be allowed to. But it should not be able to mess with the existing rules imposed by the container manager. This would be the ideal outcome.
    - arianvanp 11mo ago
      There is nothing to do here. Landlock already a guarantees that you can't undo rules that were already applied. Your application can further restrict itself but it can't unrestrict itself.
      - als0 11mo ago
        Just need the container manager to not block the landlock system call
sofixa 11mo ago
For a cool practical example, check out Nomad's (flexible workload orchestrator) exec2 task driver: https://github.com/hashicorp/nomad-driver-exec2 https://github.com/hashicorp/nomad-driver-exec2 It allows running non/semi-trusted workloads with isolation. Pretty useful to onboard applications into a proper scheduler with all bells and whistles without having to containerise, but still with decent levels of isolation between them.
- jcgl 11mo ago
  I switched away from Nomad when HashiCorp moved from FOSS licenses to the BSL. But man, I do miss its simplicity.
notatoad 11mo ago
i have zero experience with linux system programming so i'm probably missing something, but what's the point of an application restricting itself at runtime? if the application were compromised in some way, wouldn't it simply un-restrict itself?
- RonanSoleste 11mo ago
  As the article states. You can not give extra permissions only limit further.
- razighter777 11mo ago
  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.
- zanchey 11mo ago
  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/ https://lwn.net/Articles/767137/
- williamstein 11mo ago
  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/ https://developers.openai.com/codex/security/
- cortesoft 11mo ago
  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.
- johncolanduoni 11mo ago
  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.
dannyfritz07 11mo ago
I've been messing with sandboxing using "bwrap" for random itch.io games I download to play and it isn't trivial to get it working with least privileges. I have so far been unable to get "Microlandia" to run, but other Unity games are running just fine under "bwrap". I am excited to see more Landlock tools emerge that make this task easier. - https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap - https://codeberg.org/dannyfritz/dotfiles/src/commit/383430085660a7af936c93344d6499c24e028cae/bin/run-game https://codeberg.org/dannyfritz/dotfiles/src/commit/38343008... - https://explodi.itch.io/microlandia https://explodi.itch.io/microlandia
- webstrand 11mo ago
  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 it seems to work fairly well? But I just started playing with bwrap this weekend. I do wish bwrap could be told "put the program in this pre-prepared network namespace" because accessing unsecured local dev servers could also be an issue.
  - tommica 11mo ago
    I had this idea of having toolbox+custom user for each project - that way it would be "simple" to have isolated environments, but it does lead to a lot of bloat. And I do think it is a naive solution. Bwrap seems like a better option.
    - jeroenhd 11mo ago
      I think a combination of custom users + a whole bunch of sandboxing is exactly what you'd get out of systemd-nspawn if you're willing to write the config: https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn bwrap seems a lot easier but if you want more control (or, for instance, want to run a Ubuntu basis because that's what a lot of games are compiled against), systemd-nspawn can be quite powerful.
    - bflesch 11mo ago
yalogin 11mo ago
As a noob in this space, why is this needed when every job already runs inside a VM or a container? Again, a noob so please bear with me
- woodruffw 11mo ago
  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.
- fragmede 11mo ago
  > 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).
  - yalogin 11mo ago
    Aren’t there existing methods to do this using selinux or apparmor?
    - loeg 11mo ago
      Both have shortcomings.
    - zie 11mo ago
      Yes, but basically nobody uses either of those things. Some vendors like Redhat enables some of it by default, but when people have issues getting software to work, the first thing they are told to try is to turn all that stuff off. Which means in the real world, the likelihood of that stuff being on and secure is fairly low, but not zero. With landlock, pledge/unveil and similar tech, the developers of the software write and configure it, it's on by default and probably can't be turned off(or at least not easily).
ijustlovemath 11mo ago
Medical device developer here: this is precisely the kind of work we need in highly regulated industries. We use an internal version of something with a similar API to manage our critical threads/processes. Keep it up!
pdimitar 11mo ago
I'm very slowly taking an interest in Linux security as I'm starting to disentangle from my Mac and preparing to get a Linux workstation and make it my forever home for personal and work computing. So I'm very new to all this. My questions are: - 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! - 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. Maybe I'm looking at the wrong thing. I strongly prefer deny-by-default in an invisible manner i.e. my system to refuse most requests to access this or that. Not opting in to it. Bad actors will not graciously limit their own program with Landlock. They'll try to get anything before I can even blink my eyes. I feel I'm missing crucially important context. Can somebody help?
- deleted 11mo ago
  [deleted]
- ameliaquining 11mo ago
  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.
- Dig1t 11mo ago
  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.
roer 11mo ago
If you're trying to deny internet access to a program, beware that landlock only restricts tcp sockets. Programs are free to setup udp or just raw sockets.
- ape4 11mo ago
  Pretty big loophole!
- parlortricks 11mo ago
  Well that seems like a major oversight there...what is the reasoning for that?
  - arianvanp 11mo ago
    It's just incomplete and very early days for landlock. Landlock requires you to commit upfront to what is "deny-default"ed but they only added a control for TCP socket bind and nothing else. So you can "default-deny" tcp bind but all the other socket paths in the kernel are not guarded by landlock. It tries really hard to have the commit of features be an integral part of the landlock API so that you can have an application able to run on multiple kernel versions that support different parts of the landlock spec. But that means that as they develop the API the older versions of landlock need to be less restrictive than newer versions otherwise programs dont work across kernel versions. That way, a program that is very restrictive on say kernel 6.30 can also run on kernel 6.1 with less restrictions. The program keeps functioning the same way (never break userspace). The only way to do that is to have the developer tell what parts need to be restricted explicitly and you can't restrict what isn't implemented yet. They're planning to extend it to all socket types. This is also mentioned in the linked article https://github.com/landlock-lsm/linux/issues/6 https://github.com/landlock-lsm/linux/issues/6 I guess if you want to run without networking at all today you can just unshare into a fresh network namespace, or maybe use seccomp strict mode
  - razighter777 11mo ago
    There's always a lot of caution and review that goes into a new syscall feature, because once you add a feature, there's no takebacks. All the libraries downstream from landlock rely on the kernel API being good. There is an ongoing patch series for udp and another one for general socket control. You can read about it on the linux-security-module mailing list. Basically UDP is harder to hook into because it's a connectionless protocol. So bind and connect don't really work the same way. https://lore.kernel.org/all/20241214184540.3835222-1-matthieu@buffet.re/ https://lore.kernel.org/all/20241214184540.3835222-1-matthie... https://lore.kernel.org/linux-security-module/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com/T/#t https://lore.kernel.org/linux-security-module/20251118134639...
brainless 11mo ago
Thanks for sharing. I did not know of this and I am looking for simple ways to isolate processes for multiple reasons. I am building a coding agent, https://github.com/brainless/nocodo https://github.com/brainless/nocodo, that runs (headless) on a Linux instance. Generated code is immediately available for demo. I am new to isolation and not looking for a container based approach. Isolation from a security standpoint but I do not know enough. This approach looks like a great start for me.
nesarkvechnep 11mo ago
Wait until the author discovers FreeBSD’s Capsicum. I believe it’s superior to most of the APIs provided by other major OSs.
adeon 11mo ago
I've used Landlock to detect and stop unwanted telemetry. I wrote some C that stopped networking except to accept connections on a single port, no outgoing connections and no accepting connections on any other port. `dmesg` shows the connections it blocks (I think this is maybe the audit feature). I used an example sandboxer.c as a base (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...) except I just set mine up to not touch file restricting, just networking so that it has that one whitelisted incoming port. ./network-sandboxer-tool 8000 some-program arg1 arg2 etc. I like it because it just works as an unprivileged usermode program without setting anything up. A tiny C program. It works inside containers without having to set up any firewalls. Aside from having to compile a small C program, there is little fuss. I found the whole Landlock thing trying to find out alternatives to bubblewrap because I couldn't figure out how to do the same thing in bwrap conveniently. The "unprivileged" in "Landlock: unprivileged access control" for me was the selling point for this use case. I don't consider this effective against actively adversarial programs though.
- ranger_danger 11mo ago
  Would you mind sharing your source code?
  - adeon 11mo ago
    I dumped it here just now: https://github.com/Noeda/landlock-network-sandboxer-tool https://github.com/Noeda/landlock-network-sandboxer-tool It hopefully will be obvious that nobody should expect quality :) it is like a simplified version of the sandboxer sample in my other comment. E.g. it maybe does not need to touch filesystem stuff at all. I'd also look at some of the sibling comments for maybe more refined tooling than this thing. Maybe it's useful as a sample though.
    - ranger_danger 11mo ago
      thanks!
habbekrats 11mo ago
its kind of funny to say: "A official c library doesn’t exist yet unfortunately, but there’s several out there you can try." if its litterally in the standard library... https://man7.org/linux/man-pages/man7/landlock.7.html https://man7.org/linux/man-pages/man7/landlock.7.html But i suppose i am missing somehting then people would like... What would you want an library to do here? abstract over it to make it easier? (relatively simple api already) legit question, not trying to poke anyone here.. trying to find out what ppl expect from libraries which wrap around these syscalls or stdlib things.
- jeroenhd 11mo ago
  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?
  - cyphar 11mo ago
    glibc has been reticent about adding new syscall wrappers for a few years. The situation did improve for a bit recently (and they added something like 5 years of syscalls from their backlog in the past few years) but I'm not surprised it's taking some time. Thankfully we have had unified syscall numbers on Linux (for almost all architectures) for the past few years so tracking them is less painful than it used it be.
initramfs 11mo ago
bookmarked.
bboozzoo 11mo ago
It's not all roses unfortunately. See discussions https://github.com/landlock-lsm/linux/issues/28 https://github.com/landlock-lsm/linux/issues/28 and https://lore.kernel.org/all/CAG48ez1O0VTwEiRd3KqexoF78WR+cmP5bGk5Kh5Cs7aPepiDVg@mail.gmail.com/ https://lore.kernel.org/all/CAG48ez1O0VTwEiRd3KqexoF78WR+cmP... Even the example code builds a somewhat questionable 'sandbox' that hits a problem discussed in those threads. Say we're ok with an app having r-w access to home except for a couple of places such as ~/.ssh. Now you could try to add a rule to exclude access to ~/.ssh, but the security object must exist when the policy is being established (the rules refer to directories by fds). As such, no .ssh directory, means not rules denying access. You start a sandboxed app thinking you've set up a tight sandbox, at some point ~/.ssh gets created, and now the untrusted app can read your ssh keys.
- razighter777 11mo ago
  Valid concern. Maybe this can be addressed with a patch... Seems solvable by perhaps storing paths that don't exist yet on the filesystem in landlock's red black tree. Workaround might be creating .ssh ahead of time
imcritic 11mo ago
This approach is stupid. That's like relying on criminals to cuff themselves when they have committed a crime.
- woodruffw 11mo ago
  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.
- tremon 11mo ago
  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.

Landlock-Ing Linux

291 points by razighter777 11mo ago

razighter777 11mo ago

[flagged]

Cthulhu_ 11mo ago
Is this a statement or a question?
- razighter777 11mo ago
  whoops it got added by the post creation form. I thought it would appear as a subtitle not a comment lol

PeterWhittaker 11mo ago

So like using seccomp with a whitelist (fairly easy to do) with per-object access rights. I'd love to see a comparison of landlock to restricted containers.

razighter777 11mo ago
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 :)
vaylian 11mo ago
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`.
- PeterWhittaker 11mo ago
  Of course, but you can also restrict those operations. The seccomp whitelist library I wrote only sealed itself after all FDs were opened for specific operations, and the API didn't expose the calls directly. Once sealed, the app got only those operations now specifically allowed.
staticassertion 11mo ago
> 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.

kosolam 11mo ago

So it works also by using some cli utility to run my software for example?

razighter777 11mo ago
Yup. There are tools that use landlock to accomplish just that. https://github.com/Zouuup/landrun https://github.com/Zouuup/landrun All you gotta do is apply a policy and do a fork() exec(). There is also support in firejail.
- seethishat 11mo ago
  Firejail requires SUID, LandLock does not. Also, it's very easy to write your own LandLock policy in the programming language of your choice and wrap whatever program you like rather than downloading stuff from Github. Here's another example in Go: package main import ( "fmt" "github.com/landlock-lsm/go-landlock/landlock" "log" "os" "os/exec" ) func main() { // Define the LandLock policy err := landlock.V1.RestrictPaths(...) // Execute FireFox cmd := exec.Command("/usr/bin/firefox") }
  - butvacuum 11mo ago
    Isn't this example just "downloading stuff from GitHub,"(the external Go dependency) but with extra steps? (Having to write and compile a golang app)
  - pdimitar 11mo ago
    So you're basically writing a program launcher? In this case this program is what you'd want to have a desktop shortcut to and not to Firefox itself, is that it?
codethief 11mo ago
Yeah, see e.g. sydbox: https://gitlab.exherbo.org/sydbox/sydbox https://gitlab.exherbo.org/sydbox/sydbox

seethishat 11mo ago

LandLock is a Minor LSM intended for software developers. They incorporate it into their source code to limit where the programs may read/write. Here's a simple Go example: package main import ( "flag" "fmt" "github.com/landlock-lsm/go-landlock/landlock" "io/ioutil" "log" "os" ) // simple program that demonstrates how landlock works in Go on Linux systems. // Requires 5.13 or newer kernel and .config should look something like this: // CONFIG_SECURITY_LANDLOCK=y // CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo" func main() { var help = flag.Bool("help", false, "landlock-example -f /path/to/file.txt") var file = flag.String("f", "", "the file path to read") flag.Parse() if *help || len(os.Args) == 1 { flag.PrintDefaults() return } // allow the program to read files in /home/user/tmp err := landlock.V1.RestrictPaths(landlock.RODirs("/home/user/tmp")) if err != nil { log.Fatal(err) } // attempt to read a file bytes, err := ioutil.ReadFile(*file) if err != nil { log.Fatal(err) } fmt.Println(string(bytes)) }

razighter777 11mo ago
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.
- unsnap_biceps 11mo ago
  I don't understand why someone would wrap an untrusted application with their own code vs using something like Systemd's exec capabilities to do the same without having to have a binary wrapper. What benefits do you see over the systemd solution?
  - razighter777 11mo ago
    Systemd's exec capabilities are great, but don't allow the application developer to dynamically restrict access rights to resources. So you could restrict a text editor for instance to the file it was launched to edit, instead of a hardcoded directory.

fiiin 11mo ago

Interesting they added new syscalls, instead of handling configuration via /sys like with SELinux and AppArmor. I suppose it must be because of the no privilege principle. Can sysadmins disable access to Landlock syscalls via seccomp? Not that I can see why they'd want to, just wondering how this is layered. I suppose the problem might be if the system has been set up at some earlier point in time to whitelist a set of syscalls for a process and, as Landlock is newer, its syscall numbers won't be included. A program that has been updated to use Landlock while a seccomp policy that predates Landlock is applied would presumably be terminated with SIGSYS due to this? How can a program determine if Landlock is present without just trying the syscalls and seeing if they work?

razighter777 11mo ago
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.
cyphar 11mo ago
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.

smartmic 11mo ago

I am puzzled by this: > A official c library doesn’t exist yet unfortunately, but there’s several out there you can try. > Landlock is a Linux Security Module (LSM) available since Linux 5.13 Since when is not a C API the first and foremost interface for developers when it comes to Linux kernel stuff?

muvlon 11mo ago
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.
- smartmic 11mo ago
  Thanks for clarification! I meant more, why isn't there a C API first, but Rust, Haskell, and Go before that — that's kind of surprising or new to me.
  - WJW 11mo ago
    I don't understand what you mean. There's no "official" Rust, Haskell and Go APIs for this thing either. All libraries available seem to be just what some third party made available. There's also several C libraries, just none that have been officially endorsed by the Linux kernel team.
  - wging 11mo ago
    I read the article as saying that there's no official C library but unofficial ones do exist. Quote below, emphasis mine. > A official c library doesn’t exist yet unfortunately, but there’s several out there you can try. Also, it looks like there is more than zero support for C programs calling Landlock APIs. Even without a 3rd-party library you're not just calling syscall() with a magic number: https://docs.kernel.org/userspace-api/landlock.html https://docs.kernel.org/userspace-api/landlock.html https://github.com/torvalds/linux/blob/6bda50f4/include/uapi/linux/landlock.h https://github.com/torvalds/linux/blob/6bda50f4/include/uapi... https://github.com/torvalds/linux/blob/6bda50f4/include/linux/syscalls.h#L980 https://github.com/torvalds/linux/blob/6bda50f4/include/linu...

tux3 11mo ago

What's the status of Landlock in container runtimes? A quick search makes it seem like CRIs are trying to define their own custom Landlock interface. That will inevitably lag behind what the kernel supports, but more importantly I don't foresee many container image packagers, Helm recipe maintainers and other YAML wranglers getting into the business of maintaining a Landlock sandbox policy. It makes sense for an application to use Landlock directly to sandbox some parser or other sensitive component. But if the CRI just blocks the syscalls by default, no infra person is going to take on the maintainance of their own sandbox policy for every app. The app will just see ENOSYS and not be sandboxed. 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?

ameliaquining 11mo ago
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.
- als0 11mo ago
  If the application in the container wants to add more restrictive rules then it should be allowed to. But it should not be able to mess with the existing rules imposed by the container manager. This would be the ideal outcome.
  - arianvanp 11mo ago
    There is nothing to do here. Landlock already a guarantees that you can't undo rules that were already applied. Your application can further restrict itself but it can't unrestrict itself.
    - als0 11mo ago
      Just need the container manager to not block the landlock system call

sofixa 11mo ago

For a cool practical example, check out Nomad's (flexible workload orchestrator) exec2 task driver: https://github.com/hashicorp/nomad-driver-exec2 https://github.com/hashicorp/nomad-driver-exec2 It allows running non/semi-trusted workloads with isolation. Pretty useful to onboard applications into a proper scheduler with all bells and whistles without having to containerise, but still with decent levels of isolation between them.

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

notatoad 11mo ago

i have zero experience with linux system programming so i'm probably missing something, but what's the point of an application restricting itself at runtime? if the application were compromised in some way, wouldn't it simply un-restrict itself?

RonanSoleste 11mo ago
As the article states. You can not give extra permissions only limit further.
razighter777 11mo ago
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.
zanchey 11mo ago
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/ https://lwn.net/Articles/767137/
williamstein 11mo ago
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/ https://developers.openai.com/codex/security/
cortesoft 11mo ago
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.
johncolanduoni 11mo ago
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.

dannyfritz07 11mo ago

I've been messing with sandboxing using "bwrap" for random itch.io games I download to play and it isn't trivial to get it working with least privileges. I have so far been unable to get "Microlandia" to run, but other Unity games are running just fine under "bwrap". I am excited to see more Landlock tools emerge that make this task easier. - https://github.com/containers/bubblewrap https://github.com/containers/bubblewrap - https://codeberg.org/dannyfritz/dotfiles/src/commit/383430085660a7af936c93344d6499c24e028cae/bin/run-game https://codeberg.org/dannyfritz/dotfiles/src/commit/38343008... - https://explodi.itch.io/microlandia https://explodi.itch.io/microlandia

webstrand 11mo ago
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 it seems to work fairly well? But I just started playing with bwrap this weekend. I do wish bwrap could be told "put the program in this pre-prepared network namespace" because accessing unsecured local dev servers could also be an issue.
- tommica 11mo ago
  I had this idea of having toolbox+custom user for each project - that way it would be "simple" to have isolated environments, but it does lead to a lot of bloat. And I do think it is a naive solution. Bwrap seems like a better option.
  - jeroenhd 11mo ago
    I think a combination of custom users + a whole bunch of sandboxing is exactly what you'd get out of systemd-nspawn if you're willing to write the config: https://wiki.archlinux.org/title/Systemd-nspawn https://wiki.archlinux.org/title/Systemd-nspawn bwrap seems a lot easier but if you want more control (or, for instance, want to run a Ubuntu basis because that's what a lot of games are compiled against), systemd-nspawn can be quite powerful.
  - bflesch 11mo ago

yalogin 11mo ago

As a noob in this space, why is this needed when every job already runs inside a VM or a container? Again, a noob so please bear with me

woodruffw 11mo ago
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.
fragmede 11mo ago
> 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).
- yalogin 11mo ago
  Aren’t there existing methods to do this using selinux or apparmor?
  - loeg 11mo ago
    Both have shortcomings.
  - zie 11mo ago
    Yes, but basically nobody uses either of those things. Some vendors like Redhat enables some of it by default, but when people have issues getting software to work, the first thing they are told to try is to turn all that stuff off. Which means in the real world, the likelihood of that stuff being on and secure is fairly low, but not zero. With landlock, pledge/unveil and similar tech, the developers of the software write and configure it, it's on by default and probably can't be turned off(or at least not easily).

ijustlovemath 11mo ago

Medical device developer here: this is precisely the kind of work we need in highly regulated industries. We use an internal version of something with a similar API to manage our critical threads/processes. Keep it up!

pdimitar 11mo ago

I'm very slowly taking an interest in Linux security as I'm starting to disentangle from my Mac and preparing to get a Linux workstation and make it my forever home for personal and work computing. So I'm very new to all this. My questions are: - 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! - 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. Maybe I'm looking at the wrong thing. I strongly prefer deny-by-default in an invisible manner i.e. my system to refuse most requests to access this or that. Not opting in to it. Bad actors will not graciously limit their own program with Landlock. They'll try to get anything before I can even blink my eyes. I feel I'm missing crucially important context. Can somebody help?

deleted 11mo ago
[deleted]
ameliaquining 11mo ago
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.
Dig1t 11mo ago
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.

roer 11mo ago

If you're trying to deny internet access to a program, beware that landlock only restricts tcp sockets. Programs are free to setup udp or just raw sockets.

ape4 11mo ago
Pretty big loophole!
parlortricks 11mo ago
Well that seems like a major oversight there...what is the reasoning for that?
- arianvanp 11mo ago
  It's just incomplete and very early days for landlock. Landlock requires you to commit upfront to what is "deny-default"ed but they only added a control for TCP socket bind and nothing else. So you can "default-deny" tcp bind but all the other socket paths in the kernel are not guarded by landlock. It tries really hard to have the commit of features be an integral part of the landlock API so that you can have an application able to run on multiple kernel versions that support different parts of the landlock spec. But that means that as they develop the API the older versions of landlock need to be less restrictive than newer versions otherwise programs dont work across kernel versions. That way, a program that is very restrictive on say kernel 6.30 can also run on kernel 6.1 with less restrictions. The program keeps functioning the same way (never break userspace). The only way to do that is to have the developer tell what parts need to be restricted explicitly and you can't restrict what isn't implemented yet. They're planning to extend it to all socket types. This is also mentioned in the linked article https://github.com/landlock-lsm/linux/issues/6 https://github.com/landlock-lsm/linux/issues/6 I guess if you want to run without networking at all today you can just unshare into a fresh network namespace, or maybe use seccomp strict mode
- razighter777 11mo ago
  There's always a lot of caution and review that goes into a new syscall feature, because once you add a feature, there's no takebacks. All the libraries downstream from landlock rely on the kernel API being good. There is an ongoing patch series for udp and another one for general socket control. You can read about it on the linux-security-module mailing list. Basically UDP is harder to hook into because it's a connectionless protocol. So bind and connect don't really work the same way. https://lore.kernel.org/all/20241214184540.3835222-1-matthieu@buffet.re/ https://lore.kernel.org/all/20241214184540.3835222-1-matthie... https://lore.kernel.org/linux-security-module/20251118134639.3314803-1-ivanov.mikhail1@huawei-partners.com/T/#t https://lore.kernel.org/linux-security-module/20251118134639...

brainless 11mo ago

Thanks for sharing. I did not know of this and I am looking for simple ways to isolate processes for multiple reasons. I am building a coding agent, https://github.com/brainless/nocodo https://github.com/brainless/nocodo, that runs (headless) on a Linux instance. Generated code is immediately available for demo. I am new to isolation and not looking for a container based approach. Isolation from a security standpoint but I do not know enough. This approach looks like a great start for me.

nesarkvechnep 11mo ago

Wait until the author discovers FreeBSD’s Capsicum. I believe it’s superior to most of the APIs provided by other major OSs.

adeon 11mo ago

I've used Landlock to detect and stop unwanted telemetry. I wrote some C that stopped networking except to accept connections on a single port, no outgoing connections and no accepting connections on any other port. `dmesg` shows the connections it blocks (I think this is maybe the audit feature). I used an example sandboxer.c as a base (https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/samples/landlock/sandboxer.c https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux...) except I just set mine up to not touch file restricting, just networking so that it has that one whitelisted incoming port. ./network-sandboxer-tool 8000 some-program arg1 arg2 etc. I like it because it just works as an unprivileged usermode program without setting anything up. A tiny C program. It works inside containers without having to set up any firewalls. Aside from having to compile a small C program, there is little fuss. I found the whole Landlock thing trying to find out alternatives to bubblewrap because I couldn't figure out how to do the same thing in bwrap conveniently. The "unprivileged" in "Landlock: unprivileged access control" for me was the selling point for this use case. I don't consider this effective against actively adversarial programs though.

ranger_danger 11mo ago
Would you mind sharing your source code?
- adeon 11mo ago
  I dumped it here just now: https://github.com/Noeda/landlock-network-sandboxer-tool https://github.com/Noeda/landlock-network-sandboxer-tool It hopefully will be obvious that nobody should expect quality :) it is like a simplified version of the sandboxer sample in my other comment. E.g. it maybe does not need to touch filesystem stuff at all. I'd also look at some of the sibling comments for maybe more refined tooling than this thing. Maybe it's useful as a sample though.
  - ranger_danger 11mo ago
    thanks!

habbekrats 11mo ago

its kind of funny to say: "A official c library doesn’t exist yet unfortunately, but there’s several out there you can try." if its litterally in the standard library... https://man7.org/linux/man-pages/man7/landlock.7.html https://man7.org/linux/man-pages/man7/landlock.7.html But i suppose i am missing somehting then people would like... What would you want an library to do here? abstract over it to make it easier? (relatively simple api already) legit question, not trying to poke anyone here.. trying to find out what ppl expect from libraries which wrap around these syscalls or stdlib things.

jeroenhd 11mo ago
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?
- cyphar 11mo ago
  glibc has been reticent about adding new syscall wrappers for a few years. The situation did improve for a bit recently (and they added something like 5 years of syscalls from their backlog in the past few years) but I'm not surprised it's taking some time. Thankfully we have had unified syscall numbers on Linux (for almost all architectures) for the past few years so tracking them is less painful than it used it be.

initramfs 11mo ago

bookmarked.

bboozzoo 11mo ago

It's not all roses unfortunately. See discussions https://github.com/landlock-lsm/linux/issues/28 https://github.com/landlock-lsm/linux/issues/28 and https://lore.kernel.org/all/CAG48ez1O0VTwEiRd3KqexoF78WR+cmP5bGk5Kh5Cs7aPepiDVg@mail.gmail.com/ https://lore.kernel.org/all/CAG48ez1O0VTwEiRd3KqexoF78WR+cmP... Even the example code builds a somewhat questionable 'sandbox' that hits a problem discussed in those threads. Say we're ok with an app having r-w access to home except for a couple of places such as ~/.ssh. Now you could try to add a rule to exclude access to ~/.ssh, but the security object must exist when the policy is being established (the rules refer to directories by fds). As such, no .ssh directory, means not rules denying access. You start a sandboxed app thinking you've set up a tight sandbox, at some point ~/.ssh gets created, and now the untrusted app can read your ssh keys.

razighter777 11mo ago
Valid concern. Maybe this can be addressed with a patch... Seems solvable by perhaps storing paths that don't exist yet on the filesystem in landlock's red black tree. Workaround might be creating .ssh ahead of time

imcritic 11mo ago

This approach is stupid. That's like relying on criminals to cuff themselves when they have committed a crime.

woodruffw 11mo ago
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.
tremon 11mo ago
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.