I’ll try it, but just off the bat, how does this compare to bubblewrap?

If I understand it correctly, landlock is an API used by an app to sandbox itself. The app itself controls the sandboxing. Bubble wrap is user space tooling external to the app, so the app had no direct awareness or control of its sandboxing. The scenarios each is intended for are orthogonal to one another.

Landlock can be used to sandbox a launched sub process, as it is here, just as the Kernel APIs used by Bubblewrap could (and sometimes are!) used by programs to sandbox themselves.

not exactly correct. bubblewrap, firejail, and i not sure, but maybe even apparmour, all remove capabilities and create+join restricted fs/net namespaces, and then fork the actual thing you want to execute. so it's exactly the same concept, but those use the cap and cgroups.

I also would like to understand the differences relative to bubblewrap

Bubblewrap is very limited, for example it doesn't allow to grant access to /proc/self/exe without giving access to whole /proc subsystem. So I had to write an emulation of /proc in Python and mount it with FUSE to work around this. I wonder if this issue is fixed in landlock, firejail and others.

Also bubblewrap cannot ask for a decision in runtime: you must set up the rules beforehand.

Emulating /proc isn't super interesting when you can simply enter a new process namespace.

This doesn't allow hiding things like /proc/cpuinfo or /proc/cmdline or /proc/modules etc.

Same question. One thing I really dislike in Bubblewrap is that I must share the whole net user namespace even if all I want to do is use UNIX domain sockets.

Since I only see net options specifying ports, does this handle this use case?

> if all I want to do is use UNIX domain sockets

I routinely --unshare-net with UDS ro-binds.

You may be using abstract sockets (@/path/uds.sock) and those do require the same netns I think.

Landlock supports scoped abstract UNIX socket: https://docs.kernel.org/userspace-api/landlock.html#ipc-scop...

Landlock doesn't use namespaces, they are orthogonal.

This seems pretty nice, as it using directly landlock API from the Linux Kernel (like pledge from OpenBSD). One feature I would like to have is like yaml description for some set of configuration rather that use all this arguments. So we could have preconfigured commands and just execute them. But I think it is just a matter of taste. I will try the tool. Thanks for it.

That could be a separate wrapper, like bubblejail is for bubblewrap. Landjail?

If you want a file format, I'd lobby for one of the existing ones rather than some random yaml one

- sandbox-exec's scheme one https://github.com/BrianSwift/macOSSandboxBuild/blob/main/co...

- AppArmor https://wiki.apparmor.net/ (although I'm cognizant that tries to address way more than just filesystem access)

- Java's permission one https://docs.oracle.com/javase/8/docs/technotes/guides/secur...

Likely tens more

I agree that re-use file format could a good option. BTW the used landlock go library has sort of example https://github.com/landlock-lsm/go-landlock/blob/main/exampl...

Still early but Mickaël Salaün, the author of landlock, is working on this.

https://github.com/landlock-lsm/landlockconfig

I'm going to write up some Go bindings for this when it becomes relevant.

(Author of go-Landlock here)

Awesome! I'm happy to hear that you and others are interested in the configuration language. We should probably coordinate that on the Landlock mailing list when the time comes, so that we don't duplicate that work. We are open to outside contributions :)

Would be cool to see integration of landlock with configuration file in a way that a service launched by systemd can apply the configuration to the executable.

Akin to systemd SystemCallFilter directive for no-code application of seccomp filters to the sandboxed process https://www.freedesktop.org/software/systemd/man/latest/syst...

We are working on a JSON/TOML format for Landlock, with the related library, and bindings for several languages: https://github.com/landlock-lsm/landlockconfig

We are working to make it part of the OCI runtime specification too.

Using existing configuration format would not work because Landlock has its own unique properties: unprivileged, nested sandboxes, dedicated Linux syscalls, and a good compatibility story with opt-in and incremental features.

