Show HN: Porting OpenBSD Pledge() to Linux
justine.lol
justine.lol
One of the best introductions I've seen to pledge() is Kristaps Dzonson's writeup on it that you can find here [1]. The whole website in general is furthermore a guide on how to write webapps in C, which may sound like a crazy idea to some people who have written it off as everything from an elaborate joke to a security nightmare that nobody should ever consider doing [2], but for people like me who end up having to write that kind of code in constrained execution environments it's been extremely enlightening and I really appreciate knowing how to do it more securely. If pledge is something I can access in Linux it really helps me out for things in the future going forward, I hope to create some cool things with it!
It might take a little while to catch on in those use cases but I've been waiting for someone to nail the implementation for a while. It's hardly a surprise that you of all people got it down, I've been admiring your work for quite some time.
So how about those blog posts in Mayan Hieroglyphics?
Why? This library obviously assumes you have an operating system running, so it's not that constrained of an environment.
Playstation's SDKs in particular is a strictly C/C++ (And I think C# via Xamarin) environment, you're not going to be making games in something like Rust or Go for that platform. Lua is an exception - see what Justine does with redbean [1], it's very lean and meant for this kind of embedded use, but something with its own full networking stack built into it like Python? Forget about that if you want to spare your users the trouble. It may compile, some may use it in their internal scripting engines, but it's just a huge why would you do that to me and everyone else I personally know involved in doing that kind of development. If we're talking about security here as well, if you know the stack you wrote from top to bottom with very small (Easier to audit), well-written libs, it's a lot more reliable to write your own if you're confident enough in these lower-level environments and using tooling for auditing (ASAN and UBSAN are real game changers as well), like what Justine mentioned here, than having to put up with some bug down the line in some interpreter you didn't write; Issuing patches for every single user just to get the interpreter's implementation secure again is what you end up doing.
As for salaries when looking at the data I stand somewhat corrected, you're probably right on compensation based on experience, too. It looks like the top three averages on the latest survey I can quickly find are Rust, Go, and Scala. [3]
[1] https://en.m.wikipedia.org/wiki/Google_LLC_v._Oracle_America....
[2] https://www.theregister.com/2022/03/22/oracle_starts_to_incl...
[3] https://www.zdnet.com/article/developer-jobs-and-programming...
Google's use of Java in Android. I can't claim to know the exact details of how the company reacted to the lawsuit internally, but I will point suggestively at the fact that Google is still running most of their Java code in production and continues to write more, and their support for Java on Android stagnated at Java 8-ish and Kotlin is now heavily promoted as the language to write software for that platform.
Yes…
> since it makes the unsafe keyword safe!
No. It's a debugging tool to help, but saying it makes the unsafe safe is a somewhat dangerous hyperbole.
Why pledge(2) or, how I learned to love web application sandboxing - https://news.ycombinator.com/item?id=13037442 - Nov 2016 (73 comments)
Many OpenBSD ports contain pledge() support. Steal all you can. OpenBSD does "hoisting" in many userland programs, meaning all the open calls and such take place at the very start but isn't actually parsed until after we have locked ourselves in with pledge() and unveil(). I hope this also means many non-base programs are redesigned in this manner.
Of course the problem is that it needs some cooperation between libc and the kernel. That's why it's easier for OpenBSD to provide it.
You may have missed that our new pledge() impl is hosted in the Cosmopolitan Libc repository. So we've got cooperation. Therefore it'd help to clarify when you say this project won't get us there, that you're only speaking for glibc. pledge.com works fine with everything else like Musl and Cosmo Libc. It even works with glibc most of the time. One can't reasonably expect cosmo to need to support glibc before being able to support itself. We've learned today that folks want this. So the Glibc dev team should be doing more to help us. What I fear is that they're focused on different things.
You have libc, which does mean it's in sync with dynamically compiled binaries against your libc, with the other drawbacks I mentioned too.
And you need kernel maintainer cooperation too to "bring pledge to Linux".
That and they invented it.
OpenBSD is able to provide these things because they have a different organizational model.
Or to put another way: Linux is shipping the org chart.
OpenBSD can do some other interesting things because they don't have the mantra of "we don't break user space". Neither is wrong, just different. High level strategies like these affect commercial success and also the abilities to ship technical solutions.
Or on the topic of the article here: Yes, if you replace libc, restrict to just one arch, and put many other restrictions on userspace, then under those circumstances your only "opponent" is the kernel, and you can implement something partially like pledge().
But really, that means that you solve the multiparty problem by kicking out everyone who's in your way, who you can't get rid of (namely the kernel).
You may want to familiarize yourself with the Hacker News guidelines: https://news.ycombinator.com/newsguidelines.html
I noticed that you're missing the sendfd promise. Is there a reason for that omission? Also you've added a number of extensions that perhaps should be documented as such.
Also there's a pretty significant undocumented difference between your implementation and OpenBSD, in that promises are by inherited across exec in yours, and not on OpenBSD.
OpenBSD experimented with that by specifying the second argument as execpromises, but discovered that it was extremely difficult if not impossible to write meaningful execpromises in the parent for potentially unrelated programs, it's also happening too early before dynamic linking, and before the program has had an opportunity to "initialize" or "do privileged stuff" and call pledge(2) later itself with more accurate knowledge of what to self-restrict. As such, no calls with execpromises set to anything but NULL/0 exist today. I'm curious how to reconcile those differences.
One suggestion I might add, it would be worth trying to compile any of OpenBSD's privilege separated network daemons on Linux (w/ Cosmopolitan Libc, or others). While you may have intended to use this facility primarily for your own APE Binaries, I suspect you'll find that the despite your intentions to make this compatible with the C API definition of pledge(2), in practice, your implementation is incompatible with privsep/privdrop software, for which pledge was designed. It was never intended for application "sandboxing".
I guess landlock can't help you here since it is still mostly about filesystem access right now, but maybe someday? It looks like "minimal network access control" is on the long term roadmap: https://landlock.io/
BPF programs attached to syscalls (via kprobe or fentry) can read arguments via helpers (bpf_probe_read_{user,kernel}). Seccomp uses "classic BPF" which has no concept of helpers or calls.
>.. 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.
As someone else who's banged their head against seccomp and given up (put on hold) I have to say that you're missing one roadblock though. It's not enough that the kernel gets pledge(), but libc needs to cooperate too.
E.g. as I found in https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h... the first printf() you do will do a newfstatat() syscall.
So really there's no way for user space to know which syscalls will be called, just based on common sense. libc can call anything and everything.
And this is why I have less hope for a real pledge() on Linux.
Oh, I'll just name myself (see code link below), I'm not ashamed that this didn't complete.
There are more fundamental reasons why these projects don't complete, and they apply to the project linked above as well:
- Maintaining lists of allowed syscalls across kernel versions and architectures is unreasonable to do, and it's a moving target. An allowlist-based approach might break when doing a kernel or glibc upgrade, which breaks the API backwards compatibility that the kernel otherwise guarantees. - Core parts of glibc are doing initialization work on demand, which complicates matters (should ideally be done before enabling the sandbox, but this is not generally possible) - Some pledge() promises can't be mapped correctly; examples: - the "dns" promise in cosmopolitan/pledge.c just permits all outgoing UDP connections, which is more than what OpenBSD permits, IIRC - the "exec" promise cannot elevate privileges again, as it does in OpenBSD - glibc name lookups as they are used for DNS are loading shared libraries on first use (libnss), and it's impossible to tell in advance what these will do unless you control the execution environment - The pledge API itself is a moving target as well (compare https://man.openbsd.org/OpenBSD-6.0/pledge.2 and https://man.openbsd.org/OpenBSD-7.1/pledge.2) - In OpenBSD, pledge was always path-aware, until they moved that part into the unveil() call. This is not possible on Linux with seccomp-bpf. (Well, yes yes, with signals that do syscall trampolines and very very tight control over the runtime environment, or with sidecar processes to do the supervision, but both of these require a lot more dedication and can't be just mapped to a call to "pledge()" on Linux.)
FWIW, my own (abandoned) implementation is at: 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.
That is the approach if you can't regain privileges. In the OpenBSD way it is literally the opposite of waht you propose.
> How is some program going to know what other programs you use will need?
It doesn't? Same issue on linux/openbsd in that regard, with some aspects a bit different due to libc.
> How is the dynamic linker of the later program supposed to deal?
It obviously doesn't, again, same thing on Linux and OpenBSD. It also won't help you to be able to regain privileges via exec if the issue is a shared library.
Allowing for privileges to not propagate is a cool feature that allows you to shell out to a binary that you can't write to (otherwise it's pointless) and have that binary manage its own permissions. That's sometimes important, and Apparmor supports that sort of thing (with child profiles).
But it's also a big footgun that can easily allow a full sandbox bypass.
You can implement the child profile concept easily enough with a privileged broker anyway.
I assume/ hope this is something you can control with better filesystem controls?
Not having an option to opt out when your program voluntarily tries to secure itself is terrible because it means fewer programs can use it to secure themselves. A classic example would be an ssh server. You want to factor it into several components, one that talks to the network and a privileged (root) part that spawns the child processes with arbitrary uids. The latter part can reasonably pledge away a lot of its privileges but its children must run unrestricted (but often on unprivileged users).
Keep in mind that if you can:
1. write to a file 2. Make that file executable (or write to an already-executable file, or an executable that provides scripting/ code exec natively)
And you have the `exec` capability, the sandbox is trivial to bypass in the face of code execution in the pledge'd process.
int main(int argc, char *argv[]) {
CHECK_NE(-1, pledge("stdio rpath wpath cpath exec", 0));
CHECK_NE(-1, open("/tmp/doge.exe", O_CREAT | O_WRONLY | O_TRUNC, 0755));
return 0;
}
I mean it's probably a good idea to close the trivial version of the bypass by disallowing setting exec on files (although you need to check the path because you may want to set it on a directory), but if you can execute `chmod`, write to the i-node directly, write to any other executable, write to your own executable, etc, that's just a full bypass.
I just feel that it's difficult to do in Linux's heterogeneous environment where everyone uses their own kernel configuration and libc variant... the reason is not just the difficult C API (with BPF in it...) but it's also the surprises and weak guarantees in the environment where these programs run.
We should at some point be able to do unprivileged sandboxing, but seccomp-bpf may not be the way to do this at scale.
I agree with all of this fwiw, but I actually was very glad to see this. I find it really weird that the openbsd pledge lets you just escalate out of it.
It's only weird because the normal M.O. with facilities in other environments is to sandbox specific, high-exposure applications, which are typically run in isolation, such as system daemons or end-user GUI applications. The semantics of pledge and unveil were fine-tuned from OpenBSD developers systematically sandboxing almost the entire base system--most command-line utilities in OpenBSD are pledged, as are all daemons.
Inheritance is only a "problem" if you're exec'ing other programs, but the vast majority of programs, even command-line utilities, never need to exec, at least not during runtime (as opposed to startup). Most programs using pledge drop the ability to exec entirely (i.e. don't specify the "exec" pledge), so inheritance is irrelevant as there could never be anything to inherit. (Note that upon the first call to pledge, you lose any capabilities you don't explicitly request.) But if you do need to exec other programs, then inheritance can quickly become a problem--counter-productive, even, as workarounds typically involve the parent program preserving permissions which it might not need directly. (Note that this is also why pledge and unveil are superior APIs to relying on the invoker--e.g. systemd--dropping permissions as only the program itself knows best which permissions it needs and when.)
OpenBSD is developed as a comprehensive system, and it's in this context that you need to understand pledge and unveil. On OpenBSD, if program A exec's program B, program B should be making use of pledge and unveil itself, and if it's not then that can and will be fixed. Unlike in the cat-herding Linux ecosystem, OpenBSD developers have little reason for a security model that prioritizes the ability for program A to implement workarounds for deficiencies in program B; their habit is fixing program B or refactoring A and B so they can work better together.
It's more restrictive than Firejail and is not suid.
The topic of a pledged process starting other processes un-pledged often comes up (and already has done in the comments here). I'd recommend checking out this section of Theo de Raadt's presentation that explains why this is [3].
As mentioned in the article the nice thing of pledge on OpenBSD is the integration of the pledge interface with the reality of underlying system. So as one example a program can pledge only dns and say not have filesystem access, but really under the covers it can read /etc/resolv.conf.
[1]https://www.youtube.com/watch?v=uXgxMDglxVM
If you like I can run pledge against my more complicated app to see if it complains. I did it on a simple app and it seemed to not like how I used memory map (MAP_PRIVATE | MAP_ANONYMOUS | MAP_POPULATE). I also do MAP_PRIVATE | MAP_ANONYMOUS | MAP_POPULATE | MAP_STACK | MAP_GROWSDOWN which might be weird to pledge too
MAP_STACK can be used correctly with Cosmo by saying MAP_STACK | MAP_ANONYMOUS. That's all you need. You can also call Cosmo's _mapstack() function. Cosmo is somewhat unique in that it polyfills the platform-specific underlying flags automatically when you do that. So you shouldn't include MAP_GROWSDOWN because we chose to adopt the FreeBSD behavior which we polyfill on Linux using MAP_GROWSDOWN. See our docs for further details. https://github.com/jart/cosmopolitan/blob/0a589add4167c1b587...
One of the reasons why I use MAP_GROWSDOWN is because it gives me a page guard. Your link mentions/implements a page guard. Well done
I tried my complicated app for fun removing the MAP_POPULATE flag. I get an assert because it seems like mmap didn't align the pointer to 4K. I don't need this to work I was just playing around with it
You REALLY need a committed team to maintain this, and likely ability to fix in a /etc/pledge.conf or something, as syscalls are added and changed.
The hard part is not what jart did, but to keep it working.
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 Linux has introduced in the last ten years that I personally 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 binaries are designed to run on six operating systems. I'm probably the only person on earth who's written a libc for that many platforms. Here's what I learned. 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. 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.
So I really don't think it's as complex as folks here are making it out to be. It's simply a question of focus. We aren't solving every problem. But the few things we are doing, we do very well.
But as you say, it's quite limiting for userspace trying to use things that maybe your libc is not aware of.
Compare how OpenBSD is actually disallowing syscalls outside of their libc. That's the level of control that's needed both for it to work, and I don't think Linux lets you do that.
My point is: No, this does not "port pledge() to Linux". I'm sure you agree that it has many many asteriskses, to the point that the title built up a hope it can't live up to.
I wish it did, but I don't see it.
> We aren't solving every problem.
It's a good effort. But the problem isn't the narrow scope. The problem is "Porting OpenBSD pledge() to Linux", which I don't think is an accurate description of what this does.
And Cosmopolitan Libc actually disallows syscalls to the OpenBSD Libc whilst running on OpenBSD. If this surprises you then you've misunderstood the intent behind msyscall(), which Cosmopolitan's pledge() implements on Linux too. See the "Syscall Origin Verification" section of the blog post https://justine.lol/pledge/#msyscall The basic idea is you can choose whatever set of system call wrappers you want, put them into one memory location, and then the kernel will check the RIP register to make sure that SYSCALL is only being used from those addresses. Their choice to start doing this is kind of funny because it turns C libraries into a game of Highlander. There can be only one.
My understanding is that promises aren't inherited across execve. So that's an incompatibility with openbsd's pledge. And a pretty important one imo because it makes it more difficult to factor out privileged subprocesses (e.g. one doing network things, the other accessing filesystems).
> File system access is a blind spot. OpenBSD solves this with another famous system call called unveil()
That could probably be approximated with user + mount namespaces, a tmpfs and bind mounts. Basically what containers do. But that might suffer from the same process inheritance problems if unveil is BSD-specific, the manpage is unclear about unveil's exec behavior.
$ pledge.com -p 'stdio rpath wpath cpath dpath flock tty recvfd fattr inet unix dns proc thread id exec' curl http://justine.lol/hello.txt
curl: (6) getaddrinfo() thread failed to start
Put differently, ENOSYS tells userspace that the system call isn't implemented and you need use some fallback code. EPERM means that the operation was denied by policy. But in that case, it might not be a good idea to approximate it by using different system calls because it might circumvent the intended security policy.
Keep it up! I’ll be upping my sponsorship in the hopes that you can continue doing this full time.
1. https://manpages.ubuntu.com/manpages/jammy/man1/unshare.1.ht...
2. https://manpages.ubuntu.com/manpages/jammy/en/man2/unshare.2...
[0] I don't think it's meant to disable it, I just know too little about namespaces to appreciate how you would unshare a new network namespace and have it keep working.
More specific critique of seccomp here: https://blog.habets.se/2022/03/seccomp-unsafe-at-any-speed.h...
There is AppArmor which is much more flexible and it is not as complicated and annoying to use as Selinux.
Disabling the internet access is just one line per network:
/usr/bin/prog {
deny network inet,
deny network inet6
}
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/
But I agree that software developers know their software the best so they should be the ones writing the rules and ideally configure them depending on automake/configure paths (i.e. different PREFIX, this software/profile separation is annoying) but pledge() looks too old and non-flexible for such a job IMO. Most software need file ops but don't need to write everywhere.
I'm sure it's great but it requires setuid privileges. If it needs root it isn't ad-hoc.
> But I agree that software developers know their software the best so they should be the ones writing the rules
Exactly! You get it. pledge() is basically an App Store permissions model in spirit. It's curated and, like Android / Apple devs, the developer is thinking about what permissions they'll need to ask for at each step of writing their program. Not needing root is an important aspect of enabling that. The good news is that with SECCOMP BPF and Landlock I think we finally have a comprehensive solution for building the perfect unprivileged sandbox.
4gb and perfectly reasonable are two different things. I'm not sure if there is any sensible default memory limit but if there is one it should probably scale with available memory instead of just hardcoding some magic amount that "ought to be enough for everyone".
New binary available at https://justine.lol/pledge/
spun up a vm and am googling a lot
Nicely done and if we're ever at the same conference link this comment to me and I'll buy your next drink.
However I never really quite understood the idea of limiting the permission of untrusted programs hoping that it won't pown you anyway. If you remove network access and allow file system access, what's preventing the program to invoke itself in your .bashrc ? (Or probably 10s of other ways)
This seems like a pretty cool feature to have in Linux.
[0] https://unix.stackexchange.com/questions/410056/what-is-open...
using strings for 16 categories is certainly not "elite". bits would be fine.
Addressed, yeah, but I would not say solved for the general case of all the namespaces.
"Just put me in a (sand)box" is actually really tricky with namespaces, and depends on if you started off as root or not.
More on using namespaces to drop privs: https://blog.habets.se/2022/03/Dropping-privileges.html (another backburner project)
It's early morning so I may be wrong, but my testing seems to show that actually yes you can still fchdir() your way out of a file system namespace.
But that isn't really an issue with chroot (or namespaces). It's (1) that CLOEXEC is opt-in, not opt-out, and (2) that you need this poll hack to enumerate open file descriptors.