Our great sponsors
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The Cosmopolitan Libc project has a very modest scope that isn't nearly as big as you suppose. We only support x86-64. We're not trying or claiming to be the ones who will carry the pledge() burden for the whole Linux world like glibc and Musl too, even though (so far) our implementation seems to do a reasonable job at that.
As for the moving target of the Linux system call ABI, we mostly use a whitelist model so I don't see why it should matter. Unless your concern is that we keep up with the latest new features. My humble opinion is there's very few system calls that've been introduced in the last ten years that I care about using. Other people might care about things like io_uring and statx() but I tend to stick with the classic calls.
Keep in mind, Cosmopolitan Libc supports six operating systems. If you look at https://github.com/jart/cosmopolitan/blob/master/libc/sysv/s... you can see that there's a point in history where consensus between systems drops off and Linux goes its own way. It probably happened sometime around the year 2000, and since then Linux has mostly just gone its own way as far as UNIX systems are concerned. There's only been a select few system calls introduced in the last twenty years that every single system was quick to adopt, e.g. getrandom(), pipe2(), openat(), fstatat(), etc.
Very nice! I'm a fan of OpenBSD and pledge(). I've had some success on Linux with libseccomp[0] which means you don't have to deal with BPF directly, but pledge() is obviously much much easier.
0. https://github.com/seccomp/libseccomp
https://github.com/gnoack/seccomp-scopes/blob/master/pledge....
IMHO the better approach on Linux is going to be Landlock (https://landlock.io) in the future. I'd encourage you to look into it.
Great work!
>.. So how do we get it that simple on Linux? I believe the answer is to find someone with enough free time to figure out how to use SECCOMP BPF to implement pledge.
> There's been a few devs in the past who've tried this. I'm not going to name names, because most of these projects were never completed.
I guess I am also one of those. I am giving it a shot with my WIP sandboxing library, which aims at making sandboxing easier for applications in general: https://github.com/quitesimpleorg/exile.h. It also aims to fix the "file system blind spot" mentioned in the article, by using Landlock and Namespaces/chroot.
Though I am calling my attempt "vows" instead of "pledge" to avoid misunderstandings. At the the end of the day, pledge() cannot be pledge() on Linux, due to limitations which the article also mentions.
Nevertheless, as has already been mentioned in this thread, as all attempts, mine also suffers from the fact that one has to keep up constantly with kernel releases and all software must recompiled from time to time against new library releases. This is a suboptimal situation. Secondly, there systems calls with currently cannot be filtered with seccomp BPF, such as openat2() and clone3() and so on.
Therefore, at this time you cannot have pledge() on Linux properly. So I am putting it on hold until deep argument inspection lands.
Overall, my experience led me to believe in order to have true, partical pledge() on Linux, it must be implemented in the kernel ultimately.
Here's a landlock wrapper for FireFox: https://github.com/62726164/misc/tree/main/go/landlock/firef...
It's more restrictive than Firejail and is not suid.
Unfortunately the Linux port was never incorporated and is apparently now abandoned: https://github.com/google/capsicum-linux
I am just its (mostly happy) user. I wrote that rule on my phone so you are right, it is not complete. On the other hand raw sockets require CAP_NET_RAW capability which is often assigned to root only so running a capability-untreated binary as an unprivileged user should not allow any raw socket ops (ping often uses file capabilities or setuid root).
AFAIK it requires root to load/reload profiles. And that is fine for me, my use-case is hardening of services running on my server.
For ad-hoc restriction of untrusted software you can already use stuff like FireJail https://firejail.wordpress.com/ I just don't think a new syscall would be such a benefit but I am not the one to decide. :)