OpenBSD: Security Begins with Design

OpenBSD is a free, Unix-like operating system from the BSD family. It originated in 1995 under the leadership of Theo de Raadt as a fork of NetBSD. Its technical roots extend through NetBSD back to 4.4BSD.

The OpenBSD project identifies five areas of focus: portability, standardization, correctness, proactive security, and integrated cryptography. Security is therefore an important part of OpenBSD, but it is not its only goal.

OpenBSD also sees itself as a development platform. The source code is publicly accessible, changes can be traced in the source tree, and the project’s goals include a developer-oriented approach and technical quality in decision-making.

This development approach shapes the finished system. OpenBSD does not consist merely of a kernel around which independently developed components are assembled into a distribution. The kernel, system programs, libraries, configuration, and documentation are developed as an integrated system.

An Operating System as an Integrated System

In OpenBSD, the boundary between the operating system itself and additionally installed software is important. The project develops and releases an integrated Base System. In addition to the kernel, this includes system programs, libraries, daemons, configuration files, and the associated documentation.

The Base System includes, for example, the ksh(1) shell, tools from the Unix environment, and system services such as httpd(8), smtpd(8), and ntpd(8).

During installation, the Base System is divided into several release sets. These sets make it possible to select specific components. However, they are not software packages in the sense of a package manager; they remain part of the released OpenBSD system.

Separate from this is additional software from third-party projects. OpenBSD provides the Ports Collection and binary packages built from it. A port describes how software can be built and packaged for OpenBSD; a package is the resulting installable binary package. Software installed with pkg_add does not thereby become part of the Base System.

This boundary also determines who develops and maintains the code and which part of an installed system statements about OpenBSD apply to. In particular, the Base System’s audit and development process must not be applied wholesale to additionally installed software.

We encounter this distinction again in system maintenance: the Base System and packages have different maintenance and update paths. We will examine how these work in practice in detail later.

For now, the basic model is sufficient:

OpenBSD
│
├── Base System
│   ├── Kernel
│   ├── System programs and daemons
│   ├── Libraries
│   ├── Configuration
│   └── Documentation
│
└── Additional software
    ├── Ports
    └── Packages

A statement about a property of the OpenBSD Base System therefore does not automatically apply to additionally installed software.

How OpenBSD Is Developed

Developing the system as a whole makes changes across component boundaries possible. If a technical change affects multiple parts of the Base System, they can be adapted together.

Among the project’s stated goals are making technical decisions based on their quality and not leaving known serious problems unresolved. Correctness plays a central role in this. A bug does not first have to become known as an exploitable security vulnerability before it makes sense to investigate and fix it.

Code audits are part of this work. They are not only about finding already known security vulnerabilities. Source code is also examined for programming errors, problematic assumptions, and recurring error patterns. When such a pattern is identified, the consequences can extend beyond correcting a single instance.

OpenBSD’s development history repeatedly shows how more general solutions can emerge from specific problems. Functions have been replaced by interfaces that are harder to misuse, implementations have been reworked, and additional protection mechanisms have been developed.

This can be described as a recurring pattern:

Observe problem
        ↓
Fix specific bug
        ↓
Identify recurring pattern
        ↓
Develop more general solution
        ↓
Adapt existing code

Not every problem goes through this entire chain, and not every change arises this way. The pattern does, however, explain some of the mechanisms that today extend far beyond fixing individual historical bugs.

Changes can also affect existing interfaces and configurations. Throughout OpenBSD’s development history, older compatibility mechanisms have been removed and existing components replaced. Such changes are documented in the notes for the respective release or upgrade and must be taken into account when moving between versions.

Releases and Continuous Development

OpenBSD regularly publishes new releases. Ongoing development takes place in -current. The individual releases emerge from it, each representing a defined state of the system.

After a release, bugs or security issues may become known for which the project provides errata and patches. Fixes for supported releases are also incorporated into the respective -stable branch.

