OpenBSD and the Broader Problem of Platform Security

OpenBSD helped establish that an operating system should assume software contains vulnerabilities and should limit the damage when those vulnerabilities are exploited. That argument has been substantially accepted. Exploit mitigations, privilege separation, and reducing unnecessary authority are now ordinary concerns in platform security.

My criticism is that OpenBSD has not adopted several platform boundaries now present elsewhere, particularly around boot integrity, application identity, and workload isolation. OpenBSD continues to do valuable security engineering, but the range of threats it addresses has become narrow relative to the project’s stated ambition to provide the most secure operating system. OpenBSD project goals

For much of the late 1990s and 2000s, the project was known for treating exploit resistance as an operating-system responsibility. It audited the base system, removed privileges from network daemons, improved unsafe interfaces, deployed mitigations broadly, and accepted compatibility costs in doing so. OpenBSD did not invent every technique associated with that period. Its contribution was often to recognize a useful idea early, integrate it throughout the system, and make it a default rather than an optional hardening exercise. Its own history records work on W^X, address-space randomization, privilege separation, safer libc interfaces, RETGUARD, pledge, unveil, and restrictions on executable memory and syscall entry. OpenBSD innovations

The wider adoption of these ideas vindicates the approach, although it does not establish that every other implementation descended from OpenBSD. The practical consequence is more important than assigning credit: a hardened Unix process is no longer an unusual security property. OpenBSD’s relative position now depends on what it provides beyond that shared foundation.

The threat model expanded

Exploit resistance addresses what happens when a program fails. Platform security also has to address programs that behave maliciously by design, privileged attackers seeking persistence, mutually untrusted workloads, and software attempting to use resources the user never intended to grant it.

Android illustrates this expansion. Its application identities and SELinux policy provide boundaries that do not depend solely on traditional Unix ownership, and SELinux constrains userspace processes even when they run with root privileges. Verified Boot establishes an authentication chain from a hardware-protected root of trust through the bootloader and verified system partitions, with rollback protection intended to prevent a vulnerable older system from becoming a persistence mechanism. These properties depend on the device’s boot and policy configuration, but they are part of the platform’s design. Android SELinux, Android Verified Boot

macOS provides a different example. Its Signed System Volume authenticates system contents using a hash tree and signed seal; on Apple silicon, the bootloader checks the seal before transferring control to the kernel. Separating that system content from mutable data makes it possible to check the installed operating system against an authorized deployment. The protection is scoped to the sealed system and its boot policy, rather than promising that every file or every running process is trustworthy. Apple Signed System Volume security

These mechanisms supplement process hardening. They address different failures: modifying the installed system, running intentionally hostile software, or crossing a boundary between workloads. Their existence does not prove that Android or macOS is safer for every use case. It does show why a comparison based mainly on memory-corruption defenses leaves out a large part of contemporary operating-system security.

OpenBSD still develops useful defenses

The criticism should not obscure recent work. mimmutable(2), introduced in OpenBSD 7.3, prevents later changes to a mapping or its protections. pinsyscalls(2), introduced in 7.5, tells the kernel the permitted instruction location for each syscall entry in libc, with corresponding setup for the dynamic linker and static executables. These mechanisms reduce the options available to an attacker who can manipulate a process’s control flow or mappings. They are concrete engineering advances. mimmutable manual, pinsyscalls manual

OpenBSD 7.9, released May 19, 2026, continued that work. It removed root’s exemption from BPF descriptor locking, retired the tmppath pledge promise, introduced a tightly constrained libc facility for opening internal files, and restricted timezone-file access from pledged processes. The release notes also list Wayland and several compositors among the available ports, which matters when considering possible foundations for desktop confinement. OpenBSD 7.9

OpenSSH remains another example of substantive work. OpenSSH 10.0 moved authentication handling into sshd-auth, separating its address space from the code used for the remainder of a connection, and made the hybrid post-quantum mlkem768x25519-sha256 key exchange the default. The project’s security work clearly extends beyond maintaining old Unix code. OpenSSH release notes

My concern is the scope of the resulting platform. Much of OpenBSD’s distinctive work still asks how a process can relinquish authority and how a compromised process can be made less useful to an attacker. Those remain important questions, but they do not cover the full threat model implied by the project’s security ambition.

Three gaps in the platform

The first gap is authenticated installed-system integrity. OpenBSD signs releases and updates; 7.9 publishes keys for the base system, firmware, packages, and binary patches. Authenticating an artifact before installation is valuable, but it establishes a different property from authenticating the system contents at boot. The ordinary OpenBSD 7.9 installation uses a mutable Unix filesystem. File flags, read-only mounts, and securelevel can constrain changes, but their enforcement depends on the running kernel and configuration, and they do not supply a cryptographic chain from authorized system contents to the boot decision.

A package signature establishes who authorized the package. A verified system deployment can also establish whether the contents being booted still match an authorized system. The standard OpenBSD 7.9 installation does not provide an equivalent to the end-to-end deployment checks described by Android Verified Boot or Apple’s SSV. This is a specific missing property, rather than a claim that OpenBSD has no integrity controls.