I didn't have much luck with one of the readme examples:

    # rm -f /tmp/foo; ./landrun-linux-amd64 --log-level debug --ro /usr/bin --ro /lib --ro /lib64 --rw /tmp touch /tmp/foo
    [landrun] 2025/03/22 10:28:02 Sandbox config: {ReadOnlyPaths:[/usr/bin /lib /lib64] ReadWritePaths:[/tmp] AllowExec:false BindTCPPorts:[] ConnectTCPPorts:[] BestEffort:true}
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /usr/bin
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /lib
    [landrun:debug] 2025/03/22 10:28:02 Adding read-only path: /lib64
    [landrun:debug] 2025/03/22 10:28:02 Adding read-write path: /tmp
    [landrun:debug] 2025/03/22 10:28:02 Applying Landlock restrictions
    [landrun] 2025/03/22 10:28:02 Landlock restrictions applied successfully
    [landrun] 2025/03/22 10:28:02 Executing: [touch /tmp/foo]
    touch: cannot touch '/tmp/foo': Permission denied

Looks very interesting. I'm achieving something somewhat similar by running soeme processes under docker and mounting volumes ro, but could definitely see a usecase for adding landlock to more server processes.

Would be possible/make sense to use landlock on OCI/containers land?

Syd[0] uses landlock (among many other mechanisms) to containerize applications and provides an OCI-compatible interface.

[0]: https://gitlab.exherbo.org/sydbox/sydbox

thanks for the link, Sydbox seems like a super cool project, but there's something weird about it: too many links in the README. not on GitHub, and the project that's on GitHub with a similar name hasn't had a commit in 16 years, is it by the same person?

if they can polish up the public facing side of the project, it would instill more confidence.

> too many links in the README

In other documents too. And very repetitive.

I don't need a link to Wikipedia every time "PoC" is used. Or to an online man page every time strace(1) is mentioned.

I get it that a documentation can have more than one "entry point", and hyperlinking all occurrences solves that.

But I think assuming certain audience leads to a document that is more effective. You don't explain addition in university-level textbooks, to make it easier to children from primary school.

This product is simply not for people who hear of strace for the first time.

Eh. Personally I find it refreshing to see a page err on the side of too many links instead of too few. No need to explain addition in any book if you can just link to the best explanation available.

The bigger issue IMO is that the links seem to be automatically-generated, and the generation is a bit sloppy; for example, the "Syd" links should probably link to the sandboxing technology instead of Pink Floyd's original frontman.

> the links seem to be automatically-generated, and the generation is a bit sloppy; for example, the "Syd" links

I dare you, check the git history! (if you care anyway)

It's all manually crafted, with love. From the Shine On You Crazy Diamond badge at the top down to the very last link.

Fair enough lol

Some Wikipedia articles themselves do this, linking every common word in the article, which makes trying to simply highlight a section of text a fun adventure. I ended up at one point making a userscript to strip all internally-pointing links just to make an article more readable (as an addition to an existing script that stripped all the "[citation needed]" and other noise).

Wikipedia needs some notion of "suggested links" that don't become links unless the text is selected or they're toggled globally or some other explicit action. With those, authors could go and link every last word if they like.

> which makes trying to simply highlight a section of text a fun adventure

Tip: in Firefox, you can hold Alt to drag and select text without triggering links.

TIL. I wish I knew years ago, I've never been happier to have switched.

Still using Chrome for work stuff, since profile management in FF is still pure hate.

what's wrong with `firefox -ProfileManager` and the like or alternatively containers?

I always seem to end up with duplicate profiles, or `about:profiles` refuses to open ("Another copy of Firefox has made changes to profiles.") and on and on with various hiccups and speedbumps. Small annoyances, but profiles on Chrome always Just Work, and the half-dozen times I tried it on FF was always death by a thousand cuts.

It's been a few years, so I'll give profiles another try I guess. Containers likely won't do it since multiple profiles all use the same domain (console.aws.amazon.com being the obvious one).

Containers don't need to auto-open domains. You can simply use them to "color" tabs manually. That should cover your needs!

