OpenBSD: Security Through Simplicity and System Design

A Philosophy of Security and Simplicity

OpenBSD adheres closely to the Unix philosophy, producing a system that is straightforward to install and configure without compromising security. Its secure-by-default policy leaves nonessential services disabled. This "less is more" approach asks administrators to enable only what they need, reducing both remotely reachable code and opportunities for misconfiguration.

Simplicity is a security property in this design: fewer mechanisms, dependencies, and compatibility paths leave less behavior to understand, test, and audit. OpenBSD omits features or replaces a component when that choice leaves a clearer, more maintainable system.

OpenBSD configuration files use compact, readable syntax, and the manual pages document each option in detail. Missing or incorrect documentation is a defect because administrators cannot secure behavior they cannot identify and configure correctly.

Proactive Defenses and Exploit Mitigations

OpenBSD combines that restraint with proactive defenses. The project's audit process repeatedly examines critical components for ordinary correctness bugs, including bugs whose exploitability is not yet known. It also develops mitigations that limit what a successful memory-corruption bug can achieve. These layers include:

• W^X policy: OpenBSD strictly enforces the rule that writable memory must not also be executable. Exceptions for programs that require writable executable mappings must be explicit in both the executable and the filesystem mount policy.
• Stack protections and SROP mitigations: Stack protections detect corruption, while SROP defenses restrict forged signal-return state. Both remove routes from a memory-corruption bug to control-flow hijacking.
• bcrypt(3) for passwords: The Blowfish-based password hash has a configurable work factor, making offline password guessing deliberately expensive without relying on a fast general-purpose hash.
• Application sandboxing: pledge(2) restricts which classes of system operations a process may request, while unveil(2) restricts which filesystem paths it can see. Applying both to base programs limits the damage available after a compromise.

OpenBSD layers these mitigations with narrow privileges, conservative defaults, and code review. Each layer removes an exploit path or limits the authority available after another layer fails.

Secure Defaults and Tooling in Practice

OpenBSD's security posture is not limited to exploit mitigations. It also emphasizes secure defaults, small auditable utilities, and tight integration between the kernel and base userland. These choices reduce reachable code and administrative complexity before any post-install hardening.

Several mechanisms and base tools commonly cited in security discussions are:

• KARL (Kernel Address Randomized Link): After each boot, reorder_kernel(8) relinks the kernel's object files in randomized order for the next boot. This changes internal code, data, and gadget locations rather than only the kernel's load address.
• Boot-time relinking of core libraries: OpenBSD randomizes the object order of key shared libraries at boot, reducing predictability for attacks that depend on fixed offsets.
• arc4random(3) and getentropy(2): These interfaces provide random data without requiring each caller to manage a pseudorandom generator and are used consistently across the base system.
• signify(1): A simple signing and verification tool used for release artifacts and binary patches, reinforcing integrity checks as part of normal administration.
• doas(1): A compact privilege-escalation tool designed to be easy to audit and easy to configure for common administrative workflows.
• pf(4) and privilege separation: The stateful packet filter complements a long-standing practice of splitting daemons into processes with narrowly assigned privileges, limiting the authority retained after one process is compromised.

Continuous auditing and precise manual pages make security-relevant behavior inspectable: configuration is explicit, defaults are intentional, and administration relies on documented primitives instead of opaque layers.

security(8) and Daily System Checks

OpenBSD includes security(8), a script run by daily(8) that looks for signs of common security weaknesses and mails any output to root. Among other things, it checks account databases, home directories and dotfile permissions, changes to files listed in /etc/changelist, mounted-disk labels and partition tables, package changes, and selected network configuration permissions.

The manual deliberately describes it as a security aid rather than complete protection. Its value lies in making obvious weaknesses and unexpected system changes visible, provided an administrator reviews the daily reports and maintains the files being monitored.

Hardening Beyond the Obvious: Randomization and Memory Safety

Beyond well-known mitigations, OpenBSD has long invested in techniques that make exploitation less reliable by reducing predictability in both userland and kernel space. These measures are most effective in combination: even when attackers gain partial information, each added layer raises the cost of building a reliable exploit chain.

• Address-space and layout randomization: Multiple layers of randomization are used to make code- and data-targeting techniques less repeatable across reboots and across machines.
• Kernel randomization (KARL): Each relinked kernel has a different internal object layout, denying exploits the stable relative offsets of one fixed kernel build.
• PID randomization: Process identifiers can be less predictable, reducing the value of attacks that rely on guessing process IDs.
• Safer libc primitives: Functions such as freezero(3) and recallocarray(3) are designed to help developers and system components handle sensitive data and allocation patterns more safely.
• Allocator hardening and diagnostics: OpenBSD's malloc implementation combines exploit resistance with diagnostics that expose classes of memory errors during development and debugging.

OpenBSD exposes runtime controls through documented interfaces, principally sysctls and configuration files. The active policy remains inspectable instead of being hidden in implicit state.

Control of the Base System and Its Implementations