The desired invariant is straightforward: protected base-system contents should match an authenticated deployment. Implementing that invariant would still require difficult decisions about key management, boot integration, updates, recovery, and the boundary between the base system and mutable configuration. Calling the invariant simple is not a reason to pretend that the implementation would be free. It is a reason to evaluate whether the property deserves that work.

The second gap is a general facility for isolating workloads within one kernel. OpenBSD has chroot, privilege separation, pledge, unveil, routing domains, and virtual machines. It does not provide a direct counterpart to FreeBSD jails or the collection of Linux mechanisms used to construct containers. FreeBSD has provided jails since the FreeBSD 4 era; its current facilities include private process and filesystem environments, restrictions on jailed root, and optional independent network stacks. The exact protection depends on configuration, and the host kernel remains shared. FreeBSD jails handbook

That distinction matters because restricting a process’s operations and isolating its environment answer different questions. pledge can prevent a process from invoking operations outside its declared needs. unveil can restrict its filesystem view. Neither alone provides the complete environment and administrative boundary of a jail. Conversely, a jail can still contain a vulnerable daemon that benefits from pledge and unveil.

For example, consider two mutually untrusted services that each need to read a configuration file, accept connections, and manage a small set of child processes. Restricting their system calls can reduce what an exploit accomplishes, and restricting their filesystem views can keep their files separate. A workload boundary asks additional questions: which processes can each service see or signal, which network environment does it inhabit, what authority does its administrator retain, and which devices are visible? The answer requires a specified collection of boundaries. A single restriction cannot be credited with properties outside its scope.

The third gap is a general application-security architecture. OpenBSD’s browsers are useful counterexamples to the claim that GUI applications receive no confinement. Firefox and Chromium use OpenBSD’s sandboxing facilities. Firefox port documentation, Chromium port documentation The broader omission is a platform policy that gives applications identities, derives permissions from those identities, and mediates access to user resources through narrow interfaces.

unveil provides filesystem confinement and can deny access even after a process is compromised. It is therefore more than a request that software behave itself. Likewise, pledge restrictions can survive into executed programs under the configured execpromises. The limitation is that these primitives do not, by themselves, supply an application platform for permissions, trusted file-selection brokers, cameras, microphones, secrets, IPC, and other resources. A launcher or application-specific integration can construct part of such a boundary, but the user does not receive a general policy simply by installing arbitrary software. unveil manual, pledge manual

Minimalism is a design constraint, not a complete answer

OpenBSD has a reasonable objection to complex security machinery. Effective Linux container permissions can depend on namespaces, capabilities, seccomp, mandatory policy, cgroups, mount configuration, and runtime choices. A short pledge declaration is often easier to inspect than the interaction of all those mechanisms.

However, OpenBSD undertakes difficult kernel, compiler, linker, and libc work when it values the resulting property. RETGUARD, randomized kernel relinking, execute-only mappings, immutable mappings, and pinned syscall entry points all required substantial engineering. The project’s preference is therefore for particular security abstractions, rather than a general refusal to implement anything complicated.

FreeBSD jails show that workload isolation need not reproduce the entire Linux container stack. Apple’s sealed system shows that authenticated deployment need not expose a large policy language to ordinary users. Android combines application identity, mandatory policy, verified boot, and exploit mitigations. Each design has costs and limitations, but those costs should be assessed against the property it adds.

OpenBSD may reasonably reject a particular implementation because its boundary is weak, its interface is difficult to audit, or its maintenance cost is too high. The underlying requirement still deserves an answer. A process mitigation cannot establish boot integrity, and a verified boot cannot contain an application that has been granted excessive authority.

What a broader model could look like

OpenBSD would not need to reproduce another operating system to address these gaps. A native workload-isolation facility could expose a smaller interface than the Linux container stack and still provide useful process, filesystem, device, and network boundaries. pledge and unveil could remain valuable inside it.

An authenticated base-system deployment could distinguish protected system contents from mutable configuration and data. Updates could install and verify a complete generation, with a defined recovery path when verification or boot fails. Existing signing infrastructure would contribute to the trust chain, but carrying that trust into the installed system and boot process would be new work.

Desktop confinement could use unveil, Wayland, and trusted brokers as components of a policy around application identity. The important addition would be a system-mediated decision about what resources an application receives, rather than requiring every program to construct an adequate policy for itself.

These are design directions, not finished specifications. A serious implementation would have to show that the added boundary justifies its complexity and attack surface. The useful evaluation would identify the protection gained, the paths that remain exposed, and the maintenance burden introduced. That is consistent with OpenBSD’s engineering standards.

OpenBSD still has a legitimate place as a carefully engineered, security-conscious Unix, with valuable networking software, exploit mitigations, APIs, and a commitment to removing unnecessary privilege. Its influence is real. But influence from past successes and leadership in present platform security are different achievements.

Other platforms have applied the same reasoning to more of the system: installed contents, boot decisions, application permissions, workload boundaries, and hardware-backed trust. OpenBSD’s strongest work remains concentrated on a smaller portion of that problem.

If the project intends to pursue its ambition of leading operating-system security, it needs to examine that larger threat model with the same willingness to change defaults that made its earlier work effective. Otherwise it can remain an excellent traditional Unix while offering fewer of the boundaries now available elsewhere. That is a coherent future, but it is a narrower one than the project’s stated goal.