[nelsonic]

With all the security issues constantly being uncovered in other Operating Systems - which will only accelerate with Ai - it’s time everyone considers OpenBSD. Their decades-long security-focus is second to none. We have fully converted from Ubuntu/Debian to OpenBSD. No looking back.

[infinet]

I tried OpenBSD recently and found it behaves very differently from other OS. The same code works on Linux/FreeBSD/Windows but has poor multi thread performance on OpenBSD, async socket stopped working after sending at high speed for few seconds. I am not saying there is anything wrong in OpenBSD, it is just different.

[skydhash]

OpenBSD uses a Giant Lock model (simpler code) instead of the fine grained locking mechanism in Linux. And Linux has a some quirks and hacks to improve performance (instead of doing the slow, but correct thing). One example is the USB Gadget thing.

[bw86]

This is not wrong per se, but they also try to reduce/remove this giant lock as much as possible. If you see entries like "Unlocked socket splicing." in the changelog, then this is one more case where the giant lock is not needed and in which therefore all cores can be used.

It just takes time.

[nelsonic]

Is the code you ran on your OpenBSD available (e.g. on GitHub) for others to test? Curious what async issue you faced, did you report it? Or ask for help addressing?

[infinet]

I just switched to single thread and didn't try to fix the issue. Single thread is fast enough to me, it has throughput ~ 730 Mbits/s in a OpenBSD 7.8 vm on a 7th gen i7 linux kvm host.

https://github.com/infinet/rs-wgobfs/commit/c5e62796

[anthk]

        doas sysctl hw.smt=1

[fsflover]

If you care about security, why not consider Qubes OS? Related discussion: https://forum.qubes-os.org/t/qubesos-vs-openbsd-security/790...

[FuriouslyAdrift]

If you really really care about security, then consider CHERI and CheriBSD

https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

[fsflover]

Capability approach is just not practical and relies too much on security through correctness, which is unrealistic.

[sunshine-o]

I was looking at that thread and honest question: how does Qubes OS deal with the binary blob issue? I would guess it is deblobbed to a certain extend according to [0]

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...

[fsflover]

They do not have a strict "no binary blob allowed" policy. Concerning VMs, they have a policy of minimal modifications: https://doc.qubes-os.org/en/latest/introduction/faq.html#wha...

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...

[nelsonic]

Qubes OS uses the Linux kernel. Without wanting to start a flame-war and with all respect to Linux, it’s not even close. See: https://en.wikipedia.org/wiki/OpenBSD_security_features

[snazz]

The “kernel” in Qubes is arguably Xen rather than Linux, and that’s where the security boundaries are supposed to be defined rather than within VMs that may be running any OS. VM compartmentalization as a security mechanism is hard to compare to a more conventional Unix like OpenBSD.

[fsflover]

It's not just Xen, it also relies on the hardware-assisted virtualization (VT-d), which is virtually unbreakable compared to anything else. Most Xen vulnerabilities do not even affect Qubes: https://www.qubes-os.org/security/xsa/#statistics

[fsflover]

You misunderstand the Qubes' approach to security. You isolate your workflows into separate VMs, so that security of a single VM doesn't matter. For example, my secrets are stored in a dedicated offline VM. All kernel bugs in it are just not exploitable. I open my online banking in a dedicated VM, in which nothing else is ever opened. Which attack vector do you think can be used against that?

[tptacek]

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.)

[terry_hc]

The slides are over 6 years old. The developers' attitudes haven't changed much, but are all of the arguments still valid?

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.

[tptacek]

The site isn't the slide deck. Let's talk after you've read it?

[terry_hc]

I have now read all of the points in the mitigations section. Just like the slides, the commentaries to the mitigations willingly assert uselessness and imply a sense of absolute insecurity, but without specific or even general examples.

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.

[pjmlp]

Unfortunately the hardware support isn't there for many systems.

If I had to pick a BSD, it would be FreeBSD anyway.

[dharmatech]

Hey pjmlp (waves),

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.

https://github.com/dharmatech/9social

[pjmlp]

Cool! Trying out new ideas is very good way to open mindsets, even if those systems aren't used regularly, they serve as inspiration for future improvements.

The video is kind of interesting.

[dharmatech]

Thanks for checking it out, pjmlp!

[elcritch]

