I'm curious about what works and what doesn't: Many experts don't trust OpenBSD's security implementation (I don't want to raise the issue, just stating fact - many don't). Yet many do trust OpenSSH's security implementation, and OpenSSH is of course an OpenBSD project.
What works in OpenSSH that doesn't work in OpenBSD? Maybe it's as simple as, though under the same umbrella OpenSSH uses a different team, methodology, etc.
That's easy: OpenBSD pioneered OS-wide dragnet code audits, and also an ethos of minimally-invasive, parsimonious OS security features (PID randomization and syscall pinning are two emblematic examples). The rest of the world caught up to OpenBSD on dragnet audits, and then surpassed it; meanwhile, the OpenBSD ethos of minimal, modest security features was probably less effective than the Linux approach of features that bend the whole universe around security challenges or that thread deeply through the operating system.
More than anything else though, it's not so much that OpenBSD is less resilient than Linux (I think a case could be made), and more that OpenBSD isn't materially more secure.
They should have killed the "only N K holes in Z time" tagline a long time ago.
I have written poorly worded criticisms of the OpenBSD project on HN before. They boil down to this: from my observation, it looks like the approach to security in the OpenBSD project is adding more code to solve security issues when it should be the opposite. Code is a liability. You should write as little of it as possible to solve the problem at hand and not spare a single line that isn't needed. In this case the problem is getting a shell on a remote host. Why do you need so many configuration options to solve this single problem?
The OP is a prime example of the opposite happening - it's adding code to prevent repeated authentication failures. Why would this be needed in the first place? If you have configured OpenSSH correctly (that is, using public key authentication instead of password auth, which should not even be an option), then repeated authentication failures should not be a problem. At worst, they take up some CPU time.
Much of the code in OpenBSD and the wider OpenBSD projects also address memory safety issues which would not be issues in the first place if they just used a memory safe language. Yet they push ahead using C in the full knowledge that there are better options available. Java, Go, Python, Rust, I literally don't care, anything would be better than C. Developers should not need to spend hours carefully poring over each others patches to find critical mistakes when it comes to memory. They should not need to spend hours reading C development guidelines or rely on mailing list oracles. By eliminating memory errors as a class, mental capacity is freed up to identify logic errors.
I can't speak for OpenBSD specifically but I can speak to some of my thoughts in why an operating system continues to use C. Supporting a language ecosystem is not easy, the less "default" languages needed to bootstrap the core system the better. The nice part about C is that it's one of the few languages suited for both kernel space and user space. Out of the alternatives you listed the only language that could even seriously be considered for kernel space is rust, and even that took a lot of back and forth to get it to that point in the Linux kernel. Higher level languages have a larger range as assumptions and you have to tow those accomodations in to kernel space if you want to use them. There is also the issue of the memory management in kernel space being much more of a complicated environment than user space. How do I teach the borrow checker about my MMU bring up and maintenance?
I am also skeptical to your claim about removing memory bugs freeing up brain space for logic bugs, at least for Rust. Rust has grown quite a number of language features, that in my experience, result in a higher cognitive load compared to C. If you seriously reduce your reliance on the C macro system (as Plan
9 has shown possible), the language itself is quite simple.
In very simple terms, their approach to security is auditing to try and remove all bugs, but offering very little to protect against the case where there is a remote root hole, such as they have had in the past.
Things have gotten better in recent years with things like pledge and doas, but they are quite lacking compared to proper MAC or sandbox implementations. Worse, many of the OpenBSD devs don't seem to know much about those technologies and are kind of dismissive. I remember an OBSD user or enthusiast trying to argue Pledge was equivalent to SELinux which was pretty bad.
I'd take a slimmed down hardened Linux install over OpenBSD any day of the week.
> In very simple terms, their approach to security is auditing to try and remove all bugs, but offering very little to protect against the case where there is a remote root hole, such as they have had in the past.
I'm not sure what is meant by "protect against the case where there is a remote root hole". Do you mean, to mitigate harm from existing holes? They secure things from top to bottom, but maybe you mean some kind of authorization issues? To proactively prevent holes? They do a lot of engineering around the latter (and around other attacks) - to the extent that many question the wisdom of solving 'problems' for which there is no proven exploit. And they have had very few remote holes - whatever the reason, there's not evidence that they fail to prevent them.
> I'm not sure what is meant by "protect against the case where there is a remote root hole".
I don't understand how this is ambiguous. I mean limit the damage that an attacker can do if they get root - this is something RHEL can do and OBSD pretty much refuses to.
> They secure things from top to bottom
Eh. Kind of. The devs are against security technologies that they think add too much complexity to their system regardless of benefits. That's why they don't have any kind of RBAC or MAC, just plain old DAC. You get root, you get everything - pledge and unveil won't help too much there.
It wasn't an attack, but a genuine question, for which I provided two possible interpretations. I was (am) interested in what you were saying.
> That's why they don't have any kind of RBAC or MAC, just plain old DAC. You get root, you get everything - pledge and unveil won't help too much there.
> It wasn't an attack, but a genuine question, for which I provided two possible interpretations. I was (am) interested in what you were saying.
No worries at all! I wasn't taking it as an attack and apologies if my response seemed combative. I just honestly didn't understand where the point of confusion was.
> Thanks for explaining.
My pleasure! If you're still interested in discussing, I am interested in the point you made that 'They secure things from top to bottom' - if I may ask, why do you think this is the case? It's not a statement I would ever make myself.
I don't think OpenSSH's affiliation with OpenBSD really means anything; it's an accident of history that the people most likely to want to build something like OpenBSD happened to have been involved with OpenBSD at the time. Just my take.
> Many experts don't trust OpenBSD's security implementation...
Does this distrust go to the extent where confronted with a public Internet-facing, stock OpenBSD with a TLS-secured SSH connection, and a GSA hardened RHEL 8 [1] with a similar SSH configuration, they’ll pick the RHEL instance?
Many experts will pick RHEL over OpenBSD yes. It's impossible to isolate a single reason; generally you want a server to do something. (I guess if you're talking about SSH only then maybe you want it as a bastion host? In my experience people will generally use the same OS as their other servers though; the risk of misconfiguring an unfamiliar operating system outweighs any security improvement from picking one or the other)
What works in OpenSSH that doesn't work in OpenBSD? Maybe it's as simple as, though under the same umbrella OpenSSH uses a different team, methodology, etc.