OpenBSD is a cozy operating system | Hacker News Reader

OpenBSD is a cozy operating system

btxx.org

118 pointsskeptrune88 comments

I like the aesthetic of BSDs in general, and what is nice about OpenBSD in particular is that it is opinionated, but the opinions are mostly on point.

Documentation is comprehensive, and configuration can be completely derived by reading man pages. The defaults are reasonable, and the documentation is useful for tweaking things.

Both pledge and unveil have made certain third party applications like Chrome significantly safer.

The OS is small and performs well on older hardware. I use it on my "throw away" travel laptop with full disk encryption backed by a USB key that I keep separate from the laptop when it is not in my immediate possession.

I also ported my personal website to OpenBSD. I use a variation of BCHS (https://learnbchs.org/) for dynamic content. I've tweaked this framework to use serialization barriers and LMDB instead of SQLite. I can use both pledge and unveil along with some DJB style application decomposition to get reasonable defense in depth while keeping the code easy enough for a newbie to understand.

Is it better than operating system X? Probably not, but really, that's not the point. It's small, well put together, well documented, and safe enough.

I run FreeBSD on my development server, mainly so I can take advantage of ZFS and better virtualization support. But, many of the virtual machines I run on my dev server are OpenBSD based.

Thank you for writing this. I always find it very hard to put into words what it is that makes OpenBSD "click" for me, but what you write here is about as close of a description as I have yet to find. The whole package and process just subjectively feels "right" for me (note the emphasis). Yes, I am probably better off in terms of productivity elsewhere. But that is not what it is about to me. At home, where I am in control, I just want things to feel "right" and that is somehow what OpenBSD does for me.

but then you're stuck with Xorg... and slower vms... only disadvantages I can think of honestly

Neither bothers me. Both work just fine on older hardware. I don't need cutting edge performance.

ELI5 why the “xz drama” couldn’t happen on openBSD? do they not use open source packages? are they assuming they would have caught it before adding the infected version to their repos?

The back door relied on a couple of Linux package management systems (if I’m recalling correctly, it had .deb and .rpm checks, see https://marc.info/?l=openbsd-misc&m=171227941117852&w=2)

was it mostly about the targets the xz actor was interested in than some security property inherent to openbsd that would prevent that sort of dynamic linking vulnerability?

Debian and RedHat link liblzma into SSH for systemd which OpenBSD doesn't use. So in the sense of there being a larger attack surface with those distros I guess you can consider it more secure, but it's not just OpenBSD though; there are plenty of Linux distros that don't do this either.

If you run the 'ldd' tool against OpenBSD's ssh, you get 4 libraries. If you do the same on different Linux distros you get many more; this means the surface area is much larger.

OpenSSH and the OpenBSD init system are part of the base system, maintained by OpenBSD developers. There's no opportunity for an outsider to use dependencies to insert backdoors in critical components.

It didn't matter where the init system came from, but where xz came from.

it does. If the init system links xz... and systemd does.

My understanding is that nothing in base has a dependency on anything outside. There may be some third party software in contrib (if OpenBSD has contrib, like FreeBSD), but I don't think the 3rd party software's build system would be used.

Some BSDs use an external compiler on some platforms, and in that case, you have a build dependency on that, and trusting trust may apply.

> that nothing in base has a dependency on anything outside.

From [0]

"The system includes the following major components from outside suppliers:

Xenocara (based on X.Org 7.7 with xserver 21.1.11 + patches,

freetype 2.13.0,

fontconfig 2.14.2,

Mesa 23.1.9,

xterm 378,

xkeyboard-config 2.20,

fonttosfnt 1.2.3 and more)

LLVM/Clang 16.0.6 (+ patches)

GCC 4.2.1 (+ patches) and 3.3.6 (+ patches)

Perl 5.36.3 (+ patches)

NSD 4.8.0

Unbound 1.18.0

Ncurses 6.4

Binutils 2.17 (+ patches)

Gdb 6.3 (+ patches)

Awk January 22, 2024

Expat 2.6.0

zlib 1.3.1 (+ patches)

[0] https://www.openbsd.org/75.html

What openbsd includes in the base system is the real star vs the way linux distros get made.

The critical piece was systemd, was it not? ssh is no dependent on xz, it only gets there through the "systemd notification" hook provided by vendor specific patches.

> The critical piece was systemd

Not really, systemd was 1 way that openssh could load liblzma, but another would have been thought the selinux PAM stack. It didn't exactly rely on anything systemd specific, just that it was a (transitive) dependency to openssh.

And the entire notification stuff can also be done without linking to libsystemd, but the maintainers that added the patch I guess didn't want to reimplement it manually (now the docs have a fully functional example ready to copy-paste, but before the protocol was just explained).

selinux PAM stack

So... Some other huge subsystems that OpenBSD does not include.

What I am trying to say is: it doesn't have to be any specific dependency, it can be any dependency that somehow loads liblzma. It can be a tiny mostly insignificant direct dependency if you want, it doesn't matter, it just needs to somehow be loaded into the address space.

But if such things are avoided across the board as policy, exactly to attain the result of reducing that attack surface, then there are few such possible examples, and so you can't just say "it could be anything" you have to show that there is actually much pool of "anything".

What's an equivalent example that could actually happen in openbsd?

no, it wasn't. But even if it was, the flaw was in xz.

It depends on what is meant by "xz drama".

If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider it worthwhile trying to invest in the long supply chain attack for the OS.

If you view it as the break-xz-to-attack-sshd, OpenBSD is designed as a single system with a single codebase, and has a general aversion to features such that it is difficult for an undersecured random library to become a vehicle to breaking a major, important component.

If you view it as the techniques used to publish an exploit in open source code, well, OpenBSD is filled with the kind of developers whose self-confidence is such that they believe that they are uniquely capable of writing code without those kinds of issues and will denigrate the use of newer technologies that mitigate that risk with the attitude that it coddles programmers and coddled programmers aren't good programmers. Or, in shorter terms, OpenBSD is actually one of the projects I'd expect to have a relatively high chance of a clever contributor being able to smuggle in an exploit in plain sight.

Which newer techniques?

Honest question.

Not parent but jails and capabilities that are user controlled and not hardcoded into the binary would be nice to see.

Do you think they understand the benefits? I think you'd have a lot better chance at enacting change than my emotional rambling has, and if not, lesson learned.

They tried this. The predecessor for pledge / unveil was systrace, which included a user-controlled policy file.

One significant reason that pledge was implemented was because it is possible to disable or mis-configure user-controlled policies. Theo mentions this in his presentation that unveiled pledge, and he's basically referring to things like seccomp and systrace:

https://www.openbsd.org/papers/hackfest2015-pledge/mgp00005....

More explicitly mentioning seLinux / seccomp:

https://www.openbsd.org/papers/hackfest2015-pledge/mgp00008....

https://www.openbsd.org/papers/hackfest2015-pledge/mgp00011....

More explicitly mentioning systrace:

https://www.openbsd.org/papers/hackfest2015-pledge/mgp00009....

Certainly, it's possible to debate the relative merits of this approach, but this is why OpenBSD has moved away from user controlled policies.

> If you consider it to refer to the supply chain attack, well, OpenBSD is too minor a platform for anyone to consider it worthwhile trying to invest in the long supply chain attack for the OS.

I agree that OpenBSD is a minor sized target, but I recall these bits from back in the day.

EDIT: accusations from ~2010 about actions ~2000

"FBI accused of planting backdoor in OpenBSD IPSEC stack" [0]

"A Chapter from the FBI's History with OpenBSD and an OpenSSH Vuln (twitter.com/rooneymcnibnug) 127 points by signa11 on July 21, 2019" | 23 comments [1]

"Theo de Raadt summarizes the OpenBSD IPSec "backdoor" situation"[2]

and HN discussion "36 points by there on Dec 21, 2010 | 47 comments [3]

[0] https://arstechnica.com/information-technology/2010/12/fbi-a...

[1] https://news.ycombinator.com/item?id=20489904

[2] http://marc.info/?l=openbsd-tech&m=129296046123471&w=2

[3] https://news.ycombinator.com/item?id=2029175

The OpenBSD IPSEC stack thing was very silly.

https://news.ycombinator.com/item?id=2029640

Last paragraph is off base. They have a long history of doing mitigations by default before they are seen elsewhere. A lot of those are from more than 20 years ago though -- things like fewer services by default, daemons that chroot and drop privilege at a time when Linux didn't do that, W^X, address randomization.. more recently they do some stuff to prevent shellcode from making syscalls.. this IFUNC mechanism to monkey patch system binaries is something they would not go for.

I'm going a bit far off of my wheelbase here, because exploit development and mitigation is not an area I have a lot of experience in, but the sense I've seen from security researchers is that OpenBSD's security posture is far more mixed than their developers' touting implies. So while OpenBSD may have some features that are well-regarded (say, their malloc implementation), they can do a shockingly bad job in other areas (such as ROP mitigations).

I think you're expressing an opinion that is pretty mainstream among runtime hardening and exploit people. You can find reasonable opinions in both directions, though. Joshua Stein built a page that is a pretty incredible resource on this topic:

https://isopenbsdsecu.re/

I’ve not seen any openbsd exploit code in… a decade though? Can you point me to a single working exploit for anything in openbsd lately?

(Excluding shellshock/log4shell kind of vulns)

I mean an exploit against some service running on openbsd, or even necessarily the os contents..

Edit: I don’t mean an 0day, just an exploit that worked on some combo of openbsd and x. X being anything like e.g Apache or Bind or whatever

There was an RCE in OpenSMTPD --- a 25/tcp RCE, that'll bring you back to the '90s! --- like a minute ago.

I think that was early 2020 if memory serves. There was another serious security bug discovered a few months before too.

2022.

Do you have a source for that? I run it on a few machines and monitor that stuff, I think I would remember. I remember patching that one before the portable tree release with the fix was in a distro. I remember it very well because I was rushed, heading out to a meal but realizing a machine was vulnerable.

Here's what I find googling:

https://github.com/superzerosec/cve-2020-7247

2020-01-29

I think later they had another crashing bug that wasn't exploitable. This one from 2020 was poor validation of input leading to a shell command. A very 90s bug indeed.

Oh! You're totally right. I had two different links, and, of course, the actual Qualys advisory has the date you're giving it. Thanks for taking the time to correct me on this.

citation needed for the failings of their ROP mitigations. I don't use openbsd for the security, so I don't pay much attention to that side of things. But the one that stood out was where they removed all rop gadgets. which sounds pretty good to me.

https://www.openbsd.org/papers/asiabsdcon2019-rop-paper.pdf

The link tptacek gave to a talk is such a citation, albeit at a very high level.

I'm not commenting on OpenBSD's security, but I think some of that goes too far:

> OpenBSD is designed as a single system with a single codebase, and has a general aversion to features such that it is difficult for an undersecured random library to become a vehicle to breaking a major, important component.

From what I understand, those security benefits aren't incidental; they are a major reason for doing those things.

> a clever contributor

Doesn't seem like it would be very hard for someone to join the team and obtain maintainer status? Also, remember the social engineering done by the xz attacker to get their exploit included in updates - that also seems a bit challenging in the OpenBSD project.

OpenBSD seems to do more careful code reviews than other projects, but I don't know that I have an objective measure of it.

OpenBSD source gets independent code reviews, and they run syzcaller continuously.

https://marc.info/?l=openbsd-tech&w=2&r=1&s=coverity&q=b

https://marc.info/?l=openbsd-tech&m=164303498026116&w=2

People used to say backdoors and security bugs were less likely on Linux because 'open source'.

Sociological theories of computer security are magical thinking.

(By 'people', I mean me and also the person who introduced me to Linux.)

The "all bugs are shallow" schtick is not about bugs being less likely, only that bugs are more likely to be brought to light. Which is still true: the xz backdoor never would have been found in a closed-source codebase.

"ELI5 why the "xz drama" couldn't happen on [O]penBSD."

It could happen but it did not happen.

Linux distributions that use glibc and systemd are popular. Linux has millions of dollars behind it, and many corporations contributing their time and money, some building businesses around Linux. AFAIK, OpenBSD does not have similar resources. It's volunteer-supported.

Berkeley Software Distributions use their own libc, such as OpenBSD, and their own init system (not systemd) and are relatively unpopular.

The liblzma exploit that was discovered targeted Linux distributions that use glibc and systemd. Specifically, it relied on a feature of glibc called ifunc.

If an exploit targeted OpenBSD, then there would probably be less "drama".

Unpopularity probably plays a role in avoiding "drama".

Also consider the use of features such as ifunc and systemd. In some cases Linux may use features that BSD projects do not have. The liblzma exploit author chose to target Linux-specific features.

Also, glibc and systemd are different projects, the later is associated with a commercial entity. The libc and init system used on a BSD project are normally both parts of the BSD project, and the project is not associated with any commercial entity. Whether that has any effect on anything is left as question for the reader.

BSD seems really nice for its target audience. The people know what they want and the OS respects that.

With Linux there's a bunch of people who seem to want Linux to be more like BSD, while the rest want it to be more like Windows/Android, so there's a lot more bickering.

Fortunately, you can install Gentoo/Void if you're in the former camp or Ubuntu if you're in the latter camp.

I have not used Void Linux, so I can not comment. However, I do not think that source distributions like Gentoo, NixOS, etc. are a good comparison to what you get with the BSDs. BSDs (especially OpenBSD) tend to be about sane defaults and shipping rather complete systems, while the source-based Linux counterparts are more about endless configurability and how to tame it. Not arguing that one is better than the other (especially as I have used both Gentoo and NixOS), but it is certainly a very different take on what a *NIX system should be compared to the BSDs.

Void Linux is, to a first approximation, "Arch without the BS". Because it ships a musl version, and because Lennart thinks anything but Linux/glibc is a niche corner case which can simply be ignored, Void does not use systemd but rather runit. (Indeed, it's the only distro I know of to officially switch away from systemd to something else.) Also, there are few, if any, distro-breaking flag days. I once blindly typed 'xbps-install -Syu' into a Raspberry Pi 2 that had fallen 2-3 years behind, and everything just chugged along and updated without a hitch.

Source: I use Void, btw.

FWIW I recently reverted to Arch after five years because Void broke itself completely, but it was otherwise a decent OS.

You mean the distro has gone in the wrong direction, or your specific five year old installation died somehow?

The latter, an upgrade gone awry and I couldn't be bothered to fix it. I use Arch on my work laptop (a concession to modernity and having easy access to whatever), so it was simple to move my primary Good Screen to it as well.

The thing that makes me curious about BSD (haven’t had a chance to give it a try yet) is that its more of a complete system, unlike Linux, which is a kernel in the middle of all of these modular components. How these components are managed is what makes distributions, but there are misgivings about the stubborn cultures that back each distribution.

Ironically, the thing that I find most appealing about switching to a bsd is what makes it most similar to Windows, in that its mostly a whole operating system.

I like KDE, I don’t ever eveb change the wallpaper, though. I don’t want a tiling windows manager, I dont care about x vs. wayland, I just want to see what I’m doing, and, oh the system works? F—- if it uses systemd or not!

You got a version of a package that isnt 3 years old? It doesn’t have the newest backdoor? Great! I can get things done!

And thats why I find something like FreeBSD appealling. Im sorry, I want to get things done, maybe have some fun, and not have to deal with a future of subscriptions or invasive telemetry. Sorry if I want a bsd thats too much like Windows…

Yep, installing Ubuntu is exactly what I do.

I'd imagine it's a bit harder for the Gentoo users, since it's easy to accidentally add a dependency on some DBus daemon or something, and never notice if you don't ever use any lighter distros.

OpenBSD is also make a nice router too. With its minimalist design combined with secure by default system.

https://web.archive.org/web/20240000000000*/https://filebin....

Why the link to a zip file?

Also, OpenBSD support for WiFi is generally considered less robust than Linux. For example, no 802.11ax support as of this post: https://www.openbsdhandbook.com/networking/wireless/#support...

> All the core systems just work out the box. Yes, you need to "patch" in WiFi with a firmware update, ...

... did someone change the meaning of "out of the box" or "core systems" while I wasn't looking?

I guess WPA3 and bluetooth are not "core systems" either.

IMHO, bluetooth is definitely not a core system for a desktop/laptop. Experience has taught me the bluetooth rune is an ancient symbol that means probably might work. There's no reason I would purchase a bluetooth perhipheral when a wired equivalent is available.

For a mobile phone, it's probably a core system; connecting to a car radio is an important use case. If wired android auto/car play includes hands free calling over usb, then that could be enough, and maybe bluetooth can be relegated to my history bin; but a lot of people like wireless earbuds.

As for WPA3, I dunno? Afaik, I've never needed that either, but my wifi is a bit old.

For people wanting to use BSD in desktop systems, they arguably are. For those like me who primarily use it in servers, they’re not.

Good point. I use FreeBSD on a daily driver NUC and I have no need for neither WiFi not Bluetooth. But I know I'm an outlier.

Support on that front could definitely use some improvement. I had to turn off Bluetooth in the bios because it made my box hang on startup. Never bothered to find out why because I don't need it anyway.

Does it really matter which unix OS to use? For me it boils down to the package manager. Arch and NixOS come up as the best options: https://repology.org/repositories/graphs

Yes, there's a huge difference between Linux and BSDs.

I wonder what's the performance delta like with latest OpenBSD and FreeBSD. The gap used to huge. Have we reached the point where we could ignore that performance cost and adopt OpenBSD for majority of appliance and applications.

I imagine it remains significant, and will always be so.

OpenBSD prioritizes simplicity over almost all else.

And modern OS’es do complex work to fully utilize all cores. This complexity is something OpenBSD has yet to adopt.

Ironically, DragonflyBSD forked from FreeBSD over wanting to go down an innovative (and simpler) approach to SMP … and while it took it awhile to get there, its performance is on par or better than all the BSD, including FreeBSD. (With the smallest of all dev teams of the BSDs too)

> Incredibly secure operating system (No xz drama here...)

What makes OpenBSD incredibly secure?

Their development process. Like safety, security is the result of process, not a feature.

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.

So I can only give a recent example of pinsyscalls(2), which associate a system call to a specific memory address to prevent return-to-libc attacks. It's subtle system/OS stuff that make it secure. You throw that out the window installing third party apps though... OpenBSD is best served pure if security is your main angle.

The purpose of that website is to take down OpenBSD's reputation for security.

Well obviously. The question is, are they wrong to do so?

Actually their stated reason for making the site is that they don’t like the politics of openbsd devs

> Because the OpenBSD community is notorious for not being nice and welcoming:

That's not their reason for believing that obsd isn't as secure as claimed or that their development practices are bad, however, that's just their reason for not directly coming to the obsd developers with the issues instead of just making the problems public for other people to make their own choice about.

And it isn't about the politics of the obsd developers, as I would have thought that website would have made abundantly clear, it's about the fact that the obsd developers are extremely prideful and unwilling to listen to other people's input and have crank-like is used concerning security according to most security professionals, so it would simply be unproductive to come to them with these issues.

So your attempt to insinuate that this website is purely dunking on obsd because their community is insufficiently inclusive or progressive or whatever and has no actual technical merit to it is simply wrong and misleading.

> however, that's just their reason for not directly coming to the obsd developers

In other words they intend to hurt the reputation of people they don’t like rather than fix problems.

They literally said, the website would not exist but for spite.

> obsd developers are extremely prideful and unwilling to listen to other people's input

That describes these sideline critics well. If you show the devs a vulnerability you don’t think they will fix it?

> has no actual technical merit

Well that’s ok because I’m talking about a social problem.

I think it's impossible to tell because there's not enough people who are smart enough to prove that who care enough to do so AND who enough other people will believe. For example, half the people I ask consider Whonix dev Madaidan (and his thoughts on OpenBSD security: https://web.archive.org/web/20220227172102/https://madaidans...) to be wrong, while the other half think he's right. There's no majority consensus because everyone thinks they know better.

Madaidan is a bit of a mixed bag in my opinion — they are probably mostly factually correct in their statement about everything in my opinion, but it seems like they are deeply unfair to Linux (praising other OSes for things they've barely done and then criticizing Linux for barely doing those same things) and have fallen for the flatpak FUD. In the case of their opinion on obsd, I think they seem correct, and their opinion lines up with the other website criticizing obsd so there's that. But you're right, it's hard to know as a layperson.

The binaries get signed with signify by god knows who. But other than that. Everything goes through unsigned patches via mail. Peers have to reply with "ok". Someone with write access to the CVS has to check it in. How is this process more safe against an xz style social engineering attack?

On top of that, would a direct attack on their CVS even be noticed? I hope so.

It certainly is "incredibly secure" in the sense of "not credible".

Unix in general is a very cozy tent with a lifetime supply of canned beans, set up in bear territory.

Ok for a while but I wish we had build a house by now.

Hm? My KDE Plasma setup on FreeBSD definitely feels like a house to me :)

And it's really my house, not Microsoft's, Apple's or even Canonical's or RedHat's.

I agree, I use obsd as a desktop system. and objectively it is worse than a linux system. yet, there is something about it, A thing that I find difficult to put into words, where I dread those times when I boot into another os and am happy to get back to my comfortable obsd system.

Now a large part of this is familiarity and I like to delude myself that it is because I feel that I understand obsd is a way that would be very difficult on any other OS. But I don't like free or netbsd nearly as much. So because I am unable to describe what I like about it I would suggest people try it, if you like it, that is great, but if you bounce off, which is understandable there are an awful lot of limitations using obsd on the desktop, don't force yourself to use it.

If it ever gets a modern file system I could probably use it for a daily driver. But powercuts are just a fact of life here.

this webpage is powered by FreeBSD according to the footer

This mentions the docs. I don’t know what it is about the BSDs that attracts people fanatical about writing approachable and comprehensive documentation. It’s hard describe how good it is to someone who hasn’t experienced them, like explaining “blue” to someone who’s never been outside.

I'm more of a FreeBSD folk and occasional contributor to the handbook. Installing an OS you've never used just by following the goddamn manual surely is a refreshing experience.

I think this has to do with the BSD’s origins as extensions to AT&T Unix. AT&T Unix shipped with excellent documentation beyond man pages. In fact, some of this documentation was included with FreeBSD, alongside documentation written by key Berkeley people such as Marshall Kirk McKusick. (I don’t know if FreeBSD still ships with this original Unix documentation due to its age. I remember reading a lot of this nearly 20 years ago as a high school student during the days of FreeBSD 5):

https://docs-archive.freebsd.org/44doc/

This is what make OpenBSD great. The software does what the documentation describes and there is only one source of documentation.

The same seems to be tru for nuttx which I just stred exploring.

It’s cozy until you need to use their version of clang. Even macos bootstraps pkgsrc better than OpenBSD. In this sense MacOS is more BSD than OpenBSD.

Reply on news.ycombinator.com