[JCattheATM]

No, not really. Linux has better options available and is significantly stronger when configured correctly. The OpenBSD approach ls largely based around eliminating bugs in the first place, but isn't as strong at limiting an attacker that successfully exploited a bug they missed or weren't responsible for.

[binkHN]

> when configured correctly.

These are the operative words. With OpenBSD, you get this out of the box and everything just works. With other operating systems, you have to do a lot of the legwork that's already been done for you with OpenBSD and make sure you didn't break things with your configuration.

[JCattheATM]

> These are the operative words.

These are words that when applied equally to Linux and OpenBSD, has Linux coming out ahead.

> With OpenBSD, you get this out of the box and everything just works.

With OpenBSD, out of the box you get a blank slate that really can't do anything, that you have to configure to do what you want, and currently can't be configured to be as secure as linux can be.

[tete]

Sorry but that's simply not true. There are various cases where vulnerabilities didn't affect OpenBSD due to defense in-depth in OpenBSD.

OpenBSD has a pretty long history of eg. limiting attacks through compile time mitigations while making them more usable for every day use compared to specialized "high security" Linux distributions. This can also be seen in patches of third party software (in the ports (packages) system) that often have patches so the code can live with these limitations.

One example of such a mitigation is W^X. Implemented in OpenBSD in 2003, copied later by Windows, Linux and the other BSDs (incl. macOS).

https://en.wikipedia.org/wiki/W%5EX

More recently of course pledge and unveil were also added.

Also in 2003 OpenBSD was also the first mainstream (no research or test OS) that implemented strong ASLR that in 2005 was supported in Linux through third party patch sets.

For a list, see here:

https://www.openbsd.org/innovations.html

Many things were later picked up by Linux distributions, kernel patchsets, compilers, etc.

[JCattheATM]

It really is true. OpenBSD focuses on auditing. In many cases they were not affected because of mitigations, but because they were just using a different stack. OpenBSD wasn't affected by regreSSHion for example, for basically the same reason Alpine wasn't.

OpenBSD didn't invent the concept behind W^X, and if you want to talk of 'copying', which I think is kind of silly personally, then PAX was first.

I'm familiar with the list of OpenBSD innovations, and in turn I would point you to https://https://isopenbsdsecu.re/ for a breakdown of their claims and marketing.

To this date OpenBSD doesn't have anything as simple as a proper ACL, let alone any type of MAC. They claim such systems are too complex, which is of course nonsense.

It's like I said - they focus a lot on preventing an attacker gaining access, but have little available to constrain attackers who DO get access.

[binkHN]

> OpenBSD focuses on auditing.

This is partially true; there are numerous other things that are done for mitigation outside of this.

[JCattheATM]

> there are numerous other things that are done for mitigation outside of this.

Sure, and I think they are mostly great, main problem being they just don't go far enough. Where's the namespace level isolation, ACL or MAC support? Is there a way to give a user append only ability for one file, while having write but not delete access to another, and delete to yet another? What's the maximum extent to which OpenBSD could have limited an attacker, had they been vulnerable to regreSSHion?

[anthk]

Namespaces are a joke under Linux compared ot 9front. The last exploits under bubblewrap ran the same. OpenBSD has OpenSSH pledge'd and unveil'ed.

[JCattheATM]

Don't make the perfect be the enemy of the good. Just because they didn't stop escape via dirtyfrag doesn't make them useless let alone a joke. pledge and unveil are nice, but exactly how effective do you expect them to be against an ssh/sftp server? Maybe you have ssh configured so it can't manipulate user and/or system files, but that isn't typically common usage.