Porting OpenBSD Pledge() to Linux (2022)

The comparison with SELinux is a bit off, because SELinux is very different from RSBAC and other ACL-type mechanisms for limiting the attack surface of software. SELinux is much more complex because it takes policy decisions like "this software is a Word Processor, it is not allowed to open files of the type Sensitive Document".

That is very useful for those with that particular need, for others it is unnecessarily complex. A more common use case for regular users would rather be "run word processor without network access". That's where simpler systems shine. There used to be many access control mechanisms for Linux but they seemed to struggle to retain mindshare and remain a bit obscure.

I would guess that's because so much is achieved by the old way of running software under their own uid and a chroot, so anything else already is a special case.

> One of the things I feel OpenBSD has gotten right with pledge and unveil is the placement of responsibility. It's the developers who know and understands the code the best, so they are the most qualified to lock down the code.

Most qualified, certainly. But if all application developers were responsible, we wouldn't need security mechanisms in the first place. I may be misunderstanding how pledge works, but it seems to be actually a very poor security mechanism, since you could just write software which... doesn't pledge to only use certain capabilities. It seems like a great bug prevention mechanism, but not so much for security.

SELinux assumes that the operating system is the trusted downstream of less trustworthy software. By design this implies that someone downstream has to (re-)define all acceptable behaviour of the packaged blackbox causing lots of duplicated work and a fragile interface broken by upstream changes.

Pledge assumes that developers or maintainers will add pledge() and unveil() calls to the code. The software is no longer a blackbox, but given the tools to communicate intend to the kernel (e.g. i won't fork, exec, or create new sockets and will only access files in my /var/db/$name and /var/run/$name directories).. It doesn't change the intended usage of the existing APIs, but to get be able to use the tightest sandbox permissions you have to acquire capabilities as early as possible. This allows retrofitting useful pledge()/unveil() calls to existing code, get quick feedback and restructure the code over time.

An other interesting design to compare pledge()/unveil() against is FreeBSD's Capsicum. It's a fine grained capability mode (e.g. disable/keep specific ioctl() on a file descriptor) and can be used by normal FreeBSD processes as such, but the real sandbox mode is used by acquiring all file descriptors, restricting what is allowed on them, and entering the restrictive capability mode. Once inside capability mode there is no way back and you're only allowed to use existing capabilities to derive equal or weaker capabilities e.g. openat() relative to an open directory file descriptor instead of open() with an absolute path. It puts the burden purely on the developer. It's a very clean design, but correct to a fault. It's not harder to write new software to work inside it, but it's very hard to port software that wasn't written with it in mind to work at all, because it's all or nothing. As a consequence few software is written to take advantage of it.

OpenBSD's pledge()/unveil() is a pragmatic defense in depth tool. It works together with privilege separation and chroot. A good example is that new child processes intentionally are unrestricted and trusted/expected to apply their own restrictions whereas Capsicum mode is inherited to child processes.

Pledge() and unveil() are useful because they can provide additional safety and security at low cost, but they are less expressive. Porting it to Linux has the additional problem that Linux considers system calls to be the stable interface to the kernel instead of libc. The different versions of different libc implementations use different system calls on different architectures (e.g. sbrk() vs mmap()). To make matters worse some of them even depend of compile time flags (e.g. stat() vs stat64()). Each libc would have to implement its own pledge()/unveil() on top of a more flexible (aka complex and error prone) kernel interface.

> One of the things I feel OpenBSD has gotten right with pledge and unveil is the placement of responsibility. It's the developers who know and understands the code the best, so they are the most qualified to lock down the code.

You mean those developers who put in the telemetry code (or back-door or security vulnerability) in to begin with?

What do the application developers know about the user's organization's security policy?

So what about using libraries that don't use pledge?

As I understand, pledge()/unveil() are not declarative, and therefore difficult to review for users.

That is quoting an article from 2002, 21 years ago.

https://everything2.com/title/BSD+is+dying

(I've been using OpenBSD as my primary OS since 2000 so I guess I'm one of the 7000 OGs.)

If you click that link, you’ll see it’s a reference to an ancient and prolific Slashdot troll post (“Netcraft confirms it—BSD is dying…”).

>Theo states that there are only 7000 users of OpenBSD.

Just one metric. /r/openbsd has 17k subscribers. Not sure with DaemonForums.

Depends on what you mean by "in the wild". AFAIK it's not packaged by any major distro, but it has a user base.

The issue is one of attack surface. A program written in a memory safe language is extremely hard to exploit, especially remotely. But if you're talking about an attacker with local execution (who has already taken over a program) the attack surface is much larger.