> but nobody uses it because the API is ... hard!
OpenBSD really got it right with pledge and unveil.
OpenBSD really got it right with pledge and unveil.
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.
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.
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.
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.
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).
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).
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).
Defaults are important.
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.)