A new release may also require changes to programs, interfaces, configuration formats, or other parts of the system. The project publishes upgrade notes documenting relevant changes and required adjustments.

Development, release, and maintenance therefore form an ongoing cycle:

              -current
                  ↓
               Release
                  │
          ┌───────┴────────┐
          │                │
    Errata/Patches      -stable
          │                │
          └───────┬────────┘
                  ↓
            next release

Which releases are currently supported and which changes must be considered between two specific versions depend on the respective version state. In these fundamentals, we therefore address version-dependent statements specifically where they become relevant to installation, configuration, or operation.

Correctness, Security, and Limitation

Even careful development and repeated code audits cannot guarantee that a system is free of bugs. OpenBSD therefore attempts not only to eliminate known problems, but also to limit the prerequisites and possible consequences of future bugs.

Two complementary approaches are behind this: bugs should be found and fixed as early as possible. At the same time, the system assumes that unknown bugs may nevertheless remain.

This leads to an important question:

What is a program allowed to do at all if a bug in it is exploited?

A network service, for example, does not need all the privileges with which it was started throughout its entire lifetime. A process may need access to only a small part of the file system. A program requires only a limited subset of the functions offered by the operating system for its task.

OpenBSD addresses these boundaries at different levels. Privilege Separation divides tasks so that the entire service does not have to operate with the same extensive privileges. Privileges can be dropped when they are no longer needed. pledge(2) allows a process to limit the system operations it still requires, while unveil(2) can limit its view of or access to parts of the file system.

Other mechanisms address the conditions required for exploitation. W^X restricts the conditions under which memory may be writable and executable at the same time. ASLR changes the arrangement of memory regions between program executions.

These mechanisms do not eliminate the original programming error. They change the conditions under which it can be exploited or limit the capabilities available afterward.

None of these mechanisms by itself means that a program is “secure.” chroot(2) is not a complete sandbox, W^X does not prevent every form of unwanted code execution, ASLR does not render memory errors harmless, and neither pledge(2) nor unveil(2) replaces correct program code.

Their effects operate at different levels:

Avoid bugs wherever possible
        │
        ├── Correct code
        ├── Code audits
        └── Eliminate problematic patterns
        │
        ▼
Account for remaining bugs
        │
        ├── Limit privileges
        ├── Limit system operations
        ├── Limit file system access
        └── Make exploitation more difficult
        │
        ▼
Limit possible impact

These levels do not replace one another. Additional protection mechanisms do not make correct code less important; carefully audited code does not make additional limitations unnecessary.

Secure by Default

With “Secure by Default,” OpenBSD aims to provide the most secure possible starting point in its default configuration. Non-essential services are disabled by default and can be enabled by the administrator when needed.

Several states must be distinguished:

Is a feature present?
        ↓
Is it enabled?
        ↓
Is an associated service running?
        ↓
Is it listening on a network socket?
        ↓
Through which address is it reachable?

A service present in the Base System is not automatically started; a running service is not necessarily reachable from outside. “Secure by Default” therefore cannot be reduced to a list of disabled services.

Which services actually run after a particular installation and which addresses they listen on also depend on the version and installation. Such observations must be verified for the respective state and are not suitable as timeless rules about OpenBSD.

Proactive Security

Proactive security does not begin only with a published vulnerability and does not end with its patch.

If a more general class of errors can be identified from a specific bug, the question becomes whether the system can be changed so that similar bugs can be avoided in the future, made harder to exploit, or limited in their impact. This can lead to new interfaces, changed implementations, or additional protection mechanisms.

Many mechanisms visible today are therefore part of an ongoing process:

Observe bugs, fix bugs, identify patterns, and develop ways to prevent the same kind of problem earlier in the future or limit its impact.

This does not make OpenBSD free of bugs. Security remains an ongoing technical task.

Freedom, Portability, and Hardware

Portability is one of OpenBSD’s explicitly stated areas of focus. The project aims to keep the source code as independent of individual machine architectures as possible and to support as many systems and hardware platforms as practical.

