openbsd: secure by default

Correction: ASLR was not innovated by OpenBSD, the Linux PaX project published the first design and implementation of ASLR in July 2001 as a patch for the Linux kernel. ASLR was then added to OpenBSD 3.4 in 2003 followed by Linux in 2005.
–Unix Sheikh

Continuing with the theme of my last post regarding the impetus of the OpenBSD project, and the principles by which development of the operating system adheres, I felt compelled to enumerate some of the tangible benefits that such a system produces. The principled purist within me notwithstanding, for what reason do I not only choose to use but advocate for OpenBSD when there are so many viable alternatives? What are the benefits? Candidly, there are plenty. Beyond the intangible, esoteric, and ideological, there are myriad reasons that could incentivise installing and running OpenBSD; if not as a daily driver—a firewall, router, {file, media, web} server or other specific use case. Chief among them: security. Security is all but a buzzword of late, and much of the Twittersphere and cyberspace certainly pay it a lot of lip service; and yet, if there's a choice between secure and inconvenient or insecure and {convenient, pretty, familiar, quick, cheap, etc.}, insecure code almost always prevails. And that's by conscious choice–there's a great deal more that isn't even known about and seldom sought out. This is where OpenBSD stands apart: code is specifically audited for bugs; mitigations are researched and developed; and changes are made, irrespective of the cost (e.g., time, breaking legacy compatibility, loss of options), to improve the security of the system. Put plainly, OpenBSD is uncompromising in their pursuit of being "NUMBER ONE in the industry for security." As an example of some of the tangible, real world benefits of this concerted approach, you don't need to scour the history books. In the last twelve months, as a pseudorandom selection, OpenBSD has protected users from:

• Fallout
• Zombieload
• RIDL
• Vim exploit
• SACK kernel vulnerabilities
• ptrace local root exploit
• Linux elf tables integer overflow local root exploit
• Linux VMA cache overflow remote root exploit

To highlight the proactiveness of OpenBSD, the first three exploits listed were all related to the Intel feature bug of simultaneous multi-threading exploited in the Spectre-class of attacks, including Meltdown, that wreaked havoc in early 2018, and which OpenBSD developers disabled, citing potential for further attack vectors. Less than twelve months later, they were proven right. OpenBSD has a track record of making the right call, taking the hard road, and producing the more robust, dependable product. Prior to the global calamity that was Heartbleed in 2014, the project had made plans to fork the OpenSSL mess codebase to produce a cleaner and more secure web crypto stack with LibreSSL; the motivations and early days of development you can read or hear directly from the developers. Unfortunately, it wasn't quite soon enough to protect OpenBSD users from Heartbleed but there was a patch released within a couple days and, in all fairness, the entire world was vulnerable. Interestingly, though, OpenBSD actually had countermeasures in place—specifically, malloc's junk fill, and guard pages—but OpenSSL shipped with "exploit mitigation countermeasures", if you can believe it! Nonetheless, OpenBSD has since provided the world with yet another secure, robust utility of ubiquitous use, the other being OpenSSH, but there are many, many more, albeit of either less universality or less of a critical component to the overall infrastructure of the connected space perhaps. Nonetheless, their contributions comprise a veritable litany of useful applications and implementations, some of which are tmux, pf, CARP, OpenBGPD, OpenIKED, OpenNTPD, OpenSMTPD, mandoc(1), IPsec, privilege separation, W^X, ASLR, and so on. It really is an impressive list of innovations that the project has freely contributed to the world and which you'll find are integral components to critical infrastructure that provides immeasurable value the world over.

As an operating system, though, the project's commitment to clean code provides a secure installation by default without sacrificing usability or even compromising performance. The base system comes with httpd, which is a minimal, fast, securely chrooted, and exceedingly simple web server. A Let's Encrypt client to secure your site with a free HTTPS certificate which, from config to request to installation, is done with the press of less than a few dozen keys. And a graphical desktop environment that starts with a few keystrokes. Even the install procedure itself is so efficient that it can be done by pressing return a few times. The whole system is streamlined with the end user in mind. And because OpenBSD developers, as the expression goes, eat their own dog food, it's secure by default. No fuss, no cruft, no fluff. As the inimitable Nassim Nicholas Taleb avers, "[t]hings designed by people without skin in the game tend to grow in complication (before their final collapse)," and according to Michael W. Lucas, "the OpenBSD Community are masters of reducing complexity." Two astute observations. And in the current climate of insecurity where privacy is eroded with every app downloaded from the App Store, and ransomware is the cyber criminal's attack du jour, at least having your network protected by the most secure operating system available is a valid insurance policy; the fact that's it's simple to operate, reliable, and performant makes it an equally valid daily driver. The singular focus on security and correctness manifests in many mitigations and controls visible to the user—without being obstacles to the user. Features like KARL, arc4random(3), anti-ROP, doas(1), kernel and userland page map table separation, pledge(2), unveil(2), MAC address randomisation, privilege separation, securelevel(7), encrypted swap space, xenodm…the list continues, provide protections that are either not offered elsewhere, or not enabled by default. And I think this is due to the developers having skin in the game, which affords them a perspicacity that has produced an antifragile development environment where real world use produces real world solutions to real world problems. As Donald Knuth says, "the designer of a new system must not only be the implementor and the first large-scale user; the designer should also write the first user manual."

I quoted Taleb earlier and will conclude with another insight that supports this view:

People have two brains, one when there is skin in the game, one when there is none. Skin in the game can make boring things less boring. When you have skin in the game, dull things like checking the safety of the aircraft because you may be forced to be a passenger in it cease to be boring. If you are an investor in a company, doing ultra-boring things like reading the footnotes of a financial statement (where the real information is to be found) becomes, well, almost not boring.

And eating your own dog food when you produce crap, makes you awfully loathe to produce crap.