An analysis site that examines OpenBSD's exploit mitigations one by one and assesses whether they make the system secure.
Commenters call it extremely good and detailed, though some say it is disdainful and note it shows no working exploit against OpenBSD.
a.) They found it off-putting that OpenBSD was "proud" not to have a CoC, in the context of whether they would choose to work with them or to host the website themselves. Consider taking a moment to read the passage in question: https://isopenbsdsecu.re/about/
This idea they were surprised a project succeeded without having a CoC is an artefact of this particular discussion, not something the author ever said or implied. It was in the same category as de Raadt swearing at people over email - they didn't anticipate a productive exchange if they reached out. That's it.
If someone declares they reserve the right to treat people however they please, and then you observe them treating people in a way you don't want to be treated, and your conclusion is, "I don't think emailing this person is a good use of my time, I'm just going to host this website myself" - I find it hard to understand how anyone would find that objectionable, that seems simple, common sense, and largely neutral.
b.) Whenever you have a large group of people collaborating for an extended period of time, you have incidents. There's drama. There's inappropriate behavior. It's just how it goes. It's a Murphy's Law thing.
Eventually people sit down and say, "we've gotta set some ground rules." You probably signed a code of conduct at every school you attended and every job you've accepted. I know I have.
You can disagree with that without viewing it as a conspiracy. It's a predictable result of being in a…
It's not exploitable. It's an exploit mitigation, in fact. It's not a bug; it's intentional that it works this way. And Nathan Michaels didn't think that if you want to find Theo de Raadt writing on some subject, better try OpenBSD discussion fora, not the LLVM mailing list. (-:
This was put into OpenBSD back in 2017. It's not "trap instructions". It's "trapsleds". The idea is to trap the sleds (a.k.a. slides) of NOP instructions that linkers used to put in between compiled code for alignment, and which could be exploited with "return-oriented programming" where an attacker could cause execution to jump to any address in the padding range (possibly needing the inexactitude because of constraints upon byte substitutions) and slide along all of the NOPs to the target function.
* https://undeadly.org/cgi?action=article;sid=20170622065629
* https://isopenbsdsecu.re/mitigations/trapsled/
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.
While much of this document is openly disdainful, there are areas like the malloc implementation[1] and features like the atexit hardening[2] where OpenBSD is unambiguously excellent, and it says as much, noting that the latter is a "pretty cool mitigation".
I used to do some OpenBSD ports work, and even got a tiny patch into the base system. I love OpenBSD! I don't have an axe to grind here! But it is not above reproach, and I think this site is overall harsh but fair.
[1]: https://isopenbsdsecu.re/mitigations/malloc/
[2]: https://isopenbsdsecu.re/mitigations/atexit_hardening/
This page has stuck with me since I read it regarding openbsd. It's a bit mean spirited, but I think openbsd mostly benefits from its own obscurity.
https://isopenbsdsecu.re/
But the nice parts of ChromeOS, as far as security properties go are the way it can be "power washed" between usages. Along with a desktop Linux system that has less binaries installed at it's base than most. And things that are built in are typically built atop chrome's sandbox.
I used to joke with my friends who ran TAILS Linux that my grandma with her Chromebook had the same threat model.
Going by CVEs, Haiku is more secure than OpenBSD. Linux has had strong kernel-level crypto enabled by default on major distributions for years, see AF_ALG or LUKS.
On the wiki page you provided, the only thing that really stands out at the kernel level is KARL, which has a dubious utility: https://isopenbsdsecu.re/mitigations/karl/ It is not even up to date: strlcpy(3) and strlcat(3) were implemented in glibc 3 years ago.