OpenBSD: Sicherheit beginnt im Design

OpenBSD ist ein freies, Unix-artiges Betriebssystem aus der BSD-Familie. Es entstand 1995 unter der Leitung von Theo de Raadt als Abspaltung von NetBSD. Seine technischen Wurzeln reichen über NetBSD bis zu 4.4BSD zurück.

Das OpenBSD-Projekt nennt fünf Schwerpunkte seiner Arbeit: Portabilität, Standardisierung, Korrektheit, proaktive Sicherheit und integrierte Kryptographie. Sicherheit ist damit ein wichtiger Teil von OpenBSD, aber nicht das einzige Ziel.

OpenBSD versteht sich zugleich als Entwicklungsplattform. Der Quellcode ist öffentlich zugänglich, Änderungen lassen sich im Source Tree nachvollziehen, und zu den Projektzielen gehören eine entwicklerorientierte Arbeitsweise und technische Qualität bei Entscheidungen.

Diese Entwicklungsweise prägt das fertige System. OpenBSD besteht nicht lediglich aus einem Kernel, um den unabhängig entwickelte Komponenten zu einer Distribution zusammengestellt werden. Kernel, Systemprogramme, Bibliotheken, Konfiguration und Dokumentation werden als zusammengehöriges System entwickelt.

Ein Betriebssystem als gemeinsames System

Bei OpenBSD ist die Grenze zwischen dem Betriebssystem selbst und zusätzlich installierter Software wichtig. Das Projekt entwickelt und veröffentlicht ein zusammengehöriges Base System. Dazu gehören neben dem Kernel unter anderem Systemprogramme, Bibliotheken, Daemons, Konfigurationsdateien und die zugehörige Dokumentation.

Zum Base System gehören beispielsweise die Shell ksh(1), Werkzeuge der Unix-Umgebung und Systemdienste wie httpd(8), smtpd(8) oder ntpd(8).

Bei der Installation wird das Base System in mehrere Release Sets aufgeteilt. Diese Sets ermöglichen es, bestimmte Bestandteile auszuwählen. Sie sind jedoch keine Softwarepakete im Sinne eines Paketmanagers, sondern gehören weiterhin zum veröffentlichten OpenBSD-System.

Davon getrennt ist zusätzliche Software aus Drittprojekten. OpenBSD stellt dafür die Ports Collection und daraus erzeugte Binärpakete bereit. Ein Port beschreibt, wie Software für OpenBSD gebaut und paketiert werden kann; ein Package ist das daraus entstandene installierbare Binärpaket. Mit pkg_add installierte Software wird dadurch nicht Bestandteil des Base Systems.

Diese Grenze bestimmt auch, wer den Code entwickelt und pflegt und auf welchen Teil eines installierten Systems sich Aussagen über OpenBSD beziehen. Insbesondere darf der Audit- und Entwicklungsprozess des Base Systems nicht pauschal auf zusätzlich installierte Software übertragen werden.

Auch bei der Systempflege begegnet uns diese Trennung wieder: Base System und Packages besitzen unterschiedliche Pflege- und Aktualisierungswege. Wie diese praktisch funktionieren, betrachten wir später ausführlich.

Für den Moment genügt das grundlegende Modell:

OpenBSD
│
├── Base System
│   ├── Kernel
│   ├── Systemprogramme und Daemons
│   ├── Bibliotheken
│   ├── Konfiguration
│   └── Dokumentation
│
└── zusätzliche Software
    ├── Ports
    └── Packages

Eine Aussage über eine Eigenschaft des OpenBSD Base Systems gilt damit nicht automatisch auch für zusätzlich installierte Software.

Wie OpenBSD entwickelt wird

Das gemeinsam entwickelte System ermöglicht Änderungen über die Grenzen einzelner Komponenten hinweg. Betrifft eine technische Änderung mehrere Teile des Base Systems, können diese gemeinsam angepasst werden.

