A rough description of upcoming network restriction features in Landlock and how they map to the BSD socket API is in the talk at https://youtu.be/K2onopkMhuM?start=2025 starting around 33:45
I really hope we can get back to these features soon :) I think these would be very useful.
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.
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.
(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 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.
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.
Namespaces can also be used for sandboxing, but they have a series of problems. Most importantly, they require more substantial changes to your program that wants to sandbox itself, and the program has to jump through a series of hoops to get everything into the right state. It is possible, but the resulting program environment is in the end more unusual and the mechanisms for enabling unprivileged namespaces are making it difficult to use it for smaller use cases. (It involves re-execution of the program that wants to sandbox itself, whereas with Landlock, a small program can just install a Landlock policy during an early startup phase and continue with that.)
Controlling the rules through a separate process is not currently possible, but it was proposed earlier this month on the kernel mailing lists:
I think in the upstream kernel LSMs are also still the only way to prevent a process from creating child namespaces where it has privileges?
E.g. if you can cat CAP_NET_ADMIN even within a restricted namespace, you have access to huge amounts of horrbly broken kernel code. It's easy (for people who know how to exploit kernel bugs) to escalate privileges from there.
Distros have their own fixes for this issue so namespaces definitely aren't useless in practice for sandboxing. But the basic mechanism just doesn't that well suited to it.
It takes very little resources on my Raspberry Pi and is built to be extensible and safe through its transparent way of storing wiki pages as markdown files.
I find this an offensive comment. The GIGO principle applies to documentation, and we would be in a much worse place if we didn't have the man page documentation written and reviewed by humans.
If you're offended by the idea of a computer generating output from input you should reconsider that attitude. That's what they're for. This use of AI would be similar to a (poor quality) compiler, but for documentation.
A rough description of upcoming network restriction features in Landlock and how they map to the BSD socket API is in the talk at https://youtu.be/K2onopkMhuM?start=2025 starting around 33:45
I really hope we can get back to these features soon :) I think these would be very useful.
reply