Technical information about devices is highly important for developing hardware support. OpenBSD rejects nondisclosure agreements (NDAs) as a basis for development. If publicly available documentation is lacking, driver development can become more difficult; reverse engineering can then be one way to obtain the required information.

In addition to technical information, other factors play a role:

Hardware support
        │
        ├── Technical information
        ├── Existing driver work
        ├── Access to hardware
        ├── Required firmware
        └── Development resources

Free Source Code as a Basis for Development

OpenBSD aims to make its source code available in a way that allows it to be examined, modified, and used for different purposes. The project prefers permissive licenses such as the ISC and BSD licenses.

OpenBSD also incorporates code from other projects when its license is compatible with the project’s requirements. The Base System therefore does not consist exclusively of code originally written within the OpenBSD project.

What matters is the conditions under which code can be incorporated into, maintained as part of, and redistributed with the jointly developed system.

Firmware Is a Separate Case

Many hardware devices require firmware that is loaded onto the device during operation. For OpenBSD, a distinction must be made based on whether the license terms permit the firmware to be distributed together with the operating system.

Firmware with licensing terms acceptable to OpenBSD can already be provided with the system. For firmware that cannot be freely distributed with OpenBSD, there is fw_update(8). The tool can install required firmware from the designated firmware infrastructure.

Firmware support and free redistribution are therefore separate questions: a device can be supported by an OpenBSD driver and still require additional firmware that cannot be freely distributed with OpenBSD.

Portability Means More Than Many Architectures

Support for different hardware is the visible side of portability. Behind it is the goal of developing as much code as possible in a machine-independent manner and handling architecture-specific differences where necessary.

Portability is therefore not merely the number of platforms on which a particular release runs, but also a development goal. Which platforms a particular OpenBSD version supports can change; the specific list therefore belongs to the respective version state.

Documentation and Working with OpenBSD

The most important technical reference for OpenBSD is the man pages. Their sources are maintained in the OpenBSD source tree together with the system. They document programs, system calls, library functions, file formats, configuration files, device drivers, and other parts of the system.

An installation includes the man pages corresponding to the respective release. They can also be viewed online.

In addition to descriptions, many man pages contain file paths, configuration examples, and references to related parts of the system. Their SEE ALSO sections lead to further relevant references.

Program, file, or interface
        │
        ▼
     Man page
        │
        ├── Description
        ├── Options / Interfaces
        ├── Files
        ├── Examples
        └── SEE ALSO
                │
                ▼
        Further man pages

For larger topics and workflows, the project provides supplementary documentation, particularly the OpenBSD FAQ. The source tree itself is also a source of information about the implementation and development of individual features.

The man pages and these fundamentals serve different purposes. The man pages provide the technical reference for the system. The fundamentals establish relationships between components and concepts and place technical decisions in context.

The fundamentals explain relationships; the man pages provide the technical reference.

Understanding OpenBSD Before We Configure It

OpenBSD therefore cannot be reduced to a “particularly secure BSD.” Portability, standards, correctness, proactive security, and cryptography come together with a development approach in which the operating system is regarded and developed as an integrated system.

This perspective will accompany us throughout the remaining fundamentals. In installation, user management, networking, services, package management, and system maintenance, we repeatedly encounter the same questions: What belongs to the Base System? What comes from third-party projects? What capabilities does a service require? Which documentation describes the respective component?

Other operating systems make their own technical and organizational decisions. They do not have to serve as a counterexample in order to explain OpenBSD. Comparisons can make differences visible, but they do not replace examining a system on its own terms.

For the following chapters, a working model is therefore sufficient for now:

OpenBSD is not a finished set of security features, but an integrated system under continuous development. We therefore consider not only what a feature does, but also what problem it is intended to solve and the context in which it belongs.

Information Used

This discussion is based on:

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

Further articles in this series cover installation, system configuration, and security fundamentals in practical use.