Recent and not so recent changes in OpenBSD(bsdly.blogspot.com)
bsdly.blogspot.com
Recent and not so recent changes in OpenBSD
https://bsdly.blogspot.com/2021/08/recent-and-not-so-recent-changes-in.html
39 comments
Just a hint, HardenedBSD and with that FreeBSD the base of OPNsense had no change in the PF-syntax since years..just additions. I think that's why pfsense and opnsense chose freebsd and not openbsd....well and smp.
Show and tell.
Why do you mention Microsoft: "I have many problems with Microsoft"
Why do you mention Microsoft: "I have many problems with Microsoft"
>Why do you mention Microsoft
Because of the backward compatibility, Solaris/illumos is maybe comparable.
Because of the backward compatibility, Solaris/illumos is maybe comparable.
do you have some concrete examples? i have used pf since it was turned on in openbsd (i think around 2001ish) for simple rulesets, and there were certainly some changes that needed config file changes but i don't remember anything hugely painful, actually the changes were for the better.
When they happened, they were always well documented in the "how to upgrade" document and blindly upgrading without reading that is not good practice in any OS, not just openbsd... Then it's just a question of automating it, and there are ways to roll back pf rules with simple scripting...
Regarding the book, they are bound to go out of date, but I think their basic premise stays useful over time: it explains the basic terminology, notions, etc and gives some ideas about how to solve problems with the syntax at the time of writing. The man page can fill in the rest (which is excellent quality).
How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
When they happened, they were always well documented in the "how to upgrade" document and blindly upgrading without reading that is not good practice in any OS, not just openbsd... Then it's just a question of automating it, and there are ways to roll back pf rules with simple scripting...
Regarding the book, they are bound to go out of date, but I think their basic premise stays useful over time: it explains the basic terminology, notions, etc and gives some ideas about how to solve problems with the syntax at the time of writing. The man page can fill in the rest (which is excellent quality).
How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
> How many linux books got out of date covering linux firewalling? what is the firewall cli/rules language du jour at the moment? There's one for every finger on my hand...
I'd argue that it's iptables, and has been for the last 20 years.
In Linux 1.1 (1994) there was a port of FreeBSD's ipfw. ipfw was replaced by ipchains in Linux 2.2 (1999). However, ipchains was quickly replaced by iptables in Linux 2.4 (2001). And now since Linux 3.13 (2014) iptables is slowly being replaced by nftables, but most of its use is the iptables userland being ported to use the nftables kernel interface; the nftables native userland (`nft`) only just hit 1.0.0 this month.
Other higher level "more user friendly" wrappers have come and gone; Ubuntu's ufw (which wraps iptables), RedHat's firewalld (which wraps nftables), and uh one for each finger of my hand. But at the end of the day, they're iptables/nftables under the hood, and when you want to configure things they way you would with pf, you skip those layers and go straight for iptables.
I'd argue that it's iptables, and has been for the last 20 years.
In Linux 1.1 (1994) there was a port of FreeBSD's ipfw. ipfw was replaced by ipchains in Linux 2.2 (1999). However, ipchains was quickly replaced by iptables in Linux 2.4 (2001). And now since Linux 3.13 (2014) iptables is slowly being replaced by nftables, but most of its use is the iptables userland being ported to use the nftables kernel interface; the nftables native userland (`nft`) only just hit 1.0.0 this month.
Other higher level "more user friendly" wrappers have come and gone; Ubuntu's ufw (which wraps iptables), RedHat's firewalld (which wraps nftables), and uh one for each finger of my hand. But at the end of the day, they're iptables/nftables under the hood, and when you want to configure things they way you would with pf, you skip those layers and go straight for iptables.
IMO once you start down the ufw or firewalld path, managing iptables directly is off the table. Do one or the other if you want to stay sane.
FreeBSD’s PF avoided this. The downside is obviously the lack of nice new things like ‘rdr-to’ rules, but FreeBSD PF is also SMP-capable as of FreeBSD 10.0 (a long time ago) so its a fair trade imo
Today is more distant from the pf syntax change than the change was from the introduction of pf.
They made breaking changes as recently as 6.9 (May 2021). Major breaking changes go farther back, but the threat of new breaking changes is ever present since this is, as another commenter mentioned, just the philosophy of the project. That makes it unusable for me in anything beyond a home lab, but others may have different scenarios.
It makes me pretty sad to read this. I always liked their no compromise approach with regards to security. Seems they took Haskells' "Avoid success at any cost" literally.
The release notes describe the change and you have a full six months of supported security patches to make the change given their support / release schedule.
If you aren't looking at your pf.conf every six months, I would be concerned.
If you aren't looking at your pf.conf every six months, I would be concerned.
This is kind of OpenBSD's vibe. They tend to be ok with breaking backwards compatibility in favor of their idea of forward progress.
It's pretty counter to Microsoft's incredible investment in backwards compatibility. Or Linus' "don't break user land" philosophy.
I'd think if we had a spectrum of backwards compatibility, with the most being on the right it might look something like this:
OpenBSD ---> macOS/iOS ---> Linux ---> Microsoft
I think in the OpenBSD case, due to limited developer resources, and a cultural bias towards simplicity, this is the tradeoff they decided to make. Even at the cost of more users.
It's pretty counter to Microsoft's incredible investment in backwards compatibility. Or Linus' "don't break user land" philosophy.
I'd think if we had a spectrum of backwards compatibility, with the most being on the right it might look something like this:
OpenBSD ---> macOS/iOS ---> Linux ---> Microsoft
I think in the OpenBSD case, due to limited developer resources, and a cultural bias towards simplicity, this is the tradeoff they decided to make. Even at the cost of more users.
Linux has terrible backwards compatibility, a fact well known to anyone who runs Linux on Parallels without wanting to pay the yearly tax.
macOS deprecated a lot of kernel APIs from Catalina to Big Sur, but there were tons that were around for a decade before.
macOS deprecated a lot of kernel APIs from Catalina to Big Sur, but there were tons that were around for a decade before.
>and a cultural bias towards simplicity, this is the tradeoff they decided to make
Literally the only point of an operating system is to be a stable API for other people to write software on top of. If you're not doing that, then why make an OS?
Literally the only point of an operating system is to be a stable API for other people to write software on top of. If you're not doing that, then why make an OS?
If that were the only point to an operating system, why doesn't Windows have a monopoly in all areas of computing?
Surely there are other considerations beyond stability to be had when choosing an operating system?
Surely there are other considerations beyond stability to be had when choosing an operating system?
I don't think people are using PF to write software on top of -- they use OpenBSD specifically to run PF. You should look at upgrading OpenBSD in this use case to upgrading the firewall software.
It's a different case than mere "I compiled this application 6 months ago and I want to run it today", which is the "stable API" part of an OS that you mention.
It's a different case than mere "I compiled this application 6 months ago and I want to run it today", which is the "stable API" part of an OS that you mention.
Since the BSD's are not meant to run proprietary binary's on top, just recompile your code and everything is fine.
Linus want's that the OracleDB's of the World can run on his system...that's is fine i think ;)
Linus want's that the OracleDB's of the World can run on his system...that's is fine i think ;)
Of course Linux's ipfw has remained entirely consistent for its entire lifetime.
Excuse me, I meant ipchains.
Oh, silly me, iptables.
Excuse me, I meant ipchains.
Oh, silly me, iptables.
One thing I find appealing about OpenBSD is the simplicity. There are almost no daemons running on a default install. There's a greater sense of being able to figure out how the whole thing works compared to, obviously, Linux.
Not just simplicity but consistency also.
The file system layout, configuration file syntax, and man pages are just far more coherent. Using Linux a lot then trying OpenBSD, after getting familiar with the general layout, it's clear OpenBSD is more rigorous with where files go and the system as a whole.
I had some trouble setting up a network connection with my ISP. My ISP does not share technical connection details favouring you just plug in their provided router. Never doing Kernel dev or C before, I was able to go into the OpenBSD kernel code, spot the logline I was seeing in the logs, see why my config was failing by checking the logic and fix my config. This was only just after trying OpenBSD for the first time and being extremely unfamiliar.
The sad thing is outside of my router, I've not found an opportunity to run OpenBSD. On servers, I mainly use NixOs for declarative setup. Also, with Docker being ubiquitous today, I need to be able to run containers natively serverside.
The same for the desktop, if I switch from OSX to OpenBSD, I'm making a few sacrifices with not much advantage as a desktop user, but if I switched to Linux, at least I'd get native Docker support to compensate for some of the things I'd lose not using OSX anymore.
The file system layout, configuration file syntax, and man pages are just far more coherent. Using Linux a lot then trying OpenBSD, after getting familiar with the general layout, it's clear OpenBSD is more rigorous with where files go and the system as a whole.
I had some trouble setting up a network connection with my ISP. My ISP does not share technical connection details favouring you just plug in their provided router. Never doing Kernel dev or C before, I was able to go into the OpenBSD kernel code, spot the logline I was seeing in the logs, see why my config was failing by checking the logic and fix my config. This was only just after trying OpenBSD for the first time and being extremely unfamiliar.
The sad thing is outside of my router, I've not found an opportunity to run OpenBSD. On servers, I mainly use NixOs for declarative setup. Also, with Docker being ubiquitous today, I need to be able to run containers natively serverside.
The same for the desktop, if I switch from OSX to OpenBSD, I'm making a few sacrifices with not much advantage as a desktop user, but if I switched to Linux, at least I'd get native Docker support to compensate for some of the things I'd lose not using OSX anymore.
Depends on the Linux; Alpine is pretty close to that, Ubuntu isn't.
The big one remaining on Alpine is udevd. It's been on linux forever, but still feels to me like something that should just be part of the kernel.
In my opinion the dream is to have a system with literally just a kernel running, ready for user interaction.
In my opinion the dream is to have a system with literally just a kernel running, ready for user interaction.
It used to be part of the kernel back in the day. It was called devfs. It was dropped because a userkspace implementaton is more flexible and easier to extend and tweak. udev also isn't the only choice, mdev also exists and works without running an actual daemon (there is a file in /sys or /proc which specifies a program to run on hardware events, mdev handles the event, then quits).
Of course, nowadays devtmpfs is also a thing, fully kernel space, but not at all configurable. Mostly meant for early user space like initrd and such. But if you don't need anything special it might work for you during regular use, too.
Of course, nowadays devtmpfs is also a thing, fully kernel space, but not at all configurable. Mostly meant for early user space like initrd and such. But if you don't need anything special it might work for you during regular use, too.
We seem to have very different definitions of simplicity. I don't consider even more loaded kernel than Linux currently is simple.
I like the idea of OpenBSD. However I have been burned many times over the years as they have decided repeatedly that it is okay to make breaking changes to PF’s rule syntax. This means if you’ve installed a dozen PF firewalls for customers, you get to go around reconfiguring all of them. The nature of these types of fixes is particularly problematic and often requires on-site work where out-of-band access is not available.
It also means innumerable copies of “The Book of PF” mentioned are now paperweights, along with hundreds of articles. Readers of such articles get to play a game of “guess whether the advice in this article works or breaks PF”.
I have many problems with Microsoft, but their support for backward compatibility is something they’ve gotten right. I am hesitant to criticize volunteer programmers, but they should take a page from Microsoft’s playbook here.
I no longer use PF because I can’t worry that any day they’ll roll out yet another update that breaks my configurations.