Is OpenBSD Secure?

https://isopenbsdsecu.re/ (This site is extremely good and has fairly recent coverage, point-by-point, of all OpenBSD's mitigations. An important subtext to take to this is that OpenBSD has a reputation for introducing mitigations that exploit developers make fun of. Some of them are great, some of them less so.)

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.

>aslr on steroids, and it does vastly increase kernel attack complexity That's quite the statement, in reality KARL is a mild incovenience at best(for a more sober look on it see https://isopenbsdsecu.re/mitigations/karl/)

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/

> Find a vulnerability researcher to talk to about OpenBSD sometime, though. > https://isopenbsdsecu.re/ Notice that at no point does anyone actually show up with a working exploit.

As far as I know, all of these statements are still true: https://web.archive.org/web/20220227172102/https://madaidans-insecurit… https://isopenbsdsecu.re/

OpenBSD mostly operates on a hobbyist's idea of security, where they just make up attacks to defend against rather than being systematic or actually keeping up with the outside world. (https://isopenbsdsecu.re) Although professional security people are also rather bad at this and like to eg stack multiple cool-looking mitigations even if they break each other. (https://siguza.github.io/PAN/)

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.

OpenBSD security is overstated in my opinion (and the opinion of others[1]), and I have serious doubts it would be worth the work to migrate to unless FreeBSD is absolutely terrible. 1: https://isopenbsdsecu.re/quotes/

there may be reasons you wish to reconsider OpenBSD https://isopenbsdsecu.re/

OpenBSD has historically been eager to add new security mitigations without explaining their intended threat model. Here's an excellent talk (in website form) on the subject: https://isopenbsdsecu.re/about/

https://isopenbsdsecu.re Slide 43 is worrying.

Flipside of the coin... https://isopenbsdsecu.re/

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.

This looks quite concerning: https://isopenbsdsecu.re/mitigations/packages/

They are very positive about some mitigations: https://isopenbsdsecu.re/mitigations/pledge/

Besides the clown nose on puffy it's honestly just realistic and not all just talking bad like I've seen some people do: https://isopenbsdsecu.re/mitigations/pledge/

There's a lot of defense in depth approaches in OpenBSD, and as someone who's been on the mailing list for quite some time, I get to see them in real time. https://isopenbsdsecu.re/mitigations/ does break them down fairly well, perhaps a bit pessimistically, but, if you take time to read through this, you can still see a lot of innovation coming from OpenBSD, and often before others.

I hear this claim about security repeated a lot but not everyone agrees[0]. Always interested in hearing perspectives from actual users though. What do you like about their focus on security? [0] https://isopenbsdsecu.re/about/

Relevant article: https://isopenbsdsecu.re/about/ I don't have a strong opinion about it myself, but the security aspect of OpenBSD is not as obvious as some people make it out to be.

For anybody wondering about the new pinsyscalls(2) suggest having a look at https://isopenbsdsecu.re/mitigations/pinsyscall/ . To be clear: I use OpenBSD on all my external-facing systems. I trust it infinitely more than any GNU/Linux distribution (esp with the recent xz.. "issue"), but I think it's important to do your own research and see what the contrarians say from time to time.

Here are a lot of citations: https://isopenbsdsecu.re/quotes/

I think high quality code equates to better security, even though such code is not by itself a panacea for security. Here's a neat resource for OpenBSD's mitigations, some of which were/are novel, though it may not have been updated recently (2019): https://isopenbsdsecu.re/mitigations/

Technically correct I suppose - https://isopenbsdsecu.re/mitigations/embargoes_handling/ But they do have a relatively difficult history with embargoes. This isn't criticising them BTW - although I don't use OpenBSD any more I still have a soft spot for them and respect for everything they've achieved.

https://isopenbsdsecu.re/mitigations/pinsyscall/ for a contrasting opinion

Nope; OpenBSD boots fine via UEFI, but secure boot must be disabled. Here's a critical piece on the subject: https://isopenbsdsecu.re/mitigations/secure_boot/

Secure, yet refuses to implement hardware root-of-trust standards? https://isopenbsdsecu.re/mitigations/secure_boot/

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/

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…