OpenBSD: Security Begins with Design

OpenBSD is widely regarded as one of the most secure operating systems in the world. It was created from the conviction that security should not be added afterwards, but designed into the system from the very beginning.

After installation, OpenBSD starts with only two active network services: SSH and cron. Every other service remains disabled. This deliberate reduction to the essentials lies at the heart of the project’s secure-by-default philosophy—attack surfaces exist only where the administrator explicitly creates them.

The project has conducted continuous security audits since 1996. Developers systematically review the entire source tree for security issues, fix potential vulnerabilities before they become exploits, and document every change transparently. More than twenty-five years of this work have produced technologies such as OpenSSH, LibreSSL, and the arc4random random number generator, all of which have become standard components across many Unix systems.

Project History and Organization

Theo de Raadt founded OpenBSD in 1995 as a fork of NetBSD. From the outset, the project focused on correctness, security, and permissive licensing. OpenBSD is developed under the ISC License—a BSD-style license without an advertising clause and with only minimal restrictions.

The project is funded entirely through donations and hardware sales. It receives no corporate funding, avoiding external conflicts of interest while maintaining complete technical independence. Release CDs, USB installation media, and merchandise remain its primary sources of income.

Development is coordinated through CVS—and still is today. Changes are committed directly to the main branch, with every commit reviewed by other developers before it is accepted. The project deliberately avoids complex branching strategies and pull-request-based workflows.

Release Model and Versioning

OpenBSD releases a new version every six months—on May 1 and November 1. Each release receives security updates for twelve months, with two supported releases maintained in parallel at any given time. Version 7.9 was released on May 19, 2026, as the project’s 60th official release.

Between releases, development continues in -current. This development branch is updated continuously and includes new features, architectural changes, and experimental technologies. Production systems typically run the stable releases, while developers and testers work with -current.

Version numbers follow a straightforward scheme consisting of a major version and a minor release number. Version 7.8 is the eighth release of the seventh major version. Security fixes are published as errata without changing the release version itself.

Design Principles

Secure by Default

The installer enables only the essential services. SSH is available for remote administration, while cron handles scheduled tasks. Web servers, mail transfer agents, and databases remain disabled until they are explicitly configured by the administrator.

The system consistently applies restrictive file permissions. Configuration files in /etc are owned by root with permissions set to 644, while sensitive files such as /etc/master.passwd use 600 permissions. Service accounts have no login shell and cannot be used for interactive logins.

By default, network services bind only to localhost (127.0.0.1). To make a service accessible from the network, the administrator must explicitly configure it to listen on external interfaces. This default prevents services from being exposed unintentionally.

Code Audits and Correctness

The audit program systematically examines the base system for security vulnerabilities. Buffer overflows, race conditions, format string vulnerabilities, and privilege escalation paths are identified and eliminated regardless of whether a practical exploit is already known.

Developers favor simple, readable code over complex optimizations. Functions have clearly defined responsibilities, and modules expose only the interfaces they actually require. Complexity is reduced continuously through refactoring and simplification.

The project removes legacy code whenever it is no longer justified. Obsolete subsystems, outdated hardware drivers, and unused features are removed from the source tree. This ongoing reduction simplifies maintenance and decreases the number of potential attack surfaces.

Privilege Separation

Services are divided into privileged and unprivileged processes. OpenSSH, for example, starts with a privileged monitor process responsible for authentication, while unprivileged session processes handle individual client connections. Compromising a session process therefore does not provide root access.

System services run under dedicated user accounts. The httpd web server runs as _httpd, while the smtpd mail transfer agent runs as _smtpd. These accounts have only the permissions required for their specific tasks and are restricted to their designated directories.

chroot environments isolate services from the main filesystem. A process sees only its own chroot directory as the root of the filesystem and cannot access files outside that environment. Even if a service is successfully compromised, the resulting damage remains confined to the sandbox.

Proactive Security Features

W^X (Write XOR Execute) prevents memory pages from being writable and executable at the same time. Data pages can be written but not executed, while code pages can be executed but not modified. This separation fundamentally complicates code injection attacks.

ASLR (Address Space Layout Randomization) places memory regions at different addresses each time a program starts. Stack, heap, and shared library locations change with every execution, making return-oriented programming (ROP) attacks far less reliable.

pledge() restricts the system calls available to a process. Applications explicitly declare the capabilities they require—for example file access, network communication, or process creation. After calling pledge(), the kernel blocks any system call that was not declared, limiting the actions a compromised process can perform.

unveil() restricts filesystem visibility. Applications explicitly define which paths they need and what level of access they require. Every other path becomes invisible, and any attempt to access it fails. Even a compromised process can access only the directories it was allowed to see beforehand.

Base System and Ports

The base system includes the kernel, the Korn shell (ksh), standard utilities such as grep, sed, and awk, as well as core system services including httpd, smtpd, and ntpd. These components are developed, integrated, and maintained by the OpenBSD project itself. A complete OpenBSD installation operates without requiring external software.

Additional software is installed through the Ports collection. More than 11,000 precompiled packages are available, ranging from databases and web frameworks to desktop applications. OpenBSD maintains a strict separation between the base system, which is maintained by the project itself, and packages, which are maintained by the respective port maintainers.

The update mechanisms for the base system and packages are deliberately separate. The base system is updated with syspatch for security fixes or sysupgrade for full release upgrades. Installed packages are updated with pkg_add -u. This separation allows both parts of the system to follow independent update cycles.

Licensing and Philosophy

OpenBSD uses the ISC License for its own code and prefers BSD-style licenses for integrated software. GPL-licensed components are minimized or replaced with project-developed alternatives wherever practical. LibreSSL replaced OpenSSL, and httpd replaced Apache. Both follow the same principles of simplicity, correctness, and independence.

The project’s philosophy places correctness above features. New functionality is integrated only when it can be implemented securely and maintained without creating disproportionate complexity. “Features are bugs.” Every additional feature introduces potential weaknesses.

The project does not preserve backward compatibility when doing so would compromise security or code clarity. APIs may change between releases, obsolete interfaces are removed, and configuration formats are modernized. In this context, stability means security rather than API consistency.

Hardware Support

OpenBSD runs on amd64 (x86_64), arm64, i386, sparc64, powerpc, riscv64, octeon (MIPS), alpha, and several other architectures. Development focuses primarily on amd64 and arm64, while the remaining platforms are maintained with community support.

Hardware drivers are developed through reverse engineering without relying on vendor NDAs. The project creates open drivers based on publicly available specifications and direct hardware analysis. This independence allows the complete source code to remain freely available without legal restrictions.

Firmware blobs are installed separately with fw_update when required. The base system contains no proprietary firmware files; the utility downloads them from the official OpenBSD servers when needed. The kernel can boot without firmware and fully supports hardware that operates with free drivers.

Community and Resources

The project communicates primarily through mailing lists. misc@openbsd.org is used for general questions, tech@openbsd.org discusses technical development, and bugs@openbsd.org collects bug reports. All mailing list archives are public and searchable.

The man pages are the primary source of documentation. Every program, system call, and configuration file has a comprehensive manual page. man intro provides an overview of the documentation, while apropos keyword locates relevant manual pages by topic.

The FAQ (Frequently Asked Questions) on openbsd.org covers installation, configuration, and common operational issues. It is updated with every release and always reflects the current version of the system.

Information Used

This overview is based on:

• OpenBSD: 7.8, 7.9
• Project: openbsd.org (official project)
• Context: Server and desktop systems
• Status: June 2026

The following articles in this series cover installation, system configuration, and the practical security mechanisms that define OpenBSD in day-to-day use.