One bug found is a testament to the great diligence and culture around security of OpenBSD. Especially if you take into account the amount of resources they have been able to achieve this with.
It is also a testament to solid engineering and attention to good security practices in general. These still work, also against fancy new AI attackers.
When sophisticated attacks become cheaper to run, maybe it will (finally) be cheaper to do more solid engineering instead of doing it quick and dirty and ending up in indefinite bug-squashing mode.
If your operating system only does 20% of what another operating system can do, it's easier for you to have 80% less bugs.
That's not a knock, it's a design philosophy of OpenBSD (which is to do the minimal needed, and no more, in the most simplistic way).
For example you can imagine my disappointment when I discovered what a pain in the ass it is to get a pflow producer working on linux after doing the first one on openbsd.
And obsd has no Bluetooth, right? A pretty big subsystem to drop because security.
I am not complaining, I like the feeling that I could single handedly rebuild the internet using only what is found in an openbsd base install. But wow, considering the size there is a lot in there. They definitely punch above their weight.
And it's not like the BGP daemon is on by default. That'd be dumb. You could equally say that any Ubuntu system has equally many steps to turn on a BGP daemon, starting with `apt install frr`.
I sure hope openbsd's BGPd doesn't have any suid binaries. And if it doesn't, well that might just as well be a vacation photo instead of a binary for all the "code" it is.
I agree that they're punching above their weight, but I would also say that they are falling more and more behind. 25 years ago they were more at par in what use cases they can address, and its performance. But now it's almost retro computing.
And it's fine! If you really only need a bog standard webserver, or router/firewall, then that's the use case and it solves your problem. And solves the problem without baggage.
I wouldn't use it for storage, though, since running a non-checksumming filesystem nowadays is a bit of a joke. (let's not get into btrfs. I acknowledge its history, but checksumming is not backups, and backups address the historical btrfs problems while not addressing at all the checksumming)
I'm not an OpenBSD expert, but seems like you should be able to pass BT through USB and then do that in a subsystem or an isolated environment like a VM.
I use a Creative BT-W2 bluetooth usb dongle. Small and has a button on it for pairing. OpenBSD sees it as a normal audio device.
The Bluetooth Classic spec is indeed fairly awful, but the Bluetooth LE spec is not too bad. Plus, the entire specification is available free-of-charge, without even needing to register an account.
Bluetooth LE used to be limited to tiny accessories, but these days it supports nearly everything—I've completely disabled Bluetooth Classic on my (Linux) laptop because of how much of a disaster it is, but I'm still able to use my mouse and headphones over LE only.
> OpenBSD does not have kernel modules, so it’s either in or not.
But I'm assuming that not all kernel code is active at all times? Because it would seem odd to me if the amdgpu code was always active on something like a Raspberry Pi.
There are also architecture specific builds, so the aarch64 build won't include driver code at all for devices that are specific to x86.
It mostly a drivers tree that describe how to probe for hadrware. Like mainbus -> pci -> xhci -> usb -> uaudio -> audio.
Yes, but this is exactly the point. And running OpenBSD is not a problem, until you run into a brick wall like this.
If you don't need it (and things like it), then that's all fine. As with everything, the last 10% takes 99% of the work, and code, and therefore contains about 99% of the security problems.
IIRC they were also very late to being able to run virtual machines, and even USB.
If you simply don't implement the things you don't need for a use case (e.g. a webserver) then that scales down to the fact that the compressor controller chip in your (dumb) fridge is not remotely exploitable too.
Without journaling I really don’t agree with the oft repeated claims it makes a good “router”.
Any networking gear I’ve used is treated as an appliance and I don’t want an unfortunate power outage causing data loss.
I've had my share of sudden power cuts hit OpenBSD during the 20+ years I've been using it, and I have yet to ever see its file system actually go corrupt.
A sincere question: what important data does your router frequently and busily need to persist? If you don't have a UPS for it, perhaps it isn't too important after all. Maybe we have different perspectives of what a router is and should be. I manage a router (with OpenBSD) and it can drop off the power grid at any moment without losing anything of importance. If your router is in fact a multi-functional server I can understand the notion. Consider making all of the file systems fully synchronous. It has worked great for me for two decades.
I am very interested, is there anything we can read to achieve that?
If you're really curious about it, Michael Lucas wrote a full book about the OpenBSD file system.
One thing I actually really like about OpenBSD is that things either work or they don't. There's no "Well it kind of works if you have this specific hardware set up and these programs running..." It just works 100% of the time, in 100% of the ways you expect, or it doesn't.
you mean the most simple way. "simplistic" would mean they went too far.
you mean the most simple way. "simplistic" would mean they went too far.
https://en.wiktionary.org/wiki/simplistic
simplistic
1. Overly simple.
2. In a manner that simplifies a concept or issue so that its nuances and complexities are lost or important details are overlooked.
Hard to know how much has been thrown into this but I would bet a lot.
So far I have been very surprised we haven't been flooded by those type of announcements. If you look you will always find something and OpenBSD is the top price.
that's kinda the entire point
well, they do? it's a win-win, you can't really criticise an AI lab for doing AI instead of straight up giving money to security researchers
> If you factor in all the money spent on training
why would I? it's not a cybersec-specific model
Sure I can, if they - or you - pretend "the entire point" is about useful security work rather than expensive loss-leading marketing and demand creation.
We shouldn't look at this and think "wow AI is super useful for security". We should look and this and think "wow, there's a LOT of capital going into persuading us that AI is super useful for security".
THAT is "the entire point".
> We shouldn't look at this and think
you're gonna tell me what to think now?
yes, most company settings don't run untrusted code, and OpenBSD is mostly used for servers not employee devices
but that doesn't mean LPEs aren't quite relevant, because they matter for pretty much everyone if combined with other vulnerabilities, like RCE, supply chain attack etc.
and while RCE are becoming less common, supply chain attacks have been increasingly more common
But real defenses are generally multi-layered. And in that context, a Swiss cheese slice with only one hole is still extremely valuable.
You can't opt out of the protections and then complain that there are no protections
> On other OS's, you can set things like append only,
https://man.openbsd.org/chflags.1 lists such a flag
> limit files being readable by particular processes,
That's trivial by setting group/world permissions on any unix-like.
> whitelist paths or executables from where the system may execute,
So, https://why-openbsd.rocks/fact/noexec/ ?
> etc etc etc.
Etc etc etc.
Sometimes you don't have a choice in running software that doesn't use the 'protections' an obscure OS offers. If someone wants to run Oracle, pledge and unveil is irrelivant, as where other security solutions can still protect Oracle without requiring opt-in, and to a far greater extent.
> https://man.openbsd.org/chflags.1 lists such a flag
It's too blunt, it's an all or nothing approach. You have no way to say process A can append only, but privileged process b should have no write access at all.
> That's trivial by setting group/world permissions on any unix-like.
Only in the bluntest of terms. There is no way to allow, say, a webserverto have read access to a file while not allowing a cat processes, spawned as a subprocess of that webserver process, to not have access.
> So, https://why-openbsd.rocks/fact/noexec/ ?
No, not even close. I mean allowing user a to run /bin/ls to execute while not having access to execute /bin/rm, and at the same time allowing user b to execute both, and user c to run /bin/rm but not /bin/ls
> Etc etc etc.
No, not really, since you didn't make any point that were not based on misunderstandings.
There is no such thing as 0 bugs, and fewer is better than more.