8 ms·

Privilege drop, separation, and restricted-service operating mode in OpenBSD

74 points by brynet 4y ago

g0xA52A2A 4y ago
Changed "privilege separation" -> "separation" to fit within character limits.
- brynet 4y ago
  Indeed. :-)
  - g0xA52A2A 4y ago
    LOL I thought it was my submission, totally missed the redirect.
Zurrrrr 4y ago
Security is more than just auditing code to remove bugs - it's also being prepared for worst case scenarios for bugs that inevitably exist but have not yet been found. For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient. Something like SELinux, RSBAC, Even AppArmor is sorely needed.
- yazzku 4y ago
  Aren't pledge/unveil precisely preparing for unknown bugs? Also they seem to be much easier to use than doing AppArmor chops.
- _0w8t 4y ago
  Linux approach delegates security to the system administrator. Hence Linux provides containers, SELinux etc. focusing on securing the existing binaries. OpenBSD assumes it is the programmer who is responsible for delivering secure code. Hence it provides the tools that require to modify the sources. One can argue for one or another approach, but both at the end deliver similar reduction of the attack surface.
  - Zurrrrr 4y ago
    I think that is a flawed way of looking at it. Stuff like SELinux assumes the system administrator or software can't be trusted, and provides ways to protect against future attacks while enforcing only the minimal access needed. It isn't letting programmers off the hook, and isn't an alternate approach. Unless you can be absolutely certain of the code you are running, which no one really can, then it's the better approach.
- traceroute66 4y ago
  > Something like SELinux, RSBAC, Even AppArmor The problem with AppArmor and friends is that they are hell on earth to configure and manage. And I'm saying that as a security conscious sysadmin ! I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Of course I leave AppArmor enabled to some degree, and I'm happy if a package comes with AppArmor rules ... but I ain't gonna be sacrificing days of my life writing, tweaking, troubleshooting my own rules. That's why I feel OpenBSD's answer is likely a good compromise. It adds a demonstrable level of security, and it doesn't stress out the sysadmin.
  - binkHN 4y ago
    > The problem with AppArmor and friends is that they are hell on earth to configure and manage. > I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.
  - Zurrrrr 4y ago
    Rules might be a pain, but no more so than writing good firewall rules, and once done don't have to be done again. It's not the issue some make it out to be
    - commandersaki 4y ago
      > and once done don't have to be done again Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed. pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
      - 4y ago
- daneel_w 4y ago
  > "For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient." Does that mean that OpenBSD's mitigations are trivial to exploit? "Terrible" and "simply not sufficient" are strong words. If so, can you provide a working proof-of-concept? I keep asking this of people who make this statement because I'm genuinely interested in seeing it demonstrated as it has negative implications for me, but no one wants to spend time proving their point.
  - beachhead 4y ago
    It'll never happen. Every single time this comes up it turns into the same thing over and over again. You must remember the person that said they'd "write a blogpost bypassing OpenBSD mitigations next week" and that's been well over a month now and, surprise, there's no blog about this. Everything OpenBSD does is wrong and trivial to bypass but everyone's too busy to do it. Maybe the dumbest part about this is that nobody on the other side of this is making claims that these mitigations are perfect in any way. Qualys has bypassed some OpenBSD malloc hardening features recently but then they don't go around making wild or insulting claims about how wrong and trivial they are either. Go figure.
    - g0xA52A2A 4y ago
      Just replying to provide some context [1] for those who come across this comment as I think it's pretty interesting. Also OpenBSD are working on something for this [2]. [1] https://seclists.org/oss-sec/2023/q1/92 https://seclists.org/oss-sec/2023/q1/92 [2] https://marc.info/?l=openbsd-tech&m=167673316325935&w=2 https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
      - beachhead 4y ago
        More from Qualys: https://seclists.org/oss-sec/2023/q1/109 https://seclists.org/oss-sec/2023/q1/109 More from OpenBSD: https://marc.info/?l=openbsd-tech&m=167715187212393&w=2 https://marc.info/?l=openbsd-tech&m=167715187212393&w=2
  - 4y ago
