What every IT person needs to know about OpenBSD Part 1: How it all started

‘Functional, free and secure by default’, OpenBSD remains a crucial yet largely unacknowledged player in the open-source field.

This series aims to highlight the project’s signature security features and development practices — razor-sharp focus on correct and secure code coupled with continuing code audit — as well as the project’s role as a source of innovation in security practices and an ‘upstream’ source for numerous widely-used components such as OpenSSH, PF, LibreSSL and others. This post will focus on the history, Part 2 will focus on usage and user experience, and Part 3 will look at that packet filter.

 

Note: If you are more of a slides person you will be happy to hear that indeed the presentation I used for this when given as a talk is available with the main highlights and little to no geek jokes.

Now with that out of the way, let’s step back to where it all started.

OpenBSD: How it all started

OpenBSD’s history is, to a large extent, the history of the Internet itself. You may have heard of the time back in the 1980s when the likes of IBM and Digital were slugging it out in the corporate IT sphere and the US Department of Defense paid for experiments in distributed, device-independent networking.

That’s when a loosely organized group of hackers somewhat coordinated by researchers at the University of California’s Berkeley campus rose to prominence with BSD Unix, which by a sequence of happy accidents, became the home of the reference implementation of the TCP/IP Internet protocols.

By the early 1990s, commercialization of the Internet had started, and the Berkeley Computer Science Research Group (CSRG) that had coordinated the efforts was set to be disbanded. In addition to the net itself, the main tangible product out of Berkeley was the Berkeley Software Distribution (BSD), often distributed on tapes in the mail but also available on the net, which had started as a collection of software for AT&T’s Unix but had over the years been extended to become a full-featured Unix operating system.

Several different groups wanted BSD to go on even if the CSRG did not, and several things happened in fairly rapid succession:

• Lynne and Bill Jolitz ported BSD to Intel x86 (actually 80386sx), creating 386BSD. This was chronicled in a series of articles in Dr Dobbs’ Journal.
• Next up, hackers started sharing improvements to the 386BSD code as ‘patchkits’, and two separate groups took the work further to form their projects: The FreeBSD group would be working on bringing the best possible BSD to PC-style hardware, while the NetBSD group’s ambition was to make BSD run on any hardware they could get their hands on [see edit at the end of the article).
• A group of former CSRG employees formed BSDi Inc. and marketed their product BSD/386 with, among other things, a contact phone number ‘1-800-ITS-UNIX’. The activities of an actual corporation, in turn, triggered a lawsuit from the owners of the UNIX trademark over code copyrights.

The lawsuit was eventually settled — only six files of several thousand in the tree were ‘potentially encumbered’ and had to be replaced, leaving both NetBSD and FreeBSD with a rush to replace the code. If I remember correctly, this was at least, in part, fairly central to the virtual memory subsystem.

OpenBSD came into existence a couple of years later, from a fork of the NetBSD code base in October 1995, with the initial release in July 1996.

From the very start, the OpenBSD project has been running a code audit of the entire tree, focusing on code correctness and security. We want secure, correct code that makes up a usable system with sane defaults and complete and readable documentation. And we want that code to be available under a free license and available to the world as soon as it is committed to the project’s version control.

One of the early achievements of the OpenBSD project was anonymous CVS, which makes it possible for anyone on the Internet to get the code with changes in near real-time. This was a major break with the normal practice of most projects of the time, which would typically work in relative isolation on private mailing lists, and at quasi-random intervals issue a release as a tarball on an FTP server somewhere.

You are already an OpenBSD user!

It is probably useful at this point to reveal that even if you do not know it, you are more likely than not using code with an OpenBSD origin right now. Your Apple product, be it an iPad, iPhone or Mac, your Android device, your Cisco router, Solaris, Linux or other Unix or even your Microsoft product has some or a lot of OpenBSD originated code in it. We will get back some detail on that later.

OpenBSD: Code audit and security evolution

The code audit activity runs roughly like this:

• Read the code, understand what it does.
• Look for unsafe behaviours, assume a hostile environment.
• When you find a bug and fix it, look for similar code elsewhere in the tree and fix it everywhere.