Zu den erklärten Projektzielen gehört, technische Entscheidungen nach ihrer Qualität zu treffen und bekannte ernsthafte Probleme nicht ungelöst liegen zu lassen. Dabei spielt Korrektheit eine zentrale Rolle. Ein Fehler muss nicht erst als ausnutzbare Sicherheitslücke bekannt sein, damit es sinnvoll ist, ihn zu untersuchen und zu beheben.

Code-Audits sind ein Teil dieser Arbeit. Dabei geht es nicht nur darum, bereits bekannte Sicherheitslücken zu finden. Quellcode wird auch auf Programmierfehler, problematische Annahmen und wiederkehrende Fehlermuster untersucht. Wird ein solches Muster erkannt, kann die Konsequenz über die Korrektur einer einzelnen Stelle hinausgehen.

Die Entwicklungsgeschichte von OpenBSD zeigt immer wieder, wie aus konkreten Problemen allgemeinere Lösungen entstehen können. Funktionen wurden durch Schnittstellen ersetzt, die sich weniger leicht falsch verwenden lassen, Implementierungen wurden überarbeitet und zusätzliche Schutzmechanismen entwickelt.

Das lässt sich als wiederkehrendes Muster beschreiben:

Problem beobachten
        ↓
konkreten Fehler beheben
        ↓
wiederkehrendes Muster erkennen
        ↓
allgemeinere Lösung entwickeln
        ↓
bestehenden Code anpassen

Nicht jedes Problem durchläuft diese gesamte Kette, und nicht jede Änderung entsteht auf diese Weise. Das Muster erklärt jedoch einen Teil der Mechanismen, die heute weit über die Behebung einzelner historischer Fehler hinausgehen.

Veränderungen können dabei auch bestehende Schnittstellen und Konfigurationen betreffen. In der Entwicklungsgeschichte von OpenBSD wurden ältere Kompatibilitätsmechanismen entfernt und vorhandene Komponenten ersetzt. Solche Änderungen werden in den Hinweisen zum jeweiligen Release beziehungsweise Upgrade dokumentiert und müssen bei einem Versionswechsel berücksichtigt werden.

Releases und kontinuierliche Entwicklung

OpenBSD veröffentlicht regelmäßig neue Releases. Die fortlaufende Entwicklung findet in -current statt. Daraus entstehen die einzelnen Releases, die jeweils einen definierten Stand des Systems bilden.

Nach der Veröffentlichung können Fehler oder Sicherheitsprobleme bekannt werden, für die das Projekt Errata und Patches bereitstellt. Korrekturen für unterstützte Releases werden außerdem in den jeweiligen -stable-Branch übernommen.

Mit einem neuen Release können zugleich Änderungen an Programmen, Schnittstellen, Konfigurationsformaten oder anderen Teilen des Systems notwendig werden. Das Projekt veröffentlicht dafür Upgrade-Hinweise, in denen relevante Änderungen und erforderliche Anpassungen beschrieben werden.

Damit gehören Entwicklung, Release und Pflege zu einem fortlaufenden Zyklus:

              -current
                  ↓
               Release
                  │
          ┌───────┴────────┐
          │                │
    Errata/Patches      -stable
          │                │
          └───────┬────────┘
                  ↓
          nächstes Release

Welche Releases aktuell unterstützt werden und welche Änderungen zwischen zwei konkreten Versionen zu beachten sind, gehört zum jeweiligen Versionsstand. In diesen Grundlagen betrachten wir deshalb versionsabhängige Aussagen dort konkret, wo sie für Installation, Konfiguration oder Betrieb relevant werden.

Korrektheit, Sicherheit und Begrenzung

Auch sorgfältige Entwicklung und wiederholte Code-Audits können nicht garantieren, dass ein System frei von Fehlern ist. OpenBSD versucht deshalb nicht nur, bekannte Probleme zu beseitigen, sondern auch die Voraussetzungen und möglichen Folgen zukünftiger Fehler zu begrenzen.

Dahinter stehen zwei Ansätze, die sich ergänzen: Fehler sollen möglichst früh gefunden und behoben werden. Gleichzeitig wird damit gerechnet, dass trotzdem unbekannte Fehler im System verbleiben können.