OpenBSD develops the kernel and base userland in one source tree. This unified tree carries a new kernel restriction into system utilities, a privilege-separation refactoring into a daemon, and the matching changes into its configuration and manual. Administrators receive a coherent base rather than a collection of independently assembled upstream components.

The project also maintains an unusual amount of commonly used software itself. OpenBSD chooses among writing, importing, forking, and substantially adapting a component according to interface clarity, maintenance burden, integration, and license suitability. The project's own list of software and ideas shows the extent of this work.

The security value comes from the design method: remove unnecessary behavior, keep critical code within the project's review process, and apply the same defensive primitives consistently. Size contributes only when the resulting component remains correct, maintained, and suitable for the job.

OpenBSD developer Ted Unangst has described this practice as an attempt to reduce future bugs and maintenance problems, not as a way to erase known bugs by rewriting code. A rewrite discards obscure lessons unless its developers recover them. Its advantage must therefore come from a deliberately narrower scope and from code the project expects to understand and maintain over time.

Purpose-Built and Maintained Components

These examples distinguish the engineering reasons for controlling an implementation without turning the base system into an indiscriminate catalog of OpenBSD projects:

• httpd(8): OpenBSD replaced nginx in base after local hardening patches, a growing codebase, custom allocators, and duplicated library routines made integration and review difficult. The replacement concentrates on static files, FastCGI, and TLS, and runs chrooted with privilege separation. Its value is not size alone, but that it uses OpenBSD's libc defenses and common daemon architecture directly.
• doas(1): Its compact permit/deny grammar matches an identity, target user, command, and exact arguments, while the program constructs a controlled environment by default. This keeps privilege policy explicit and reviewable; it does not make a careless rule safe.
• signify(1): This compact tool addresses release and package signature verification with a narrow command-line interface and a deliberately limited role, avoiding the need to place a general-purpose OpenPGP implementation in base.
• OpenSMTPD: Its lean scope is reinforced by process-level compartmentalization and external extension APIs. Optional dependencies remain outside the daemon core and its address space.
• LibreSSL: OpenBSD forked OpenSSL in 2014 and set out to modernize the code, make it easier to audit and repair, and remove obsolete or broken features and platform support. These maintainability goals reduce the code and compatibility paths that require security review.
• OpenSSH: OpenBSD maintains this widely deployed remote-access suite and used it to introduce privilege separation. Ports of OpenSSH carry that base-system engineering to other platforms.

init(8) and rcctl(8): Explicit Service Control

OpenBSD keeps the layers of system startup distinct. The small init(8) process enters multi-user mode, manages terminal logins, and handles the transition to shutdown or single-user mode. It invokes the documented rc(8) startup script, which performs system housekeeping and starts the daemons selected through rc.conf(8). Individual rc.d(8) scripts provide a common start, stop, reload, restart, check, and configuration-test interface.

rcctl(8) is not an init system or a resident service supervisor. It is a small front end that records local choices in /etc/rc.conf.local and invokes those existing rc.d(8) controls. An administrator can explicitly enable a daemon, set its arguments, user, login class, routing table, working directory, logging, or timeout, test its configuration, and list enabled-but-failed or disabled-but-running services.

Daemon enablement is represented explicitly in configuration, site overrides remain in one upgrade-safe text file, and a daemon's configured identity and resource class are easy to inspect. During startup, rc(8) also follows a visible sequence that includes setting the kernel securelevel and randomized relinking. The small control plane adds little hidden state and exposes unnecessary or misconfigured services to direct inspection.

cron(8): Explicit, Checked Scheduling

Not every component maintained by OpenBSD was written from scratch. Its cron(8) descends from Paul Vixie's implementation, but OpenBSD keeps an integrated version in the base system. Keeping it in base lets OpenBSD audit and adapt suitable imported code instead of replacing it merely for the sake of novelty.

The scheduler treats its inputs as privileged configuration. It ignores user crontabs unless their mode is 0600, and /etc/crontab must not be writable by anyone except root or carry execute, set-ID, or sticky bits. The crontab(1) utility's cron.allow and cron.deny files control who may install user crontabs, and access fails closed if they cannot be read. In the maintained daemon source, pledge(2) restricts the scheduler's permitted operations. The job setup code establishes the owner's login class and credentials and checks account approval before executing the command.

OpenBSD's crontab(5) format adds focused operational controls rather than a separate scheduling framework. A ~ range chooses a stable random offset when the table is loaded to spread simultaneous starts, while -s prevents overlapping instances of the same entry. These two controls reduce load spikes, races, and accidental concurrent access to shared state. They do not sandbox the scheduled command: a job intentionally runs with its owner's authority and must still be secured like any other command.

smtpd(8): Privilege Separation as Architecture

OpenSMTPD was written as an ISC-licensed SMTP implementation after its developers were dissatisfied with the available alternatives. Its published goals join three requirements: strict validation and privilege separation, reliable handling of every accepted message, and a lean implementation aimed at common rather than obscure use cases. A readable configuration language is part of those goals because an MTA that is easy to misconfigure is not operationally secure.