You will be amazed how much different programmers think alike and make the same mistakes. Wash, rinse, and repeat.

That may sound somewhat unexciting, but careful study of how the code performs in real-life situations led to several innovations over the years, with a strong slant for being proactively secure, making it harder for bugs to do damage:

• W^X — memory can be writeable XOR executable.
• Address space randomization (ASLR) so the jump targets and gaps will vary for each execution.
• Random-sized gaps were inserted in the stack, again catching fixed-sized returns.
• Unreadable, unwriteable guard pages at the end of malloc()ed chunks to catch overruns.
• Privilege separation — daemons run the bulk of their code as a non-privileged user, more likely than not in a shell-less chroot, coupled with privilege revocation, which means that daemons drop privilege as soon as possible.
• The pledge(2) system call to declare a profile to restrict program behaviour to only specified operations and resources.
• The unveil(2) system call to restrict file system access to specified paths and permissions only.
• A fairly user-visible change came when OpenBSD 6.2 introduced the kernel address randomized link, or KARL, which sees to it that the kernel is relinked to a new, randomized layout for each boot. Once again, introducing randomness where none had been before is seen as a way to mitigate possible exploits based on code loading at predictable addresses.

All of those features have been integrated into the OpenBSD source tree, and with the developers admonished to adhere to the rule ‘where it is possible to spot damage, fail hard’, poorly written software will crash a lot more often on OpenBSD than elsewhere. That in itself should make the platform attractive to developers. Exposing your code to a hostile environment and see it perform or fail can be quite entertaining and enlightening.

Usable, portable and secure

To complete the picture, it is useful to keep in mind that OpenBSD runs on a total of 14 platforms. All platforms are self-hosting. Cross-compiling is only used in the early phase of porting to a new platform.

And, of course, in addition to purely maintaining existing code to run on diverse platforms, users and developers have real-world needs that are addressed by developing new software, extending the features of existing programs, adding new functionality or even replacing programs or entire subsystems.

Security is a many-faceted topic. Early on, OpenBSD stood out as the system that included real crypto in the base system, to the extent that exporting OpenBSD source code from the US was technically illegal under its munitions export restrictions as they were defined at the time.

Fortunately for us, the project was always coordinated from Canada by undisputed project leader Theo de Raadt. There is anecdotal evidence that US-based developers would trek across the border for hackathons with clean slate equipment to install OpenBSD while in Canada and hack — that is, work on the system — and would then legally bring the result back with them.

One early application of crypto in OpenBSD was when a full IPSEC stack was included in the system in 1997. OpenBSD was the first free system to include IPSec by default in its base install.

In a prime example of hacker humour of the time, a t-shirt featuring one of the early appearances of Puffy the blowfish that would become the project mascot touted the Blowfish password hashing algorithm. This remains the default on OpenBSD both with the picture caption ‘So long and thanks for all the passwords’ just below Puffy on the front, along with the full source code of the blowfish function on the back.

The expectation was that the t-shirt would be illegal to re-export from the US.

In addition to attention to security and code-correctness, one other important feature of OpenBSD is attention to intellectual integrity and insisting on clearly worded and unambiguous license to use and modify code and documentation that forms part of the system.

That brings us to why OpenBSD is better for users and developers. I’ll talk about that in Part 2.

Peter N. M. Hansteen is a puffyist, daemon charmer and penguin wrangler.

Adapted from original post which appeared on BSDLY.

Edit 06.11.2021

The original statement in the article that the two groups (NetBSD and FreeBSD) were only vaguely aware of each other in the early days has been disputed by at least one patchkit era participant, Tom Ivar Helbekkmo, who wrote in to say:

“That is not entirely true. When Bill Jolitz didn’t include patches from the Internet community in 386bsd 0.1, and then again not in 0.2, Chris Demetriou took the initiative to fork the project, and call ours NetBSD.”

“It soon became apparent, however, that there were divergent goals for further development. This led to the creation of FreeBSD. So, we had one community that amicably divided itself into two separate groups.”

In my own experience, however, those who joined in the post-patchkit era of both projects frequently seem to be unaware of this aspect of the early days. 

Rate this article

Discuss on Hacker News

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.