Daraus ergibt sich eine wichtige Frage:

Was darf ein Programm überhaupt tun, wenn darin ein Fehler ausgenutzt wird?

Ein Netzwerkdienst benötigt beispielsweise nicht während seiner gesamten Laufzeit sämtliche Privilegien, mit denen er gestartet wurde. Ein Prozess muss möglicherweise nur auf einen kleinen Teil des Dateisystems zugreifen. Ein Programm benötigt für seine Aufgabe nur einen begrenzten Ausschnitt der vom Betriebssystem angebotenen Funktionen.

OpenBSD setzt an diesen Grenzen auf unterschiedlichen Ebenen an. Privilege Separation teilt Aufgaben so auf, dass nicht der gesamte Dienst mit denselben weitreichenden Privilegien arbeiten muss. Privilegien können abgegeben werden, wenn sie nicht mehr benötigt werden. pledge(2) ermöglicht einem Prozess, die noch benötigten Systemoperationen zu begrenzen, während unveil(2) seine Sicht auf beziehungsweise seinen Zugriff auf Teile des Dateisystems begrenzen kann.

Andere Mechanismen setzen bei den Bedingungen für eine Ausnutzung an. W^X beschränkt, unter welchen Bedingungen Speicher gleichzeitig beschreibbar und ausführbar sein darf. ASLR verändert die Anordnung von Speicherbereichen zwischen Programmausführungen.

Diese Mechanismen beseitigen den ursprünglichen Programmierfehler nicht. Sie verändern die Bedingungen, unter denen er ausgenutzt werden kann, oder begrenzen die Möglichkeiten, die anschließend zur Verfügung stehen.

Keiner dieser Mechanismen bedeutet für sich genommen, dass ein Programm „sicher“ ist. chroot(2) ist keine vollständige Sandbox, W^X verhindert nicht jede Form unerwünschter Codeausführung, ASLR macht Speicherfehler nicht unschädlich und auch pledge(2) oder unveil(2) ersetzen keinen korrekten Programmcode.

Ihre Wirkung setzt auf unterschiedlichen Ebenen an:

Fehler möglichst vermeiden
        │
        ├── korrekter Code
        ├── Code-Audits
        └── problematische Muster beseitigen
        │
        ▼
mit verbleibenden Fehlern rechnen
        │
        ├── Privilegien begrenzen
        ├── Systemoperationen begrenzen
        ├── Dateisystemzugriff begrenzen
        └── Ausnutzung erschweren
        │
        ▼
mögliche Auswirkungen begrenzen

Diese Ebenen ersetzen einander nicht. Zusätzliche Schutzmechanismen machen korrekten Code nicht weniger wichtig; sorgfältig geprüfter Code macht zusätzliche Begrenzungen nicht überflüssig.

Secure by Default

Mit „Secure by Default“ verfolgt OpenBSD das Ziel, bereits in der Standardkonfiguration einen möglichst sicheren Ausgangszustand bereitzustellen. Nicht essenzielle Dienste sind standardmäßig deaktiviert und können vom Administrator bei Bedarf aktiviert werden.

Dabei müssen mehrere Zustände auseinandergehalten werden:

Ist eine Funktion vorhanden?
        ↓
Ist sie aktiviert?
        ↓
Läuft ein zugehöriger Dienst?
        ↓
Lauscht er auf einem Netzwerk-Socket?
        ↓
Über welche Adresse ist er erreichbar?

Ein im Base System vorhandener Dienst ist nicht automatisch gestartet; ein gestarteter Dienst ist nicht zwangsläufig von außen erreichbar. „Secure by Default“ lässt sich deshalb nicht auf eine Liste deaktivierter Dienste reduzieren.

Welche Dienste nach einer konkreten Installation tatsächlich laufen und auf welchen Adressen sie lauschen, hängt zudem von Version und Installation ab. Solche Beobachtungen müssen für den jeweiligen Stand geprüft werden und eignen sich nicht als zeitlose Regeln über OpenBSD.

Proaktive Sicherheit