The difference is architectural. In a developer presentation, OpenSMTPD is described as a set of processes with well-defined tasks rather than one daemon in which every subsystem has every privilege. Workers communicate through imsg(3) instead of shared memory; privileged work is concentrated in the parent, most other processes are unprivileged and chrooted, and the queue uses a separate account. pledge(2) restricts each worker's allowed operations, while re-execution gives child processes memory layouts independent of the initial parent.

OpenSMTPD does not have to absorb every database or directory client into that trusted core. The current smtpd-tables(7) API runs lookup backends as standalone processes outside smtpd(8)'s address space and allows them to use separately configured accounts. This is how minimalism and extensibility reinforce each other: site-specific dependencies remain available without giving them the daemon's full privileges or making them part of its memory-safety boundary.

OpenSMTPD's own security advisory history includes serious flaws, including bugs fixed in 2020 that led to command execution. Process boundaries do not erase those bugs; they limit the authority assigned to each exposed role. The defensible advantage is this explicit, reviewable division of responsibility.

vmm(4)/vmd(8): A Narrow Hypervisor

OpenBSD's native virtualization stack separates the vmm(4) in-kernel virtual machine monitor, the vmd(8) userland daemon, and the vmctl(8) control client. Device emulation therefore remains primarily in userland instead of placing network- and disk-device parsers in the host kernel. vmd(8) also starts a separate VM process for each guest.

Emulated devices consume attacker-controlled guest data and have repeatedly enabled escapes in hypervisors. An OpenBSD developer's analysis of vmd(8) describes its fork-and-exec privilege separation, dedicated process roles, reduced user and group IDs, filesystem isolation, and pledge(2) restrictions. OpenBSD 7.4 then introduced a multiprocess model for emulated VirtIO block and network devices. Separating those devices gives an attacker who compromises one emulator another process boundary to cross before reaching the rest of vmd(8) or other device code.

The virtualization FAQ also documents a deliberately limited feature set: no graphics, snapshots, hardware passthrough, cross-host live migration, live hardware changes, or guest SMP. Fewer emulation and migration paths mean less code and state to maintain. The FAQ does not identify security as the motive for every omission. The host trust boundary still includes vmm(4), vmd(8), and the kernel; an exploitable bug in those components can cause a VM escape. The smaller, OpenBSD-integrated design applies compartmentalization to the host side of virtualization.

openrsync(1): Compatibility Without Importing rsync

openrsync is a clean-room, ISC-licensed implementation of rsync written by Kristaps Dzonsons. It began as part of rpki-client(8), which had to retrieve RPKI repository data using the rsync protocol, and was imported into OpenBSD in 2019. The result gave the base system an implementation under its preferred license and direct project control; it was not merely a renamed copy of upstream rsync.

Compatibility is deliberately narrower than a full rsync replacement. The current manual defines its supported option set, local and remote synchronization, and interoperability through rsync protocol version 27. OpenBSD also supplies rsync(5) and rsyncd(5) protocol documentation, making the wire formats explicit enough to review and implement independently. Workflows that require newer protocols or unsupported options still need upstream rsync.

On OpenBSD, sandboxing limits openrsync's authority. The current main.c uses pledge(2) to limit system operations and tightens the promises after network setup. On the receiving side, receiver.c applies unveil(2) around the source paths and destination root. In server mode, server.c seeds the protocol's MD4 hashes with arc4random(3) rather than the time of day.

A narrower interface leaves less behavior to understand, protocol documentation supports review and maintenance, and sandboxing limits what a bug can reach. The available evidence does not establish that openrsync has fewer vulnerabilities than rsync. Its ordinary client and server roles are not a separate privilege-separation design.

Auditing, Secure Coding, and Documentation

OpenBSD describes its audit process as a file-by-file examination of critical software. The reviewers look for ordinary bugs rather than waiting for a proven exploit, and revisit previously audited code when a new class of flaw becomes understood. This avoids treating vulnerability reports as the only source of security work.

The same approach governs programming interfaces such as reallocarray(3), recallocarray(3), freezero(3), and explicit_bzero(3). These APIs make integer-overflow checks or reliable clearing of sensitive memory easier to express. They do not make C memory-safe, but they turn common defensive patterns into reviewed system primitives.

Precise manual pages complete the model. An implementation that is difficult to describe is also difficult to operate and audit. Treating inaccurate documentation as a defect keeps security-relevant behavior visible to developers and administrators instead of hiding it behind convention.

Conclusions

OpenBSD reduces what must be trusted, makes the remaining behavior understandable, audits it repeatedly, and contains failures with layered defenses. Its own implementations, including httpd's direct use of the system's defenses, OpenSMTPD's divided process architecture, vmm/vmd's host-side compartmentalization, the explicit init/rc control plane, and openrsync's focused compatibility target, show that this philosophy is reflected in substantial parts of the base system, not added afterward as a set of optional hardening switches.