OpenBSD, the computer appliance maker's secret weapon
hiandrewquinn.github.io
hiandrewquinn.github.io
That does sound like a dream come true; how does one end up in such a gig?
> If only there were a freely-usable set of Unix-like operating systems, with an emphasis on keeping things very, very stable over releases, even more stable than Debian does. Enter the BSDs. Free, Open, Net, take your pick. All of them take a “don’t fix it if it ain’t broken” approach to things, which means someone who started slinging NetBSD installs back in 2007 can probably spin up a well-manicured VM of that 2007 install and reliably make their way around the system, even today, in 2024.
I dearly love all the major BSDs, but that... isn't the argument I would make for OpenBSD, which is quite happy to break things to improve them. For example, replacing sudo with doas - excellent move, but if you go back multiple versions your knowledge no longer works, much like Debian.
(If I were making suggestions, I tend to feel that NetBSD has largely not yet realized it isn't a barely-forked UNIX running on a VAX; it feels much more unchanging to me, at least from a user perspective, though perhaps I merely lack the experience to know better.)
Still, somehow, on the margin, I feel I'd be more comfortable hopping back into a much earlier OpenBSD than a much earlier Debian. Maybe it's a taste thing.
Its not a bad idea if you agree with the aim - Linux already has lots of hardware support and an ecosystem to leverage.
In the long run BSDs and non-systemd Linux will be more similar to each other than they are to Linux with systemd in a lot of ways.
I have started using Alpine for servers - its small and fast. Not so sure about switching on desktops.
It vaguely reminds me of people arguing about "what color is your function". You open that portal and end up in a new universe. All or nothing.
The unix wars are long over I'm not sure what you can point to that ever was a True Unix. Nostalgia not withstanding. What well defined standard Right Way you're actually clinging to is not clear.
Whether it will end up for the best or not I don't know but the entire saga seems to be the pitfalls of endless tinkering on display rather than some unifying vision. I wish we lived in a world where systemd type efforts had clear end goals and well thought out architecture in mind when they start but open source doesn't like working this way.
It just ends up as "my favorite way of doing things is better" based on vibes. In both directions. That's the problem with "philosophies".
The best argument I have seen for systemd is that it adds a layer that will be used and standardised across multiple distros (most effectively in a video of a talk by a FreeBSD developer). The best argument against is that it is massive and does too much.
Like Google Play Services on Android.
I've been using it for years. It's the successor to slack for me. Not a fan of rolling release and prefer minimalism to Devuan's approach. Void looks interesting but I had issues, whereas I had none with Alpine. I recommend it.
It's fine. I've run it on laptops (IIRC, it does have the small downside of not sleeping on lid close by default) and my desktop (my gaming machine for a while; flatpak Steam runs nicely on Alpine) and it's fine.
I'm curious about "fast" here, as for "small" I don't care much - you mean benchmarks doing better on Alpine or fast in which terms?
Since OpenBSD's purpose is to make one of the most secure UNIX platforms that's where they generally break things. They also anticipate security holes related to speculative execution like disabling hyperthreading.
The BSD license
Yes, thanks to the magic of the BSD license you can ship an appliance that is nothing more than a vanilla BSD and some hacky scripts and never have to worry about your customers demanding to see how much jank you have shoved into the box.
Forbidding your users to see the inner workings of the system (hiding the jank that has been shoven into the box, as you say), does not seem like a positive thing..
But there's plenty of jank in e.g. Android phones. And of course anything the vendor doesn't feel like open sourcing they can just cram into something like 'google play services' to keep it closed source.
And vendors who want to TiVo-ize Linux can do it just fine, thanks to the Linux kernel embracing the TPM.
For example every software/firmware using custom Risc-V instructions is tivoized.
The problem of blobs are inability to examine it and inability to reasonably modify it.
Tivoization just makes it harder to run a software/blob on different hardware.
Can you explain?
I disagree. Tivoization means using hardware restrictions unrelated to the core functionality of the hardware to make it difficult to run modified code. The original Tivo checked digital signatures in the bootloader. This isn't core functionality, because it could be deleted without harming anything.
Merely writing software for unique hardware doesn't count as Tivoization. It's very common for software written for older machines to only run on that exact machine, and nobody calls it Tivoization. There has to be some feature added specifically for the purpose of restricting user freedom.
Indeed, I don't consider the BSD license a good thing from a user's perspective. Companies love BSD/MIT licensed software though.
Maybe I should have included a "/s" in my post.
if you can afford the lawyers.
Also, if the appliance vendor has put in some binary blob/module, you have no right to see that either (only the changes to the kernel). In the end, it really doesn't matter.
Buy proprietary stuff or don't.
Of course! But trust is unnecessary with code in hand.
Again buy proprietary or don't, the license (if opensource) has nothing to do with it.
But for appliance use, I think NetBSD has a very slight edge over OpenBSD:
* NetBSD has very long release cycles. OpenBSD's 6 month release means you will have to upgrade all appliances at least once per year.
* On install, NetBSD allows you to install a very small subset of the system. OpenBSD recommends installing all packages. But with that said, both systems are very small when compared to Linux.
OpenBSD to me has one advantage I can think of right now. Upgrading is a easier, if you keep upgrading every 6 months. They seem to be heading to fully automated upgrades.
But with NetBSD, it is possible to skip releases (ie: 8.x to 10.x) if you know what you are doing. I went from 7.1 directly to 9.3 and got a workable system. But that did mung pkgsrc, a bit of hacking got that "workable". Once the "emergency" was over, I did a full reinstall of 9.3.
Anyway, yes, I agree just about any BSD would be great for appliance use.
I got into OpenBSD again when I bought a new, cheap potato to play with -- an HP thin client PC I scored off eBay for $25. The super-lightweight candidate operating systems I tried for it -- AROS and Haiku -- both struggled with its eMMC controller and couldn't even find a volume to install to; the same, oddly, was true of NetBSD. OpenBSD found it just fine.
The best defence, IMO, is not to have the thing if you don't need the thing. Having to remember about it all the time sometimes prevents the work from getting done.
The traditional configuration for a server or router is to block in the firewall all the unused ports, which means that ICMP responses will not be sent back, with the exception of the range of ports that are normally used by the "traceroute" utility.
Unfortunately, there are also stupid people who block in the firewall even the traceroute ports, which makes more difficult the diagnosing of any network problem.
It's nothing to do with OpenBSD though, is it. I swear it's ingrained to people to just unconsciously compliment OpenBSD's security and spread the myth.
Put fail2ban on a public facing webserver or setup any kind of honeypot and enjoy the exact same thing.
Enough of the astrological pseudo-science. This distro is good for hackers, use this if you want stability, use this for bleeding edge, this one is secure by default, that one has a nice UI, it's all nonsense.
The only meaningful changes have been: The effective mandatory adoption of SystemD, and the emergence of NixOS.
NixOS elevates the entire discussion. I can't wait for it to work across different UNIX kernels. It's not ready for regular people, it's not even ready for most enthusiasts, the language is awful and the nixpkgs set is full of inconsistencies, but it's all worth it.
So let's stop with the voodoo and start applying the techniques in other places. Nix without Nix is what we need.
OStree exists and is used in lots of places: https://ostreedev.github.io/ostree/#operating-systems-and-di...
So, GNU Guix?
I don't know what a successor would look like, I worry that it would have to wrangle with 40 years of software compilation techniques.
I'm quite a fan of its approach as well, maybe a little less so when disk space is a big concern like it often is for computer appliances.
on the dev pc you'd run garbage collection once your new env is acceptable and the old one gets removed.
NixOS and Docker and other Linux container and isolation madness only exist because the Linux illuminati can't admit that zones and ZFS got it right.
I wish Linux would just STFU and copy them already. Given the amount of code that has been spilled, Linux could have cleanroom reimplemented zones and ZFS 10 times over by now.
The process feels more like compiling a program than decorating a house.
Ehhhhhhh.
As a teen eating up all the computer security stuff I could find, and getting into osdev and learning as much as I could, OpenBSD always seemed kind of off to me. The security claims are hugely overstated, and for an OS that claims security as its focus, they are slow if not reluctant to add tools that vastly increase security, like even a simple RBAC implementation.
Disabling services by default should have been the default for all operating systems, and writing OpenSSH has been great, but let's all stop perpetuating the myth of OpenBSD as an especially hardened OS.
I agree about the BSDs being a secret weapon, but that's more to do with the license as someone else mentioned, and I'd think Net and Free are more commonly taken from.
If people want to learn more there is no shortage of info. There was even a talk[0] at the 36th CCC.
Look at their remote root ssh bug. If they were a secure OS, someone getting remote root wouldn't be such a big issue, with RBAC/MAC it's clearly not such an issue, with the default 'secure' install, it sure was. Then again, I don't think the obsd devs have a real interest in security, so much as an interest in correcting bugs, which they falsely equate to be the same thing. Pretty sure one dev had no idea what MAC/RBAC even is and was trying to claim pledge is the exact same thing, which only lessens any confidence I had in them.
But I saw a post were this did happen to someone and they had to do a re-install. But they did say that had a full backup.
* it's abandoned.
* it's good for what it does, why change it?
I don't know, to be honest, in which of these most BSDs are. But I see very little reason for an Operating System's tools and utilities to have changed much since the early 2000's. Perhaps even since the 1990's. Sure, their implementations may have been significantly improved, and maybe they've got some new stuff (specially in things that do need to evolve, like crypto) but the overall user interface remains the same. I think we should start seeing change for the sake of change as a bug, not a feature.
Immediately, this quote came to mind: Those who don't understand Unix are condemned to reinvent it, poorly. - Henry Spencer
Alternatively, Just do what slack did with irc. 'Reinvent' it with a modern interface and some fixes. The mercurial masses will flock to the hot new platform, VC will shower you with adoration and cash, we'll tell stories about how you don't eat breakfast and only ever wear one sock. Everyone will emulate you and then you can come back around as a wealthy guru investor. - @more_corn
Or the wise man yells at cloud version, It used to be the case that people were admonished to "not re-invent the wheel". We now live in an age that spends a lot of time "reinventing the flat tire!" The flat tires come from the reinventors often not being in the same league as the original inventors. This is a symptom of a "pop culture" where identity and participation are much more important than progress... - Alan Kay (2016)
OpenBSD is innovative, especially in all matters of security and stability. SROP, privilege separation and revocation, W^X, PIE, trapsleds, fork+exec separation.
Removing weaknesses is evolution.
15 to 30 year lifespan of an average B2B computer appliance
Decades of recurring, non-evolving revenue vs. S-curve surfing.
Decisions, decisions.
Both OpenBSD and FreeBSD have laughable security disclosures and absolute lack of any compliance processes, which is the most important part as a vendor of anything.
FreeBSD even got that far that they invented their own VuXML format (without a spec, of course) instead of adopting an open standard like OVAL, which is used by most enterprise distributions. In the BSD world, vulnerability disclosures happen via mailing lists, aka, bad luck if you missed the email. And that's the definition of being 100% unreliable.
OpenBSD doesn't even have a VuXML file. Only free form text archive of emails that is unparseable.
I don't understand how anyone can claim they are so super duper secure in their development cycle, while not even having a web page of security disclosures that happened in the past. It's pretty damn narcisstic to be honest.
Useless source, because it is not parseable in an automated manner.
https://www.freebsd.org/security/advisories/ or
http://vuxml.freebsd.org/freebsd/index.html
Missing one of the infrequent emails from the security mailing list would be hard but my boxes also email me about vulnerabilities they are exposed to so it would be very hard to ignore them.
I am sure there is room for improvement though.
Never mind the actual security and quality of the code and professionalism of the people involved. The dances are not performed and the compliance Gods are not appeased.
No one said anything like that. They're just saying it's harder for developers and businesses to utilize them as they do other projects that use standard formats and practices. Relax.
Security is not about code quality, it's about how quickly you can mitigate mistakes. And "quickly" meaning since around 2005ish that it is done in an automated manner.
For BSDs, you will always need a dedicated person that is not only able to read code, but also able to maintain patchsets, roll out an update mirror for themselves, and understand _every line of code_ of the distribution, because BSD doesn't have a workflow to let package maintainers communicate what happened in CVEs so that their using parties can consume that data in an automated manner.
Nobody will do that job correctly, because nobody can. If you claim you can do, you must be the all knowing "God of compliance" how you put it. If you think you don't make programming mistakes, guess what, you are wrong.
Get over your elitarian opinion and realize that all humans make mistakes, therefore automated tools must adapt to that scenario and ease up mitigating those issues.
And that's where open industry standards like OVAL come in.