I have been running OpenBSD 2.4 on a spare machine for the last fortnight. This is my first serious time with anything from the BSD family — until now I have been a Slackware/Linux person — and the differences are not the ones I expected.
This is a notebook of those differences, written for someone in my position two weeks ago.
What "secure by default" actually means in practice
OpenBSD's marketing-speak slogan is "secure by default". I had read this before installing and assumed it meant "the firewall is enabled out of the box".
It means more than that. The OpenBSD project has done several specific things which, taken together, produce a meaningfully different threat model:
No services are enabled at install. Out of the box, after installation, the only listening service on the network is sshd. Compare to Slackware, which by default enables FTP, telnet, finger, identd, echo, chargen, and a small zoo of others. The OpenBSD position is that every service is a potential vulnerability, so none are enabled unless you explicitly turn them on.
Source has been audited. Theo de Raadt's team has been going through the system source line-by-line, fixing classes of bug — buffer overflows, format string issues, race conditions — pre-emptively. Many bugs they found were not yet known publicly. The result is that several whole categories of vulnerability simply do not appear in OpenBSD where they appear in other systems.
The default daemons are different. OpenBSD uses BIND with restricted privileges, a stripped-down sendmail, smtpd and so on. These are chosen for security characteristics, not feature richness.
Privilege separation is structural. Many of the daemons that ship with OpenBSD start as root, do the privileged setup (binding to a port, opening a logfile), and then drop into a chroot jail under an unprivileged user for the rest of their life. The kernel cannot stop a daemon from doing this; the daemon's design has been changed to do it.
The thing nobody tells you about
The man pages.
OpenBSD's man pages are written by people who care. They describe how the thing actually works, what the edge cases are, and what the security implications are of each option. Reading the man page for pf or ipsec tells you, with no fluff, what the tool does and why each design decision was made.
Linux man pages are not bad. OpenBSD's are decisively better. After two weeks of reading them I have stopped reaching for HOWTO documents on the web; the man page is shorter, more accurate, and covers the cases the HOWTO does not.
What I miss from Slackware
Three things, in honesty.
One, the package selection. OpenBSD has a ports tree and prebuilt packages, but the catalogue is smaller than what you get from any Linux distribution. If your work depends on some piece of software with no current OpenBSD port, it is going to be your weekend project.
Two, the kernel modularity. The Linux 2.0 and 2.2 kernels can be built with very fine-grained module choices. OpenBSD's kernel is more monolithic, although there is some loadable-module support. For a security-focused box this is mostly fine — fewer modules is fewer attack surface — but if you need a feature, you need to rebuild the kernel.
Three, the install procedure is unforgiving. OpenBSD's installer is text-based, terse, and assumes you know what you are doing. Slackware's setup is also text-based but more conversational. Newcomers will find OpenBSD harsher.
Where it changes my thinking
The most interesting thing OpenBSD has done to me is to make me notice all the places where Slackware ships things on by default "because most people want them". Most people probably do want them, in some sense. Most people also do not want to be running a service they did not realise was listening, taking traffic from the internet, on a port they cannot remember if they looked at recently.
The OpenBSD position — nothing on by default; you turn things on deliberately as you need them — is not a different way of running the same operating system. It is a different relationship between the operator and the machine.
What I am going to do with it
For my main desktop and the box I do most of my Linux experimentation on, I am keeping Slackware. The package range is too important.
For the perimeter — the box that sits between my home network and the modem — I am thinking seriously about putting OpenBSD on it. If you only run a single service on a box and that service is pf (or ipfilter, on this version), you do not need a hundred packages and a flexible kernel. You need a small system that has been thought about hard and ships nothing extra. OpenBSD is that.
The other thing I am taking from this exercise is a discipline rather than a tool. The next time I install Slackware on anything, the first thing I am doing is the OpenBSD-style audit of which services are listening. If I do not need a service, it should be off. If I am not sure whether I need it, it should be off until I am sure.
Which is, I think, the lesson OpenBSD is quietly trying to teach the rest of the community.