Proaktive Sicherheit beginnt nicht erst mit einer veröffentlichten Schwachstelle und endet nicht mit deren Patch.

Lässt sich aus einem konkreten Fehler eine allgemeinere Fehlerklasse erkennen, stellt sich die Frage, ob sich das System so verändern lässt, dass ähnliche Fehler künftig vermieden, schwerer auszunutzen oder in ihren Auswirkungen begrenzt werden können. Daraus können neue Schnittstellen, veränderte Implementierungen oder zusätzliche Schutzmechanismen entstehen.

Viele heute sichtbare Mechanismen stehen damit in einem fortlaufenden Prozess:

Fehler beobachten, Fehler beheben, Muster erkennen und Möglichkeiten entwickeln, dieselbe Art von Problem künftig früher zu verhindern oder ihre Auswirkungen zu begrenzen.

Das macht OpenBSD nicht fehlerfrei. Sicherheit bleibt eine fortlaufende technische Aufgabe.

Freiheit, Portabilität und Hardware

Portabilität gehört zu den ausdrücklich genannten Schwerpunkten von OpenBSD. Das Projekt verfolgt das Ziel, den Quellcode möglichst unabhängig von einzelnen Maschinenarchitekturen zu halten und möglichst viele Systeme und Hardwareplattformen zu unterstützen, soweit dies praktikabel ist.

Für die Entwicklung von Hardwareunterstützung sind technische Informationen über die Geräte von großer Bedeutung. OpenBSD lehnt Geheimhaltungsvereinbarungen (NDAs) als Grundlage der Entwicklung ab. Fehlt öffentlich zugängliche Dokumentation, kann dies die Entwicklung von Treibern erschweren; Reverse Engineering kann dann eine Möglichkeit sein, benötigte Informationen zu gewinnen.

Neben technischen Informationen spielen weitere Faktoren eine Rolle:

Hardwareunterstützung
        │
        ├── technische Informationen
        ├── vorhandene Treiberarbeit
        ├── Zugang zu Hardware
        ├── benötigte Firmware
        └── Entwicklungsressourcen

Freier Quellcode als Entwicklungsgrundlage

OpenBSD möchte seinen Quellcode so verfügbar machen, dass er betrachtet, verändert und für unterschiedliche Zwecke verwendet werden kann. Das Projekt bevorzugt permissive Lizenzen wie ISC- und BSD-Lizenzen.

OpenBSD übernimmt auch Code aus anderen Projekten, sofern dessen Lizenz mit den Anforderungen des Projekts vereinbar ist. Das Base System besteht deshalb nicht ausschließlich aus Code, der ursprünglich innerhalb des OpenBSD-Projekts geschrieben wurde.

Entscheidend ist, unter welchen Bedingungen Code in das gemeinsam entwickelte System aufgenommen, gepflegt und weitergegeben werden kann.

Firmware ist ein eigener Fall

Viele Hardwaregeräte benötigen Firmware, die beim Betrieb auf das Gerät geladen wird. Für OpenBSD ist dabei zu unterscheiden, ob die Lizenzbedingungen eine Verteilung der Firmware zusammen mit dem Betriebssystem erlauben.

Firmware mit für OpenBSD akzeptablen Lizenzbedingungen kann bereits mit dem System bereitgestellt werden. Für Firmware, die nicht frei mit OpenBSD verteilt werden darf, gibt es fw_update(8). Das Werkzeug kann benötigte Firmware aus der dafür vorgesehenen Firmware-Infrastruktur installieren.

Firmware-Unterstützung und freie Verteilbarkeit sind damit unterschiedliche Fragen: Ein Gerät kann von einem OpenBSD-Treiber unterstützt werden und trotzdem zusätzliche Firmware benötigen, die nicht frei mit OpenBSD verteilt werden darf.

Portabilität bedeutet mehr als viele Architekturen

Die Unterstützung unterschiedlicher Hardware ist die sichtbare Seite der Portabilität. Dahinter steht das Ziel, möglichst viel Code maschinenunabhängig zu entwickeln und architekturspezifische Unterschiede dort zu behandeln, wo sie notwendig sind.