- mrweasel 4y ago
  Pledge and Unveil are better in one, maybe two respects. 1) The restrictions are put in place by the developer, who understand the correct and expected behaviour better than a random systems administrator. 2) Neither Pledge nor Unveil can be disabled by the user. Both SELinux and AppArmor (I don't know RSBAC) can be disabled, and is FREQUENTLY disabled because dealing with either systems are a major hassle to configure. I'm not quite sure how SELinux is better, it's perhaps more granular, but is that better?
- sillywalk 4y ago
  I believe that for the OpenBSD developers, SELinux/apparmor/seccmp are against their philosophy. [0] While they are very powerful tools, they require complex rules maintained outside the actual code, and their complexity may lead you to disable the Security stuff entirely, rather than try to re-write the rules your distro/package came with. OpenBSD had systrace back in the day to restrict system calls, but it suffered from the Time of Check/Time of Use/ problem, and was only used on one (sshd) program in the base system. [0] https://www.openbsd.org/papers/hackfest2015-pledge/ https://www.openbsd.org/papers/hackfest2015-pledge/
rustifico 4y ago
Yet they are still writing everything in C. A well-polished turd is still a turd.
- chungy 4y ago
  Now name the OS that isn't written in C. Hint: It's not Windows. It's not Linux. It's not Mac OS. It's not FreeBSD. It's not illumos...
  - hulitu 4y ago
    MULTICS ? Apollo Domain OS ?
  - josephcsible 4y ago
    Redox?
    - medo-bear 4y ago
      is it your daily driver
  - unused0 4y ago
    IIRC,Primos was written in FORTRAN (with language extensions including the ability to pass a statement number as a parameter, allowing longjmp() like behavior). Multics (as noted above) was written in PL/I.
- mvdwoord 4y ago
  Sour much?
- crest 4y ago
  Where is your shiny rust kernel and userland useable as desktop/laptop or server? Don't pull others down just because you have yet to deliver.
commandersaki 4y ago
> We first get a user with getpwnam(3) to drop to. The user has /var/empty configured as its home directory so we can use that in chroot(2). Next we chdir(2) to the new file-system root to have a valid current working directory. This prevents us accidentally marking a file-system as busy depending on from where the daemon was started, preventing unmounting file-systems while the daemon is running. I think another reason for chdir(2) is to avoid a vulnerability where you can repeatedly chain chdir("..") in the process and then chroot(".") to escape chroot.

74 points by brynet 4y ago

g0xA52A2A 4y ago

Changed "privilege separation" -> "separation" to fit within character limits.

brynet 4y ago
Indeed. :-)
- g0xA52A2A 4y ago
  LOL I thought it was my submission, totally missed the redirect.

Zurrrrr 4y ago

Security is more than just auditing code to remove bugs - it's also being prepared for worst case scenarios for bugs that inevitably exist but have not yet been found. For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient. Something like SELinux, RSBAC, Even AppArmor is sorely needed.

yazzku 4y ago
Aren't pledge/unveil precisely preparing for unknown bugs? Also they seem to be much easier to use than doing AppArmor chops.
_0w8t 4y ago
Linux approach delegates security to the system administrator. Hence Linux provides containers, SELinux etc. focusing on securing the existing binaries. OpenBSD assumes it is the programmer who is responsible for delivering secure code. Hence it provides the tools that require to modify the sources. One can argue for one or another approach, but both at the end deliver similar reduction of the attack surface.
- Zurrrrr 4y ago
  I think that is a flawed way of looking at it. Stuff like SELinux assumes the system administrator or software can't be trusted, and provides ways to protect against future attacks while enforcing only the minimal access needed. It isn't letting programmers off the hook, and isn't an alternate approach. Unless you can be absolutely certain of the code you are running, which no one really can, then it's the better approach.
traceroute66 4y ago
> Something like SELinux, RSBAC, Even AppArmor The problem with AppArmor and friends is that they are hell on earth to configure and manage. And I'm saying that as a security conscious sysadmin ! I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Of course I leave AppArmor enabled to some degree, and I'm happy if a package comes with AppArmor rules ... but I ain't gonna be sacrificing days of my life writing, tweaking, troubleshooting my own rules. That's why I feel OpenBSD's answer is likely a good compromise. It adds a demonstrable level of security, and it doesn't stress out the sysadmin.
- binkHN 4y ago
  > The problem with AppArmor and friends is that they are hell on earth to configure and manage. > I don't mind spending little time to lock-down my systems a bit, but writing new AppArmor rules is about as attractive as bashing my head against the proverbial brick wall. Yep. This is one of the prime motivators as to why OpenBSD did what they did. Often times, when AppArmor and similar solutions prevent a program from working properly, the first reaction is to disable it, and then these protections tend to stay disabled.
