'Landrun': Lightweight Linux Sandboxing With Landlock, No Root Required (github.com) 40
Over on Reddit's "selfhosted" subreddit for alternatives to popular services, long-time Slashdot reader Zoup described a pain point:
- Landlock is a Linux Security Module (LSM) that lets unprivileged processes restrict themselves.
- It's been in the kernel since 5.13, but the API is awkward to use directly.
- It always annoyed the hell out of me to run random binaries from the internet without any real control over what they can access.
So they've rolled their own solution, according to Thursday's submission to Slashdot: I just released Landrun, a Go-based CLI tool that wraps Linux Landlock (5.13+) to sandbox any process without root, containers, or seccomp. Think firejail, but minimal and kernel-native. Supports fine-grained file access (ro/rw/exec) and TCP port restrictions (6.7+). No daemons, no YAML, just flags.
Example (where --rox allows read-only access with execution to specified path):
# landrun --rox /usr touch /tmp/file
touch: cannot touch '/tmp/file': Permission denied
# landrun --rox /usr --rw /tmp touch /tmp/file
#
It's MIT-licensed, easy to audit, and now supports systemd services.
- Landlock is a Linux Security Module (LSM) that lets unprivileged processes restrict themselves.
- It's been in the kernel since 5.13, but the API is awkward to use directly.
- It always annoyed the hell out of me to run random binaries from the internet without any real control over what they can access.
So they've rolled their own solution, according to Thursday's submission to Slashdot: I just released Landrun, a Go-based CLI tool that wraps Linux Landlock (5.13+) to sandbox any process without root, containers, or seccomp. Think firejail, but minimal and kernel-native. Supports fine-grained file access (ro/rw/exec) and TCP port restrictions (6.7+). No daemons, no YAML, just flags.
Example (where --rox allows read-only access with execution to specified path):
# landrun --rox /usr touch /tmp/file
touch: cannot touch '/tmp/file': Permission denied
# landrun --rox /usr --rw /tmp touch /tmp/file
#
It's MIT-licensed, easy to audit, and now supports systemd services.
LandLock (Score:5, Informative)
Ok, but... (Score:5, Funny)
Re: (Score:3)
That said... you can always run landrun in landrun.
Interesting. How easy is it to get a set of restrictions which allow it to do further restrictions without giving it the possibility to unrestrict itself?
Re: (Score:1)
Re: (Score:2)
Understood, however the forked process will either have the permissions to set permissions or it won't.
Surely, if it does have that permission it can then give itself full permissions and escape the jail.
If it doesn't have that permission then it's useless.
Re: (Score:1)
Re: (Score:2)
Okay, excellent. That still means that the process ends up with a superset of all of the permissions of all of the programs that it can run, but it's much better than it could be. Thanks, I will be investigating.
Re: (Score:3)
A bigger issue is the outright constant expectation of downloading random untrusted crap from the internet on a daily basis, because developers hate writing software that they don't get to control / monetize indefinitely. Such as webapps and dependencies that can't
Re: (Score:3)
Re: (Score:3)
But I distrust the excessive amounts of dependency downloads
Having an online repository of public libraries that you can reuse without reinventing the wheel every time is the greatest value of opensource, right there with the "I can fix it myself" part.
so fashionable with "online repositories" these days.
Apparently you have not heard of CPAN, the first large pubic opensource library repository that became active and available in 1994 or 95. It was the first of its kind to make automatic dependency resolution and unattended installation a breeze. From source, too. It became a guiding light for virtually everyone, as di
Re: (Score:1)
Apparently you have not heard of CPAN, the first large pubic opensource library repository that became active and available in 1994 or 95. It was the first of its kind to make automatic dependency resolution and unattended installation a breeze.
CPAN and the reliance of many Perl authors on it was one of the primary reasons why I kept my distance from anything Perl. I considered this a bad idea in the 1990s, and I still consider it a bad idea today.
To be fair, this is Apple's entire business model. (Score:2)
All of their "privacy" and what not is centered around you trusting them first. The rest of them don't even pretend.
I'd love to use it but dependencies scare me (Score:5, Insightful)
It always annoyed the hell out of me to run random binaries from the internet without any real control over what they can access.
Totally agree! But when I tried to build landrun it downloads code from several github accounts. Random dependencies from the internet are a worse security risk than what it is trying to solve. I'd sandbox Firefox (the only binary to be an obvious entry point for hackers on a typical desktop machine). But for this I need to trust that none of the github accounts "russross", "urfave", "cpuguy83" or "xrash" on github have been compromised by hackers (unlikely but not impossible), and therefore increases the attack surface.
go build -o landrun cmd/landrun/main.go
go: downloading github.com/urfave/cli/v2 v2.27.6
go: downloading github.com/landlock-lsm/go-landlock v0.0.0-20250303204525-1544bccde3a3
go: downloading kernel.org/pub/linux/libs/security/libcap/psx v1.2.70
go: downloading golang.org/x/sys v0.26.0
go: downloading github.com/cpuguy83/go-md2man/v2 v2.0.5
go: downloading github.com/xrash/smetrics v0.0.0-20240521201337-686a1a2994c1
go: downloading github.com/russross/blackfriday/v2 v2.1.0
Re: (Score:3, Interesting)
It always annoyed the hell out of me to run random binaries from the internet without any real control over what they can access.
Totally agree! But when I tried to build landrun it downloads code from several github accounts. Random dependencies from the internet are a worse security risk than what it is trying to solve. I'd sandbox Firefox (the only binary to be an obvious entry point for hackers on a typical desktop machine). But for this I need to trust that none of the github accounts "russross", "urfave", "cpuguy83" or "xrash" on github have been compromised by hackers (unlikely but not impossible), and therefore increases the attack surface.
go build -o landrun cmd/landrun/main.go
go: downloading github.com/urfave/cli/v2 v2.27.6 go: downloading github.com/landlock-lsm/go-landlock v0.0.0-20250303204525-1544bccde3a3 go: downloading kernel.org/pub/linux/libs/security/libcap/psx v1.2.70 go: downloading golang.org/x/sys v0.26.0 go: downloading github.com/cpuguy83/go-md2man/v2 v2.0.5 go: downloading github.com/xrash/smetrics v0.0.0-20240521201337-686a1a2994c1 go: downloading github.com/russross/blackfriday/v2 v2.1.0
Yeah agreed, the "Supply chain" problem of OSS will bite us in the ass someday, although if you are willing to trust me, you should definitely trust likes of unfave! :)
Re:I'd love to use it but dependencies scare me (Score:5, Insightful)
First thing, thanks a lot for this awesome contribution. I have used firejail and your tool improves by being simpler and elegant. I am willing to trust you, in particular because your code is short and easy to read (nothing looks scary or obfuscated). But then I also have to read dependencies, and those might also have dependencies.
The recent attack on Disney was an engineer who trusted code on github. The account was legitimate and the code useful, but had been compromised by hackers (see this thread, it also includes links to the reddit discussion: https://it.slashdot.org/commen... [slashdot.org] ).
There is a similar discussion about the standard library of Rust (e.g. https://nindalf.com/posts/rust... [nindalf.com] ). Some argue that a small standard library makes it difficult for rust to be adopted in secure environments because any useful code needs many crates, you'd need to audit them at each new version and that's impractical.
In short I'll wait for the distro I use to package your tool and all its dependencies. The supply chain problem has bitten us hard already with npm and pypy, and I am reluctant to take more risks than just trusting a Mozilla binary.
Re: (Score:1)
Re: (Score:2)
I don't think OSS Distro package maintainers really have the time to go through the source before pushing package tho...
That's true. I also have a little hope for the "thousand eyes" effect. Once a package version is in one or several major distribution, it's enough for one of the many Debian or Fedora users to fall as victim and report it to shut down the entire thing long before I install it.
Re: (Score:1)
Re: (Score:1)
Re: (Score:3)
Pulling in raw source deps from out on the internet is a fucking cancer.
This shit is all open source licensed. Put the version of the library you used in your source.
Is that inherently safer? Of course not- You could as easily be compromised. But at least the chain of trust doesn't turn into a fucking cobweb of trust.
Re: (Score:2)
Re: I'd love to use it but dependencies scare me (Score:3)
I can't remember a build that went off and downloaded dependencies on its own. They throw an error and tell you to install prerequisites. Which you are free to do from source, if you so desire.
Re: (Score:3)
"go build" and "go install" will normally pull in (recursively) the dependencies that are declared in the manifest for the package you're building. This is balanced by the versions being identified by cryptographic hash of the contents, so a vulnerable or malicious version would need to be listed by the downstream package.
Re: (Score:2)
it downloads code from several github accounts. Random dependencies from the internet are a worse security risk than what it is trying to solve.
What a shitty comment. Github accounts are not "random dependencies from the internet." Obviously your bogus assertion is just as shitty as your bogus premise. Feh.
Re: (Score:2)
Github accounts are not "random dependencies from the internet."
They are if you're not checking each one to make sure it hasn't been compromised.
Re: (Score:2)
Bullshit they are exactly "random dependencies from the internet." because people like you are not capable of going through the code and vetting them your just blindly hitting the install button like any other Microsoft user.
Re: (Score:2)
Bullshit they are exactly "random dependencies from the internet." because people like you are not capable of going through the code and vetting them your just blindly hitting the install button like any other Microsoft user.
You are trusting the original author to have chosen reasonable dependencies and locked the to a given safe checksum. That at least gives you traceability about who made the decision to use a specific version. The original author won't, however, have actually checked this particular version of a particular package. The correct solution is to get this integrated into actual Linux distributions where the distributors do the supply chain protection.
Re: (Score:2)
The correct solution is to get this integrated into actual Linux distributions where the distributors do the supply chain protection.
Bingo.
If you're never heard of it... (Score:4, Informative)
landlock(7) — Linux manual page [man7.org]
Landlock - unprivileged access-control
Landlock is an access-control system that enables any processes to
securely restrict themselves and their future children. Because
Landlock is a stackable Linux Security Module (LSM), it makes it
possible to create safe security sandboxes as new security layers
in addition to the existing system-wide access-controls. This
kind of sandbox is expected to help mitigate the security impact
of bugs, and unexpected or malicious behaviors in applications.
This anything like Bubblejail? (Score:2)
It's based on Bubblewrap. [github.com] It's also like Firejail without root access required.
Re: (Score:1)
It's based on Bubblewrap. [github.com]
It's not based on Bubblewrap
Rust version is called hakoniwa (Score:2)
Just in case you were lamenting that it's not written in Rust, fret no more, you can find one at https://github.com/souk4711/ha... [github.com]
I wasn't able to make hakoniwas file-based restrictions to work, though. Complains about "fully incompatible access-rights". And its cli tool documentation is worse. Overall it seems the tool linked here is better.
How does it compare to bubblewrap? (Score:3)
The example in the article looks like the usecase of bubblewrap.
Re: (Score:2)
I can't imagine it's as versatile or practically useful as Bubblewrap. It's based on limiting syscalls rather than namespaces, and too many processes are going to need access to too many for this approach to make sense. It makes sense when developers opt in, but not as a wrapper like the approach being tried here.
Re: (Score:3)
I especially use bubblewrap for when I want to hide systemfiles. That's rather complicated with firejail, but sometimes one may not want programs to read private information from /etc. Maybe you've hidden /home, but all the usernames are still readable in /etc/passwd. With firejail you can bind files to hide such information.
An alternative in C (Score:1)