I thought Wikipedia recommended against overlinking, and on looking it up, they do:

https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style/Link...

I agree regarding polishing the public-facing side of the project, though I don't find it particularly problematic that it's not on Github.

that looks really cool, but unfortunately without any obvious examples or even a link to documentation, I'm closing the tab and likely forgetting it exists... I would assume many others would feel the same way.

True! I had the same feeling.

From the README:

> Read the fine manuals of syd, libsyd, gosyd, plsyd, pysyd, rbsyd, syd.el and watch the asciicasts Memory Sandboxing, PID Sandboxing, Network Sandboxing, and Sandboxing Emacs with syd.

I do agree, though, that the docs could be improved.

this looks cool, thanks for sharing. they have linked a ctf event as an interactive example, what? XD

This is the minimum options I needed to get it to work:

landrun --log-level debug --exec --ro /usr/bin --ro /usr/lib --rw /tmp touch /tmp/foo

Personally I don't like that --exec would allow binaries in /tmp to be executed as well...

But

`landrun --ro /usr/bin --ro /lib --ro /lib64 --rw /path/to/dir touch /path/to/dir/newfile`

vs

`landrun --ro /usr/bin --ro /lib --ro /lib64 --exec /usr/bin/bash`

seems to indicate that `--exec` is only required if the command you're executing then uses an `exec`-call internally, which `bash` would need to be able to fork.

So `touch` should not need `--exec`, while `bash` should be able to run anything it can read (including that whitelisted `/tmp`).

The former does not work for me, I have to add --exec. I can only assume it's because touch is in /usr/bin and so it needs permission to execute it from there.

It seems that using --ro or --rw at all makes --exec also mandatory.

well yeah you'll need --exec when you want to run binaries (unlike... cat?) I hope landlock adds support to bind --exec to actual directories, that'll be fun!

> you'll need --exec when you want to run binaries

well when wouldn't it do that? in what scenario could you even use this tool without needing to execute a binary?

running cat isn't a --exec for one :)

how so?

$ landrun --ro /usr/bin cat a

[landrun:error] 2025/03/22 23:50:16 permission denied

in this case doesn't have access to "a" wherever it is...

$ landrun --ro /usr cat /usr/bin/ls | wc -l

400

executing ls (as in actual binary execution) will require --exec

$ landrun --ro /usr ls /usr/bin/

ls: cannot open directory '/usr/bin/': Permission denied

$ landrun --ro /usr --exec ls /usr/bin/

list of billions of files

note that I don't really love the --exec thingy, if it's not "on" by default it's just for sake of being explicit.

--ro /usr does not apply to /usr/bin. change it to --ro /usr/bin and then cat will refuse to run.

it's recursive by default

well it's not working. please try it

give it a try with v0.10: landrun --rox /usr/ --ro /usr/lib ls /usr/bin/

