It just takes time.
doas sysctl hw.smt=1(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.)
I've followed this discussion here and there over the years and it always goes like this:
1) everyone makes fun of the mitigations
2) many even outright assert they can easily defeat and exploit OpenBSD
3) nobody provides a working PoC when asked to demonstrate how insecure the OS is
And somewhere in the mix there's also you and your usual blabber, also without any substantial examples of how insecure and exploitable the OS is. Always.
So I'm looking forward to your careful explanation of how insecure the whole thing is and how easily it can be dismantled. Because I really want and need to know. Let's talk.
But I couldn't find if they have a strict "no binary blob allowed" policy like OpenBSD.
- [0] https://doc.qubes-os.org/en/r4.3/user/troubleshooting/pci-tr...
The dom0 is based on Fedora and has the Fedora's policy for firmware blobs. See also: https://doc.qubes-os.org/en/latest/introduction/faq.html#wil...
If I had to pick a BSD, it would be FreeBSD anyway.
I know you've been an advocate for OSes and languages that are outside of the mainstream.
I finally got around to living in plan9...
My experiment, a social network for plan9 written in rc and some awk.
The video is kind of interesting.
I would be in favour to say that out of the box OpenBSD is more secure than Linux.
The homepage of https://www.openbsd.org proudly states "Only two remote holes in the default install, in a heck of a long time!" if they didn't have the evidence to support the statement, the internet would have forced them to remove it by now. ;-)
Remote (exploitable) holes are the ones we all care about.
So even if Debian and OpenBSD ship the exact same web server, but Debian has it defaulted installed and on, but OpenBSD does not, then a remote exploit won't count against OpenBSD.
Less attack surface always equals less potential for bugs/flaws/exploits regardless of how good red teaming tools and workflows get.
Now obviously for other use cases Linux could be a much better option.
How many Linux services use seccomp? Or chroot, mount namespaces, or landlock? If they do at all, it's usually imposed externally by systemd or docker, in which case they usually run with overly broad permissions because there's no integration with the specific application code, thus the AF_ALG exploits in containers. On OpenBSD services continue to narrow their privileges after starting up so by the time an external request is serviced they have only minimal access to syscalls and the filesystem, often only read/write/send/recv syscalls, and if open is allowed only the specific files and directories needed to service requests. Typically even the network-facing daemon accepting TLS connections doesn't have access to the private key--you simply can't do that by running a vanilla service application in docker.
Does OpenBSD have bugs? Of course. The question is, which environment has more trustworthy backstops? The Linux kernel provides all the facilities, but they're not used effectively, for many reasons.
Also important to remember that diversity builds strength. Just as in biology, if all organisms are the same, they all succumb to the same virus.
I have a multi-layered firewall approach where some are Linux, some are OpenBSD, some are commercial. They'll all have bugs, but unlikely they all have the same bug.
Compare the number of CVE vulnerability trends over time between Linux: https://www.cvedetails.com/vendor/33 and OpenBSD: https://www.cvedetails.com/vendor/97
It's not even close! It's nearly two orders of magnitude higher for Linux. This isn't anecdotal or “vague opinion” CVEs are facts.
You can ask the follow-up question: Why is that?
And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced ... But you need to dig deeper to understand why OpenBSD is so much more secure, the core team of OpenBSD proactively reviews the security of other OSes and when they learn something, they rapidly implement the feature/fix in OpenBSD.
Again, read: https://en.wikipedia.org/wiki/OpenBSD_security_features Many of the proactive security features OpenBSD has are not implemented by other OSes. And in the case of kernel-level Crypto, they won't ever be because US export restrictions.
You really brushed that one off, uh? The ratio of linux devices to openbsd is quite literally a million to one. The ratio of tech companies invested in linux to companies invested in openbsd is roughly 50,000 to 1. The ratio of professional security researchers paid to find flaws in Linux vs OpenBSD is harder to quantify at the moment, but I think we can guess a trend here.
I can agree to a degree that OpenBSD takes security more seriously, and they have made very interesting design decisions to enforce their security model. But I entirely disagree that the number of "CVEs are facts" to back your opinion that it is superior.
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.
No they aren't, they're data. Your source shows the amount of Linux CVEs in 2024 are an order of magnitude higher than the amount of Linux CVEs in 2023. Does that mean Linux became way more insecure in 2024? You imply it does, but that's obviously not true. What happened is that Linux changed how they report CVEs [0].
Just like your source doesn't say anything useful about the difference in CVEs in Linux, it doesn't say anything about the difference in CVEs between Linux and OpenBSD.
Lies, damn lies and statistics.
[0] https://www.suse.com/c/linux-kernel-cve-increase-suse-explai...
The OP stated they couldn’t find any data to compare the relative security of Linux vs. OpenBSD.
CVEs are independently, objectively verifiable and provable data. This is the dictionary definition of a verified “fact”. It’s not anyone’s opinion. You don’t have to like it or me.
Love you all.
https://www.cvedetails.com/version-list/49/70318/1/Apple-Mac...
With due mention to FreeBSD's jails, BSD's security image developed mostly from OpenBSD which is said to have gained its security focus due to NetBSD being so insecure that the NetBSD folks were able to hack into DeRaadt's forked OpenBSD.
Android's Bionic was based on or heavily influenced by OpenBSD's libc iirc, though.
Their claim to fame ("only two remote holes in the default install in X number of years") is definitionally only valid for the default install in its default configuration which means: no httpd, no smtpd, no unbound, etc. etc. etc.
The default install isn't very useful, because it doesn't do a lot, and so "only two remote holes" or whatever isn't really saying much.
For example: there are still CVEs popping up: https://nvd.nist.gov/vuln/detail/CVE-2024-11148
Linux has more CVEs because it's orders of magnitude more popular. OpenBSD has appalling performance, and more or less nobody uses it, so there just isn't a large focus on auditing and fixing it.
It's a great research project, but I would not run it on my personal devices. Not because it's "insecure" but because the putative security benefits do not merit the shockingly poor performance.
For personal devices I'm not sure why anyone would run a BSD in the first place
My understanding is that Netflix used to use FreeBSD to serve video, but I read somewhere they're no longer using it. Not sure how true that is.
Some game consoles like the Playstation run a modified FreeBSD as their OS.
Thats not really true. Comes with spamd, pf, httpd, OpenSMTPD and others. Its actually one of the open source unix-like systems that packs more functionality out of the box.
Great firewall and VPN server. You can setup wireguard with just ifconfig.
The default install is actually very useful, and includes a lot, like parent said. Having run OpenBSD in the past, I found the their versions of things were often superior, at least for small setups (and some of them for large installs as well.. probably : )
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.
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.
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.
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.
This is partially true; 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?
Sent patches for two just in "find".
Openbsd, like all other projects, needs a large scale LLM powered bug squash effort.
My recent experience: https://blog.habets.se/2026/05/Everything-in-C-is-undefined-...
Anthropic did that for OpenBSD.
I'm saying you don't even need Mythos to find bugs in OpenBSD. GPT 5.5 is SO much better than humans at finding these things.
The fact that we don't even need Mythos, or $20k (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD shatters the dream that there exists any human who can write C properly with enough expertise, dedication, and time.
Bugs, or exploitable security vulnerabilities?
If the latter, have you reported them all?
As I said in the out of bounds null termination write patch, I don't believe it's exploitable. I would have gotten a CVE, website, and logo then (kidding!). But it was UB. And one-byte overflows have in the past been exploitable by better sploit authors than me.
In any case, I reported that since I felt it was clear that OpenBSD folks would obviously care about it, exploitable or not.
Confirming these findings take time, even though I found GPT to almost always be correct. I will NOT report upstream until I understand the bug. I ain't no slop reporter. As I said in the post OpenBSD (and all other code bases) need a larger effort. The Mythos/Glasswing effort focusing on actually exploitable ones may be a good method for getting them fixed, without overwhelming projects with patches, even when the patches are correct.
I did confirm at least one more UB, and did consider whether to report that OpenBSD `find` reads `status` via `WIFEXITED(status)` without checking `waitpid()` for errors. This is UB since `status` is uninitialized. (https://github.com/openbsd/src/blob/ae684bfaed6cae797cd90e27...)
The reason is my previous experience with OpenBSD where the reply may be "<some standard> is wrong in this regard", and because they control their whole system, they don't care. E.g. in this case they may go "we build with GCC x.y.z exactly, and we know what actually happens in this controlled domain". This may be a bit unfair to them, but not by much.
GPT also flagged the extremely surprising behavior of running `cat -n file1 file2` if file1 doesn't end with a newline. And that `find /etc/passwd -execdir[…]` doesn't run the command. But maybe that's how they want it? I don't want to go through the whole thing for them to go "yeah we won't do that" again. So I think this project is for them. GPT is as available to them as it is to me.
Tangent: in running GPT against `cat` I learned that not only is `cat -n` not standardized, but it also behaves COMPLETELY differently than on Linux, if you provide more than one file.
The way forward is seL4[0][1].
e.g. Genode's Sculpt[0] already bridges the gap via running Linux in a VM.
Even though they already have native webbrowser and can build software natively, it wasn't always the case.
Long time ago I maintained a couple of obsd servers, and the cost in time of upgrades and the (occasional) security fixes was substantial.
I still maintain a couple of servers, but if it wasn't because Debian makes it easier by automating most of it, I don't think I could do it.
Yet I miss my time with obsd. I'm very interested in your experience.
Edit: it was 3.6-STABLE. Things have changed since then.
You can update from one OS version to the next with manly only one command.
https://x.com/ortegaalfredo/status/2055362910415671459
When your super secure feature gets defeated by a symlink maybe it's not really time to consider it...
Sure, things are not better in the linux world but at least there's more eyes to fix issues there just because of the market share.
Running security-critical code as root is still a bad idea.
For my next trick I will demonstrate how to break into my own house to open the blinds by using my keys.
Security researcher theatrics will never not be funny.
Can you help figure out where does it say unveil does not really work when root is involved?
Here's what I can figure out: you need root to set up the environment just so. It's a don't-care. The end.
I guess you just don't understand what unveil does.
Please be sure to let us know when your better, more secure replacement is ready.
Though it's not clear to me now:
- why was this patched then?
- is the point about root that non-root wouldn't have access to passwd anyway?
If you're root inside the sandbox, you're root outside it. This exploit requires you to already be root.
So, yes, you need to have root on the box to set up this exploit.
You are root inside a sandbox. As root-in-the-sandbox, you create a symlink and this gives you the ability to escape the sandbox.
(Whether this is interesting or not depends on whether anyone actually tries to use the sandbox facility in such a way as to give root-in-the-sandbox privileges to untrusted people or code. I don't know enough about OpenBSD to answer that.)
I hear this excuse daily from developers who insist on running all their docker containers as root "because we have to".
If you're relying on a sandbox as your first line of defense you've already lost the war.
The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.
Ideally, sandboxes should be like Vegas - what happens in the sandbox stays in the sandbox.
(I'm just speaking hypothetically here, I'm not knowledgeable about OpenBSD or it's sandboxes)