kristapsdz
commented
22 hours ago Thank you for this information! Do you know of any examples for either C, Rust, or Go for landlock to simply disable everything but for stdio and (say) simple memory management? I couldn't find anything searching around and the documentation is pretty dense for somebody like myself who can be similarly dense. :tired_face:
I initially had the Darwin sandbox as seatbelt---I'll look into changing it back. Thanks again!
Hi,
Good to see such study! I'm the maintainer of Landlock so I'll mainly comment on that part.
It would be nice to go a bit further the facts and explain their reasons. For instance, about complexity, a fair comparison between Pledge and Landlock would highlight the fact that OpenBSD ships a full OS (i.e. kernel + user space) whereas in the Linux world there are several versions and configurations of the kernel and several versions and configurations of different user space. This explains why the Landlock kernel interface is more complex than the Pledge one: Landlock users need to be compatible with a wide range of kernels, which is not the case for the main OpenBSD services/apps. Indeed, Pledge can add new restrictions over time (e.g. extend the deny-by-default restrictions), which is not possible with Linux because it could break user space.
Another notable difference is that Pledge is more mature than Landlock which is being developed incrementally. Among the reasons, Pledge is older and developed by the OpenBSD team, working on both the kernel and user space. The Linux world is much more complex (and flexible).
Design decisions for Pledge and Landlock were also different. Pledge emphasis simplicity, whereas Landlock's powers lies into its flexibility. I would argue that with the Landlock (kernel interface) flexibility, we can easily create simple interfaces just in user space with an appropriate library, which is what @jart did with Pledge for Linux. Landlock's flexibility is also required to better fit with the Linux syscalls and specificities. For instance, Landlock relies a lot on file descriptors to build and manage rulesets.
Linux provides seccomp and Landlock as unprivileged security mechanisms, but they are different and complementary: kernel attack surface reduction, and access control. I guess one of the reason why one is more used than the other is because of their age. It would be nice to highlight the age of each sandboxing mechanism (not only Linux ones) for a fair usage comparison.
I'm not sure the language section is relevant because I guess most sandboxing mechanisms have libraries for several languages. For instance Landlock has official Rust and Go libraries, and others provided by the community.
About the number of lines required to create a sandbox, I think the comparison is unfair. At least we should use a tool like SLOCCount to avoid counting useless lines, but this number me change a lot with different languages and libraries. For instance, the same Landlock sandboxer example is much more verbose in C than in Rust, and Go might be even less verbose. Using Landlock with the same API as Pledge would also change the conclusion. There is currently no Landlock C library but only the kernel C headers, which are verbose, but also flexible. Also, it would be fair to compare similar restrictions for each sandbox mechanism and the required SLOCs.
The number of the sandbox users looks weird: it is between 0 and 14, and there is no backing source. Where do they come from? It might be a good idea to add a warning notice about these numbers being "work in progress". For landlocked programs, you can get a few of them listed in the newsletters, the article, and the talks but it is difficult to get the full (public) picture.
About macOS sandboxing, I think the original name is "XNU Sandbox" or "Seatbelt". Avoiding just "sandbox" should help readers too.