4 ms·

> If they run into OpenBSD, however, their efforts are quite likely to be thwarted just because the blowfish is so darn spiky. Ehhhhhhh. As a teen eating up a

> If they run into OpenBSD, however, their efforts are quite likely to be thwarted just because the blowfish is so darn spiky. Ehhhhhhh. As a teen eating up all the computer security stuff I could find, and getting into osdev and learning as much as I could, OpenBSD always seemed kind of off to me. The security claims are hugely overstated, and for an OS that claims security as its focus, they are slow if not reluctant to add tools that vastly increase security, like even a simple RBAC implementation. Disabling services by default should have been the default for all operating systems, and writing OpenSSH has been great, but let's all stop perpetuating the myth of OpenBSD as an especially hardened OS. I agree about the BSDs being a secret weapon, but that's more to do with the license as someone else mentioned, and I'd think Net and Free are more commonly taken from.

davidgerard 2y ago
The thing that seems to be missing from your post is a list of examples of its security not being all that in practice.
- DEADMINCE 2y ago
  I wouldn't say it's missing. I deliberately generalized. I mentioned RBAC as an example. If people want to learn more there is no shortage of info. There was even a talk[0] at the 36th CCC. [0] - https://www.youtube.com/watch?v=3E9ga-CylWQ https://www.youtube.com/watch?v=3E9ga-CylWQ
crest 2y ago
OpenBSD was stagnant when it came to hardening for a while, but the last few releases really added new defense in depth technologies e.g. whitelisting all syscall entry points at link time -> if your process doesn't contain fork() and execve() they're is unavailable even after you exploited a RCE. If the process is already restricted by pledge() and unveil() it can't just regain the disabled system calls. These technologies are not a fine grained and "theoretical sound" like a pure capability like FreeBSD's Capsicum, but they're a whole lot easier to retrofit to existing non-trivial applications which means more code is covered by good enough mitigations to drive the attack costs up significantly and make certain (classes of) bugs unexploitable.
- DEADMINCE 2y ago
  The thing is I find stuff like pledge adn unveil to be basically toys. Pledge especially since it relies on the software author utilizing it. We've had stuff like RBAC and MAC implementations for 20 years, and RBAC doesn't have to be complicated, look at AppArmor. If the OpenBSD guys really cared about security, they would be working on something like that. Look at their remote root ssh bug. If they were a secure OS, someone getting remote root wouldn't be such a big issue, with RBAC/MAC it's clearly not such an issue, with the default 'secure' install, it sure was. Then again, I don't think the obsd devs have a real interest in security, so much as an interest in correcting bugs, which they falsely equate to be the same thing. Pretty sure one dev had no idea what MAC/RBAC even is and was trying to claim pledge is the exact same thing, which only lessens any confidence I had in them.
  - gnubison 2y ago
    The remote ssh bug? It was caused by some Linux distributions patching sshd to link to libsystemd which required liblzma which had the backdoor. It didn’t affect OpenBSD or involve upstream OpenSSH.
    - DEADMINCE 2y ago
      I mean the remote ssh bug from 2002 that caused OpenBSD to alter their tagline to "One remote hole in the default install, in nearly 6 years!". Pretty sure that affected OpenBSD.

davidgerard 2y ago

The thing that seems to be missing from your post is a list of examples of its security not being all that in practice.

DEADMINCE 2y ago
I wouldn't say it's missing. I deliberately generalized. I mentioned RBAC as an example. If people want to learn more there is no shortage of info. There was even a talk[0] at the 36th CCC. [0] - https://www.youtube.com/watch?v=3E9ga-CylWQ https://www.youtube.com/watch?v=3E9ga-CylWQ

crest 2y ago

OpenBSD was stagnant when it came to hardening for a while, but the last few releases really added new defense in depth technologies e.g. whitelisting all syscall entry points at link time -> if your process doesn't contain fork() and execve() they're is unavailable even after you exploited a RCE. If the process is already restricted by pledge() and unveil() it can't just regain the disabled system calls. These technologies are not a fine grained and "theoretical sound" like a pure capability like FreeBSD's Capsicum, but they're a whole lot easier to retrofit to existing non-trivial applications which means more code is covered by good enough mitigations to drive the attack costs up significantly and make certain (classes of) bugs unexploitable.

DEADMINCE 2y ago
The thing is I find stuff like pledge adn unveil to be basically toys. Pledge especially since it relies on the software author utilizing it. We've had stuff like RBAC and MAC implementations for 20 years, and RBAC doesn't have to be complicated, look at AppArmor. If the OpenBSD guys really cared about security, they would be working on something like that. Look at their remote root ssh bug. If they were a secure OS, someone getting remote root wouldn't be such a big issue, with RBAC/MAC it's clearly not such an issue, with the default 'secure' install, it sure was. Then again, I don't think the obsd devs have a real interest in security, so much as an interest in correcting bugs, which they falsely equate to be the same thing. Pretty sure one dev had no idea what MAC/RBAC even is and was trying to claim pledge is the exact same thing, which only lessens any confidence I had in them.
- gnubison 2y ago
  The remote ssh bug? It was caused by some Linux distributions patching sshd to link to libsystemd which required liblzma which had the backdoor. It didn’t affect OpenBSD or involve upstream OpenSSH.
  - DEADMINCE 2y ago
    I mean the remote ssh bug from 2002 that caused OpenBSD to alter their tagline to "One remote hole in the default install, in nearly 6 years!". Pretty sure that affected OpenBSD.