As a workaround you could create a tmpfs device like /tmp_noexec with noexec flag, and mount it instead of the normal /tmp. But landrun does not (yet?) allow changing the name in directory options :(

For added security, I'd create an ephemeral tmpfs disk for each landlocked invocation: obviously the program we're running has no business seeing what other processes may have put to /tmp.

> I'd create an ephemeral tmpfs disk for each landlocked invocation

And now you've just invented firejail.

UX-wise, yes. Internally firejail and landrun use different isolation APIs.

Firejail supports Landlock though: https://github.com/netblue30/firejail/pull/6078

yeah you are missing --exec there, which feels a bit useless that you have to mention it, but I prefer things explicit and use all LSM can provide, I can imagine cases where --exec isn't really required. like `cat`.

either case have a look at latest release, it's a bit cleaner.

Could you please help me understand why exec is required for this touch example? Is it necessary to actually launch the touch binary? Or touch itself exec()s something else?

This might be related to needing execute permissions (filesystem x bit) on the directory to modify files within.

Got it. I thought it had to do with execve() syscall.

  // If we have no rules, just return
  if len(rules) == 0 {
      log.Info("No sandbox rules to apply")
      return nil
  }

Really cool and well-written project, but I disagree with this choice: No rules should mean no rules (everything denied).

I would have suggested support for more fine-grained file/directory permissions—good to see that’s already planned.

Yeah I agree with that, just release a new version that does that.

Does Linux 6.8 in fact ship ABI v5? At least it’s not guaranteed (Ubuntu 24.04, 6.8.0-55-generic). This post suggests 6.10: https://lore.kernel.org/landlock/20240716.yui4Iezai8ae@digik...

good catch, fixed.

> but nobody uses it because the API is ... hard!

OpenBSD really got it right with pledge and unveil.

OpenBSD did get it right, but they also have a more relaxed scheme for backwards compatibility across releases. Linux's strict ABI compatibility guarantees complicate matters slightly, but with the right supporting library it becomes tolerable.

See the example at the top of the Readme at https://github.com/landlock-lsm/go-landlock

(Full disclosure, I am the author of that library)

FWIW, I do hope that we can motivate people to use Landlock in the same way as people use pledge on OpenBSD, as a lightweight self-sandboxing mechanism that requires fewer architectural changes to your program and results in more constrained sandboxes than Linux namespaces and other mechanisms do.

As far as I know the ABI for pledge and unveil really haven’t changed since release? What is stopping linux from creating NEW security primitives which are easy to use? We have wireguard in the linux kernel as a recent addition. Wireguard shows that new simple primitives can be added to the kernel, it requires someone with “good taste” to do the implementation without sacrificing usability.

BSD systems ship a kernel and user space, which simplifies a lot of things. Linux is more flexible but it comes at a cost. Adding new security features can also be challenging for other reasons. Anyway, Landlock is one of these new security primitives, and it is gaining new features over time.

The Landlock interface must not change the underlying semantic of what is allowed or denied, otherwise it could break apps build for an older or a newer kernel. However, these apps should still use all the available security features. This is challenging.

Landlock provides a way to define fine-grained security policies. I would not say the kernel interface is complex (rather flexible), but what really matter are the user space library interfaces and how they can safely abstract complexity.

I know how linux and bsd work. I still have yet to find a satisfactory answer to why linux cannot create security primitives which are useful — like wireguard. I understand that landlock tries to abstract complexity, but why do we need to design complex user interfaces? Pledge and unveil are just simple syscalls, there is no magic secret sauce on BSDs which enable these syscalls. It is true that bsd userspace has been compiled to bake in plege and unviel syscalls, but that is totally separate from the usability of the interfaces.

For instance, with Pledge, the "dns" promise is implemented with hardcoded path in the kernel. Linux is complex because it is versatile and flexible. Controlling access to such features requires some complexity and the kernel might not be enough.

About interfaces, another example is that Unveil is configured with path names but Landlock uses file descriptors instead (more flexible).

Also, these OpenBSD primitives only apply to the current executed binary, there is no nested sandboxes because the goal is not to create this kind of secure environment but mainly to secure a trusted binary.

For a given linux libc function (what a program calls), the underlying kernel syscall might change over time or vary for other reasons. Since the landlock/seccomp filters are at the kernel level, that breaks programs which only interact with libc calls and don't expect different behaviour.

The underlying kernel syscall should never change, though, right? Pretty sure that's the sort of userspace-backwards-compatibility-breaking change that would result in one of Linus' famous angry emails.

Things like clock_gettime64() to handle dates past 2038.

Calling clock_gettime() in libc will call the newer syscall (assuming __TIME_BITS=64 is set). But Linux has kept backwards compat, old programs can still call the old syscall.

If you wrote your seccomp rule for your program before clock_gettime64 existed, it'd break when glibc switched. I guess that implies each language stdlib should have their own seccomp etc wrappers.

For landlock, the equivalent is that glibc reads various files in /etc varying per libc version or system settings, so landlock rules need to account for that.

> Since the landlock/seccomp filters are at the kernel level

That arguably shows that seccomp is operating at the wrong abstraction level, or the kernel needs another higher level api. With pledge, you operate on capabilities and as new functionality is added to the kernel it is categorized under existing capabilities (for example, if your program pledges not to use networking you can assume that it should not be able to use new networking syscalls added to the kernel in the future).

Seccomp is not an access control system, but Landlock is. Seccomp limits the kernel attack surface and Landlock enforces an access control. They are complementary.

With Landlock, the access control is at the right layer, and the semantic is guaranteed to be the same even if the kernel gets new syscalls. Landlock is the closest thing to Pledge/Unveil we can get with the Linux constraints (and it is gaining new features).

I have been using https://github.com/marty1885/landlock-unveil on Linux for about two years now on my stock Ubuntu kernel. I am not sure, why this hasn't become more popular. It's also rootless sandboxing (and it does `unveil` like OpenBSD I guess). I use it to confine builds of third party software with success.

This is where I need to shout out to everyone's favorite developer Justine for keeping Linux cool:

https://justine.lol/pledge/

Which also points to landlock-make[0] or vice-versa (the original project that made me aware of the kernel functionality (although didn't realize it also isolated network which is great).

[0]https://justine.lol/make/

I disagree. Android's model of starting with a strong sandbox and having apps request permission to acces things outside of it has been much more successful in getting apps to be sandboxed.

Defaults are important.

I think that isn't good enough either (but at least they tried).

My operating system design is: programs start with nothing other than the ability to perform deterministic computation and to send/receive messages with the capabilities it receives in the initial message. It is not allowed to know what these capabilities refer to; they may be proxies set up by the user, network resources, or something else, and is not necessarily what it asked for. All I/O including the ability to determine the current date/time or how much time has passed, requires the use of capabilities. (Due to this, a program with no capabilities left can be terminated automatically by the operating system (unless a debugger is attached; it is also necessary that the program cannot notice the debugger attached to it), since it is no longer capable of any I/O.)

Is argue it is good enough, but yes it could have gone farther. But ultimately permissions for things like audio would be automatically granted so in the end you end up around the same place.

Similarly to the bubblewrap comment, I'd also like to know how it compares to nsjail.

I think nsjail uses mount namespaces (CLONE_NEWNS) instead of landlock for filesystem sandboxing, but what would the practical differences be?

Are (abstract) unix sockets supported?

I'm trying to run a self-contained webserver executable without any external dependency. It starts but daemon <-> workers communication doesn't seem working (it is done via unix socket)

It works fine with bubblewrap or inside a scratch docker container.

aren't abstract sockets un-jailable unless using network namespaces?

or in the other direction, to truly prevent e.g. xorg socket from being accessed by a bubblejailed application, it should exclude --share-net, regardless if you bind the actual path to the socket (since abstract permeates beyond that)

Well, so should it work?

You're telling me there's another reason, then... Can't guess which one.

Hmmm...

they can be jailed by landlock, we don't have support in go-landlock tho afaik, @Gnoack

It's tracked in https://github.com/landlock-lsm/go-landlock/issues/35 - signals and abstract Unix sockets do unfortunately not interact well with the inherently multithreaded Go runtime. We are working on a fix in https://github.com/landlock-lsm/go-landlock/issues/36 but this needs to be on the kernel side and this is delaying this feature in Go, unfortunately. It is usable from (single threaded) C programs though.

Thanks!

V0.1.3 is out now!

How does Landrun compare to Firejail?

I’d recommend adding your first (and maybe second) paragraphs directly to your readme - this is a much clearer description if you don’t know what landlock is already!

I agree. The first section of the README leaves the impression that Landrun comes with a kernel module -- that would be a red flag for me. The fact that it uses an existing kernel module that is in the mainline is going to be critical to anyone using Landrun.

There's conflicting information in the readme about whether --best-effort is enabled or disabled by default.