7 ms·

Porting OpenBSD Pledge() to Linux (2022)

194 points by untilted 3y ago

greyface- 3y ago
128 comments, July 2022 https://news.ycombinator.com/item?id=32096801 https://news.ycombinator.com/item?id=32096801
keyle 3y ago
Seeing this was 2022, is this actually used in the wild?
- imiric 3y ago
  Depends on what you mean by "in the wild". AFAIK it's not packaged by any major distro, but it has a user base.
  - _joel 3y ago
    There's been a more recent discussion and indeed, a fair few people are using it in the wild as they don't need to deal with SECCOMP or whatever.
    - crest 3y ago
      Are seccomp and/or ebpf flexible and accesible enough implement pledge and unveil as a wrapper usable to unprivileged processes (even if it requires the help of a privileged helper daemon)?
      - _joel 3y ago
        Possibly useful info: https://news.ycombinator.com/item?id=38002064 https://news.ycombinator.com/item?id=38002064
deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
YPPH 3y ago
>Theo states that there are only 7000 users of OpenBSD. While he's certainly in a position to give this estimate, I'm curious to know the factual basis of this opinion. That's a shockingly low statistic.
- sivers 3y ago
  That is quoting an article from 2002, 21 years ago. https://everything2.com/title/BSD+is+dying 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.)
  - YPPH 3y ago
    Yikes, that's embarrassing for me. Thanks. I had checked the link but I didn't notice the post was 2002 as opposed to 2022.
- bentley 3y ago
  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…”).
- thewanderer1983 3y ago
  >Theo states that there are only 7000 users of OpenBSD. Just one metric. /r/openbsd has 17k subscribers. Not sure with DaemonForums.
  - arp242 3y ago
    OpenBSD has long since been the most active section on DaemonForums, but it's pretty skewed since there's https://forums.freebsd.org https://forums.freebsd.org – before that opened FreeBSD was much more active, but that's been a long time.
deleted 3y ago
[deleted]
mrweasel 3y ago
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. AppArmor and SELinux is perhaps better suited for "easy" retrofitting and the rules are frequently shipped by the developers, but both are much harder to use and somewhat error-prone. I've seen more clients simply turning of SELinux or AppArmor than I have clients dedicating time to develop proper configurations. Pledge and unveil just works, no mucking around in obscure configuration language or wondering if the error is in your configuration, AppArmor/SELinux or the code.
- crest 3y ago
  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.
_joel 3y ago
For all those wondering about user/usage of this, it was discussed a little =https://news.ycombinator.com/item?id=38000824 https://news.ycombinator.com/item?id=38000824
proxysna 3y ago
There is also a Pledge Nomad driver. https://github.com/shoenig/nomad-pledge-driver https://github.com/shoenig/nomad-pledge-driver
starcraft2wol 3y ago
System level security seems to be the real solution to memory safety. Declaring invariants for an entire program gives you much more peace of mind than hoping there are no bugs in JVM. Process separation is already a success story that eliminates who classes of exploits.
- insanitybit 3y ago
  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.

194 points by untilted 3y ago

greyface- 3y ago

128 comments, July 2022 https://news.ycombinator.com/item?id=32096801 https://news.ycombinator.com/item?id=32096801

keyle 3y ago

Seeing this was 2022, is this actually used in the wild?

imiric 3y ago
Depends on what you mean by "in the wild". AFAIK it's not packaged by any major distro, but it has a user base.
- _joel 3y ago
  There's been a more recent discussion and indeed, a fair few people are using it in the wild as they don't need to deal with SECCOMP or whatever.
  - crest 3y ago
    Are seccomp and/or ebpf flexible and accesible enough implement pledge and unveil as a wrapper usable to unprivileged processes (even if it requires the help of a privileged helper daemon)?
    - _joel 3y ago
      Possibly useful info: https://news.ycombinator.com/item?id=38002064 https://news.ycombinator.com/item?id=38002064

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

YPPH 3y ago

>Theo states that there are only 7000 users of OpenBSD. While he's certainly in a position to give this estimate, I'm curious to know the factual basis of this opinion. That's a shockingly low statistic.

sivers 3y ago
That is quoting an article from 2002, 21 years ago. https://everything2.com/title/BSD+is+dying 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.)
- YPPH 3y ago
  Yikes, that's embarrassing for me. Thanks. I had checked the link but I didn't notice the post was 2002 as opposed to 2022.
bentley 3y ago
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…”).
thewanderer1983 3y ago
>Theo states that there are only 7000 users of OpenBSD. Just one metric. /r/openbsd has 17k subscribers. Not sure with DaemonForums.
- arp242 3y ago
  OpenBSD has long since been the most active section on DaemonForums, but it's pretty skewed since there's https://forums.freebsd.org https://forums.freebsd.org – before that opened FreeBSD was much more active, but that's been a long time.

deleted 3y ago

[deleted]

mrweasel 3y ago

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. AppArmor and SELinux is perhaps better suited for "easy" retrofitting and the rules are frequently shipped by the developers, but both are much harder to use and somewhat error-prone. I've seen more clients simply turning of SELinux or AppArmor than I have clients dedicating time to develop proper configurations. Pledge and unveil just works, no mucking around in obscure configuration language or wondering if the error is in your configuration, AppArmor/SELinux or the code.

crest 3y ago
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.

_joel 3y ago

For all those wondering about user/usage of this, it was discussed a little =https://news.ycombinator.com/item?id=38000824 https://news.ycombinator.com/item?id=38000824

proxysna 3y ago

There is also a Pledge Nomad driver. https://github.com/shoenig/nomad-pledge-driver https://github.com/shoenig/nomad-pledge-driver

starcraft2wol 3y ago

System level security seems to be the real solution to memory safety. Declaring invariants for an entire program gives you much more peace of mind than hoping there are no bugs in JVM. Process separation is already a success story that eliminates who classes of exploits.

insanitybit 3y ago
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.