Ugh FreeBSD is so much nicer than modern Linux. It's hard not to love.

[pjmlp]

It has some pluses, I miss an updated version of "The Design and Implementation of the FreeBSD Operating System", but it is understable there are other priorities and putting such a book out is lots of work for very little money, given how much book authoring gives back.

[maxall4]

Is OpenBSD actually more secure than Linux? I have not been able to find any data to support this—only some vague opinions.

[nelsonic]

The Data:

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.

[tredre3]

> And there are many reasons. It could just be that Linux having more users/eyes means more bugs are surfaced

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.

[wartijn_]

> This isn't anecdotal or “vague opinion” CVEs are facts

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...

[nelsonic]

This announcement thread really isn’t the place to discuss or debate the data.

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.

[cccbbbaaa]

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.

[swinglock]

AF_ALG does ring a bell.

[Tepix]

US export restrictions? There are broad license exceptions since decades, so kernels like Linux are free distributable. Same would apply to OpenBSD.

[mghackerlady]

which is canadian anyway

[doublerabbit]

"Is Secure" is subjective.

I would be in favour to say that out of the box OpenBSD is more secure than Linux.

[jjav]

> I would be in favour to say that out of the box OpenBSD is more secure than Linux.

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.

[nelsonic]

You are correct; OpenBSD is secure by default. And it's not subjective at all.

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.

[bombcar]

The key (and not saying it's bad, mind you) is that the default install has very few services installed, let alone running or open.

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.

[wahern]

All OpenBSD services, including HTTP (httpd), SMTP (smtpd), and DNS (nsd, unbound, unwind), use privilege separation and sandbox themselves with pledge and either unveil or chroot. There's no extra configuration. And the developers dog-food these services; it's why they're in the base system.

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.

[Melatonic]

Isn't that a good thing for certain use cases ? If you are building an appliance type thing (say a storage or networking device) then you would want something minimalist you can add only the necessary services on. And arent those the types of devices the BSD (in general) are used for ?

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.

[binkHN]

There was a time when Linux distributions shipped lots of things on by default; OpenBSD bucked the trend and did not. This is less of an issue nowadays.

[backscratches]

People would never lie on the internet.

[tete]

Given from what Anthropic says with Mythos: Yes.

[thomashabets2]

I pointed plain old gpt 5.5 at openbsd and found plenty of bugs.

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-...

[tiffanyh]

> This was the most critical vulnerability we discovered in OpenBSD with Mythos Preview after a thousand runs through our scaffold. Across a thousand runs through our scaffold, the total cost was under $20,000 and found several dozen more findings.

Anthropic did that for OpenBSD.

https://red.anthropic.com/2026/mythos-preview/

[thomashabets2]

I know.

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.

[jjav]

> (I just pay $24/month and this was one of my MANY uses), to find bugs in OpenBSD

Bugs, or exploitable security vulnerabilities?

If the latter, have you reported them all?

[stackghost]

It's not meaningfully more secure than e.g. Debian.

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.

[irusensei]

> 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.

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.

[stackghost]

Again: It comes with them on disk, but are they enabled by default? If not, then they are not covered by their "default install" boast.

[gizzlon]

I get your point, but GP is right: You said "Default install", not enabled by default.

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 : )

[SoftTalker]

I use it on my ~10 year old desktop as my everyday OS. Performance may be measurably worse on benchmarks, but I never notice it doing regular stuff as a user. It's fine.

[Melatonic]

Don't most people use something FreeBSD based for production use ? I was under the impression OpenBSD was more used for testing and security research.

For personal devices I'm not sure why anyone would run a BSD in the first place

[tolciho]

Easy to install and upgrade, sane defaults, good documentation, lack of waffleburgers of complexity, so I'm not sure why anyone wouldn't run OpenBSD in the first place. Granted I put Windows in the unusable bin and it's been there for decades now and sounds like it is getting worse, what passes for Mac OS X these days is not so good given that you have to disable some security thing to properly kill the annoying and disruptive notification system, among other annoyances still being fueded with, and I gave up on Linux after trying to support that waffleburger in production for a year or two.

[stackghost]

OpenBSD is absolutely a research OS and that's okay.

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.

[tptacek]