- Zurrrrr 4y ago
  Rules might be a pain, but no more so than writing good firewall rules, and once done don't have to be done again. It's not the issue some make it out to be
  - commandersaki 4y ago
    > and once done don't have to be done again Hardly, you'll have to update the rules when the program gets updated to do new things; whereas with pledge(2)/unveil(2) the developer simply applies more restrictions if needed before the program is distributed. pledge(2)/unveil(2) is not only superior because it cannot be disabled, it has better aesthetics than any of that apparmor/selinux garbage.
    - 4y ago
daneel_w 4y ago
> "For a security focused OS, OpenBSD is terrible in this regard. Pledge and Unveil are simply not sufficient." Does that mean that OpenBSD's mitigations are trivial to exploit? "Terrible" and "simply not sufficient" are strong words. If so, can you provide a working proof-of-concept? I keep asking this of people who make this statement because I'm genuinely interested in seeing it demonstrated as it has negative implications for me, but no one wants to spend time proving their point.
- beachhead 4y ago
  It'll never happen. Every single time this comes up it turns into the same thing over and over again. You must remember the person that said they'd "write a blogpost bypassing OpenBSD mitigations next week" and that's been well over a month now and, surprise, there's no blog about this. Everything OpenBSD does is wrong and trivial to bypass but everyone's too busy to do it. Maybe the dumbest part about this is that nobody on the other side of this is making claims that these mitigations are perfect in any way. Qualys has bypassed some OpenBSD malloc hardening features recently but then they don't go around making wild or insulting claims about how wrong and trivial they are either. Go figure.
  - g0xA52A2A 4y ago
    Just replying to provide some context [1] for those who come across this comment as I think it's pretty interesting. Also OpenBSD are working on something for this [2]. [1] https://seclists.org/oss-sec/2023/q1/92 https://seclists.org/oss-sec/2023/q1/92 [2] https://marc.info/?l=openbsd-tech&m=167673316325935&w=2 https://marc.info/?l=openbsd-tech&m=167673316325935&w=2
    - beachhead 4y ago
      More from Qualys: https://seclists.org/oss-sec/2023/q1/109 https://seclists.org/oss-sec/2023/q1/109 More from OpenBSD: https://marc.info/?l=openbsd-tech&m=167715187212393&w=2 https://marc.info/?l=openbsd-tech&m=167715187212393&w=2
- 4y ago
mrweasel 4y ago
Pledge and Unveil are better in one, maybe two respects. 1) The restrictions are put in place by the developer, who understand the correct and expected behaviour better than a random systems administrator. 2) Neither Pledge nor Unveil can be disabled by the user. Both SELinux and AppArmor (I don't know RSBAC) can be disabled, and is FREQUENTLY disabled because dealing with either systems are a major hassle to configure. I'm not quite sure how SELinux is better, it's perhaps more granular, but is that better?
sillywalk 4y ago
I believe that for the OpenBSD developers, SELinux/apparmor/seccmp are against their philosophy. [0] While they are very powerful tools, they require complex rules maintained outside the actual code, and their complexity may lead you to disable the Security stuff entirely, rather than try to re-write the rules your distro/package came with. OpenBSD had systrace back in the day to restrict system calls, but it suffered from the Time of Check/Time of Use/ problem, and was only used on one (sshd) program in the base system. [0] https://www.openbsd.org/papers/hackfest2015-pledge/ https://www.openbsd.org/papers/hackfest2015-pledge/

rustifico 4y ago

Yet they are still writing everything in C. A well-polished turd is still a turd.

chungy 4y ago
Now name the OS that isn't written in C. Hint: It's not Windows. It's not Linux. It's not Mac OS. It's not FreeBSD. It's not illumos...
- hulitu 4y ago
  MULTICS ? Apollo Domain OS ?
- josephcsible 4y ago
  Redox?
  - medo-bear 4y ago
    is it your daily driver
- unused0 4y ago
  IIRC,Primos was written in FORTRAN (with language extensions including the ability to pass a statement number as a parameter, allowing longjmp() like behavior). Multics (as noted above) was written in PL/I.
mvdwoord 4y ago
Sour much?
crest 4y ago
Where is your shiny rust kernel and userland useable as desktop/laptop or server? Don't pull others down just because you have yet to deliver.

commandersaki 4y ago

> We first get a user with getpwnam(3) to drop to. The user has /var/empty configured as its home directory so we can use that in chroot(2). Next we chdir(2) to the new file-system root to have a valid current working directory. This prevents us accidentally marking a file-system as busy depending on from where the daemon was started, preventing unmounting file-systems while the daemon is running. I think another reason for chdir(2) is to avoid a vulnerability where you can repeatedly chain chdir("..") in the process and then chroot(".") to escape chroot.