Portabilität ist damit nicht lediglich die Zahl der Plattformen, auf denen ein bestimmtes Release läuft, sondern zugleich ein Entwicklungsziel. Welche Plattformen eine bestimmte OpenBSD-Version unterstützt, kann sich ändern; die konkrete Liste gehört deshalb zum jeweiligen Versionsstand.

Dokumentation und Arbeiten mit OpenBSD

Die wichtigste technische Referenz für OpenBSD bilden die Manpages. Ihre Quellen werden im OpenBSD Source Tree zusammen mit dem System gepflegt. Sie dokumentieren Programme, Systemaufrufe, Bibliotheksfunktionen, Dateiformate, Konfigurationsdateien, Gerätetreiber und weitere Bestandteile des Systems.

Bei einer Installation stehen die zum jeweiligen Release gehörenden Manpages auf dem System zur Verfügung. Zusätzlich können sie online eingesehen werden.

Viele Manpages enthalten neben der Beschreibung auch Dateipfade, Konfigurationsbeispiele und Verweise auf verwandte Teile des Systems. Über SEE ALSO führen sie zu weiteren relevanten Referenzen.

Programm, Datei oder Schnittstelle
        │
        ▼
     Manpage
        │
        ├── Beschreibung
        ├── Optionen / Schnittstellen
        ├── Dateien
        ├── Beispiele
        └── SEE ALSO
                │
                ▼
        weitere Manpages

Für größere Themen und Arbeitsabläufe stellt das Projekt ergänzende Dokumentation bereit, insbesondere die OpenBSD FAQ. Auch der Source Tree selbst ist eine Informationsquelle für die Implementierung und Entwicklung einzelner Funktionen.

Die Manpages und diese Grundlagen erfüllen unterschiedliche Aufgaben. Die Manpages bilden die technische Referenz für das System. Die Grundlagen stellen Zusammenhänge zwischen Bestandteilen und Konzepten her und ordnen technische Entscheidungen ein.

Die Grundlagen erklären Zusammenhänge, die Manpages liefern die technische Referenz.

OpenBSD verstehen, bevor wir es konfigurieren

OpenBSD lässt sich damit nicht auf ein „besonders sicheres BSD“ reduzieren. Portabilität, Standards, Korrektheit, proaktive Sicherheit und Kryptographie treffen auf eine Entwicklungsweise, bei der das Betriebssystem als zusammengehöriges System betrachtet und weiterentwickelt wird.

Diese Perspektive wird uns durch die weiteren Grundlagen begleiten. Bei Installation, Benutzerverwaltung, Netzwerk, Diensten, Paketverwaltung und Systempflege begegnen uns immer wieder dieselben Fragen: Was gehört zum Base System? Was stammt aus Drittprojekten? Welche Möglichkeiten benötigt ein Dienst? Welche Dokumentation beschreibt den jeweiligen Bestandteil?

Andere Betriebssysteme treffen eigene technische und organisatorische Entscheidungen. Sie müssen nicht als Gegenmodell dienen, um OpenBSD zu erklären. Vergleiche können Unterschiede sichtbar machen; sie ersetzen aber nicht die Betrachtung eines Systems auf seinen eigenen Grundlagen.

Für die folgenden Kapitel genügt deshalb zunächst ein Arbeitsmodell:

OpenBSD ist kein fertiger Satz von Sicherheitsfunktionen, sondern ein fortlaufend entwickeltes Gesamtsystem. Wir betrachten deshalb nicht nur, was eine Funktion tut, sondern auch, welches Problem sie lösen soll und in welchen Zusammenhang sie gehört.

Verwendete Informationen

Diese Betrachtung bezieht sich auf:

• OpenBSD: 7.8, 7.9
• Projekt: openbsd.org (offizielles Projekt)
• Kontext: Server- und Desktop-System
• Stand: August 2026

Weiterführende Artikel dieser Serie behandeln Installation, Systemkonfiguration und Sicherheitsgrundlagen im praktischen Einsatz.