No. (It's fine!)

[foofyter]

macOS is BSD roots on top of Darwin

[accrual]

While true it doesn't answer why OpenBSD is considered more secure by default than Linux. Despite its BSD roots, macOS has had its share of CVEs:

https://www.cvedetails.com/version-list/49/70318/1/Apple-Mac...

[JdeBP]

That's not specifically OpenBSD, though. The BSD world is not the monolith that it was back in the 1980s.

[avadodin]

True. No relevance to macOS and iOS.

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.

[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?

[snvzz]

Openbsd makes a good stopgap.

The way forward is seL4[0][1].

0. https://sel4.systems/

1. https://microkerneldude.org/category/sel4/

[binkHN]

Neat stuff, but this is not going to easily run the vast majority of open source software out there.

[snvzz]

Not today, but it could tomorrow.

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.

0. https://genode.org/download/sculpt

[ykurtov]

What? How long did it take?

[nelsonic]

How long did what take? Learning the essentials of OpenBSD, budget 4-6hours. Switching over servers from Ubuntu, an hour for the first one then 10mins each after that. You can copy config with your favourite tools; most have ports for OpenBSD already. If you want to learn more in-depth, read: Michael W. Lucas Absolute OpenBSD, 2nd Edition: Unix for the Practical Paranoid. Highly recommend it as teaches many fundamentals most software engineers skip.

[reidrac]

How many upgrades have you done so far? And how many kernel fixes?

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.

[noAnswer]

They have binary updates by now. No more need to download the source from CVS and compile fixes.

You can update from one OS version to the next with manly only one command.

[miah_]

syspatch and sysupgrade have made things substantially easier these days.

[rs_rs_rs_rs_rs]

>it’s time everyone considers OpenBSD

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.

[ori_b]

Note that this specific symlink was special cased because sandboxed programs still need to access timezones. Also note that you would need to be root to create that special cased symlink. It's embarrassing, but less catastrophic than it looks at first glance.

Running security-critical code as root is still a bad idea.

[866-RON-0-FEZ]

Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment?

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.

[gjm11]

Maybe I'm misunderstanding the video, but it looks to me as if the situation is:

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.)

[ori_b]

OpenBSD doesn't do different user accounts inside vs outside sandboxes; if you're root in the sandbox, you're root on the system.

[anthk]

Also I tried the Dirtyfrag exploit under Bubblewrap for GNU/Linux. It lasted, but finally I got root with a simple 'su'.

[wahern]

unveil was designed and intended to effectively sandbox root when combined with sufficiently strict pledge permissions. I don't think this exploit would have effected any existing OpenBSD services, but sometimes services need to keep around processes with higher privileges than the network-facing process, yet you still want to sandbox them as much as possible. For example, sshd uses a special auth process, and that process needs higher privileges to be able to access the password database. On OpenBSD this auth process doesn't need root, but there may be similar cases where you want to use unveil with a root process for defense-in-depth. Suffice it to say, it would be foolish to only use unveil with such processes.

The bug here actually involved the intersection of unveil and pledge. IIUC, it was more a pledge bug that accidentally allowed bypassing unveil checks.

[866-RON-0-FEZ]

So what? You're still root. You're relying on a sandbox to plug a few voids while you still effectively held keys to the kingdom before said voids were plugged.

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.

[MarsIronPI]

I think the idea is to not run programs as root in the sandbox.

[SmirkingRevenge]

The parents tone wasn't warranted, but bugs like this could be more serious if combined with privilege escalation bugs in the sandbox.

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)

[rs_rs_rs_rs_rs]

>Your "evidence" for him to reconsider is a sandbox "bypass" that requires you to be root to set up the environment

Can you help figure out where does it say unveil does not really work when root is involved?

[866-RON-0-FEZ]

You left a snarky comment, then paraded around a positively lame example as some sort of trophy.

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.

[3form]

So, a break out of chroot in a chroot jailed app would be a non-issue because I need root to set it up?

[yjftsjthsd-h]

If you need root to set up the escape, then yes that is relatively uninteresting. Like, we know chroot can't contain root.

[rs_rs_rs_rs_rs]

>Here's what I can figure out: you need root to set up the environment just so.

I guess you just don't understand what unveil does.

[866-RON-0-FEZ]

Your arrogance is continued proof you could never comprehend the work that goes into building, releasing, and maintaining an entire OS, and your contributions will forever be limited to snarky negativity on message boards.