OpenBSD gilt als eines der sichersten Betriebssysteme der Welt. Es entstand aus der Überzeugung, dass Sicherheit nicht nachträglich hinzugefügt, sondern von Beginn an in das Design integriert werden muss.
Nach der Installation startet OpenBSD mit zwei aktiven Netzwerkdiensten: SSH und cron. Alle anderen Services bleiben deaktiviert. Diese bewusste Reduktion auf das Notwendige bildet den Kern der „secure by default“-Philosophie – Angriffsflächen entstehen nur dort, wo der Administrator sie ausdrücklich schafft.
Das Projekt führt seit 1996 kontinuierliche Security-Audits durch. Entwickler prüfen den gesamten Source-Code systematisch auf Sicherheitsprobleme, beheben diese präventiv und dokumentieren die Änderungen transparent. Über 25 Jahre ergaben sich daraus Technologien wie OpenSSH, LibreSSL und der Randomisierungsmechanismus arc4random – heute Standard in vielen Unix-Systemen.
Projektgeschichte und Organisation
Theo de Raadt gründete OpenBSD 1995 als Fork von NetBSD. Der Fokus lag von Anfang an auf Korrektheit, Sicherheit und freier Lizenzierung. Das Projekt entwickelt unter der ISC-Lizenz – einer BSD-Variante ohne Werbeklausel und mit minimalen Einschränkungen.
Die Finanzierung erfolgt ausschließlich über Spenden und Hardware-Verkäufe. Das Projekt erhält keine Unternehmensfinanzierung, vermeidet dadurch externe Interessenkonflikte und behält vollständige technische Unabhängigkeit. Release-CDs, USB-Installationsmedien und Merchandise bilden die Haupteinnahmequellen.
Die Entwicklung organisiert sich dezentral über CVS – bis heute. Commits erfolgen direkt in den Main-Branch, jede Änderung durchläuft vorher ein Code-Review durch andere Entwickler. Das System verzichtet bewusst auf komplexe Branching-Strategien und Pull-Request-Workflows.
Release-Modell und Versionierung
OpenBSD veröffentlicht halbjährlich neue Versionen – am 1. Mai und 1. November. Jedes Release erhält 12 Monate Sicherheitsupdates, parallel laufen immer zwei unterstützte Versionen. Version 7.8 erschien am 22. Oktober 2025 als 59. Release des Projekts, Version 7.9 folgt im Mai 2026.
Zwischen den Releases entwickelt das Projekt an -current. Diese Entwicklungsversion aktualisiert sich kontinuierlich und enthält neue Features, Architektur-Änderungen und experimentelle Technologien. Produktive Systeme nutzen die stabilen Releases, Entwickler und Tester arbeiten mit -current.
Die Versionsnummerierung folgt einem einfachen Schema: Hauptversionsnummer und Minor-Release ohne komplexe Benennungen. Version 7.8 ist das achte Release der siebten Generation. Patches erscheinen als Errata-Nummern, ohne die Versionsnummer zu verändern.
Designprinzipien
Secure by Default
Der Installer aktiviert ausschließlich essenzielle Services. SSH läuft für Remote-Administration, cron führt zeitbasierte Aufgaben aus. Webserver, Mail-Transfer-Agent und Datenbanken starten erst nach expliziter Konfiguration durch den Administrator.
Das System setzt konsequent restriktive Dateirechte ein. Konfigurationsdateien in /etc gehören root mit 644-Berechtigungen, sensible Dateien wie /etc/master.passwd erhalten 600. Dienste-Accounts besitzen keine Login-Shell und können sich nicht interaktiv anmelden.
Netzwerk-Services binden standardmäßig an localhost (127.0.0.1). Der Administrator muss explizit externe Interfaces konfigurieren, um Services im Netzwerk erreichbar zu machen. Diese Voreinstellung verhindert versehentliche Exponierung von Diensten.
Code-Audits und Korrektheit
Das Audit-Programm prüft systematisch den Base-System-Code auf Sicherheitslücken. Buffer-Overflows, Race-Conditions, Format-String-Bugs und Privilege-Escalation-Pfade werden identifiziert und behoben – unabhängig von bekannten Exploits.
Entwickler bevorzugen einfachen, lesbaren Code gegenüber komplexen Optimierungen. Funktionen haben klar definierte Aufgaben, Module begrenzen ihre Schnittstellen auf das Notwendige. Komplexität reduziert sich systematisch durch Refactoring und Vereinfachung.
Das Projekt entfernt Legacy-Code konsequent. Veraltete Subsysteme, obsolete Hardware-Treiber und nicht mehr benötigte Features verschwinden aus dem Source-Tree. Diese Reduktion vereinfacht Maintenance und verringert potenzielle Angriffsflächen.
Privilege Separation
Dienste teilen sich in privilegierte und unprivilegierte Prozesse. OpenSSH startet mit einem privilegierten Monitor-Prozess, der Authentifizierung übernimmt, und unprivilegierten Session-Prozessen für die Verbindungsabwicklung. Eine Kompromittierung eines Session-Prozesses gewährt somit keinen Root-Zugriff.
Systemdienste nutzen dedizierte Benutzeraccounts. Der Webserver httpd läuft als _httpd, der Mail-Transfer-Agent smtpd als _smtpd. Diese Accounts besitzen minimale Rechte und können nur auf ihre spezifischen Verzeichnisse zugreifen.
chroot-Umgebungen isolieren Dienste vom Haupt-Dateisystem. Prozesse sehen nur ihr chroot-Verzeichnis als Root und können nicht auf Systemdateien außerhalb zugreifen. Selbst bei erfolgreicher Kompromittierung bleibt der Schaden auf die Sandbox beschränkt.
Proaktive Sicherheitsfeatures
W^X (Write XOR Execute) verhindert gleichzeitig beschreibbare und ausführbare Speicherbereiche. Daten-Segmente können geschrieben, aber nicht ausgeführt werden; Code-Segmente sind ausführbar, aber nicht beschreibbar. Diese Trennung erschwert Code-Injection-Angriffe grundlegend.
ASLR (Address Space Layout Randomization) verschiebt Speicherbereiche bei jedem Programmstart an zufällige Adressen. Stack, Heap und Library-Positionen ändern sich, Return-Oriented-Programming-Exploits verlieren ihre Verlässlichkeit auf feste Adressen.
pledge() schränkt Systemcalls ein. Programme deklarieren benötigte Capabilities explizit – Datei-Zugriff, Netzwerk-Kommunikation, Prozess-Erzeugung. Nach dem pledge()-Aufruf blockiert der Kernel nicht deklarierte Systemcalls; selbst bei erfolgreicher Code-Ausführung bleiben Operationen begrenzt.
unveil() definiert Dateisystem-Sichtbarkeit. Programme geben an, welche Pfade sie benötigen und mit welchen Rechten. Alle anderen Pfade werden unsichtbar, Zugriffe schlagen fehl. Ein kompromittierter Prozess kann nur auf vorher definierte Verzeichnisse zugreifen.
Base-System und Ports
Das Base-System enthält Kernel, Shell (ksh), Standard-Utilities (grep, sed, awk) und System-Dienste (httpd, smtpd, ntpd). Diese Komponenten entwickelt das Projekt selbst, integriert sie eng und wartet sie kontinuierlich. Ein vollständiges OpenBSD-System funktioniert ohne externe Software.
Zusätzliche Anwendungen installieren sich über das Ports-System. Über 11.000 vorkompilierte Pakete stehen bereit – von Datenbanken über Webframeworks bis zu Desktop-Anwendungen. Das System trennt strikt zwischen Base (vom Projekt gepflegt) und Packages (von Port-Maintainern betreut).
Updates unterscheiden sich grundlegend zwischen Base und Ports. Das Base-System aktualisiert sich per syspatch (Sicherheitspatches) oder sysupgrade (komplettes Release-Upgrade). Packages aktualisieren über pkg_add -u. Diese Trennung ermöglicht unabhängige Update-Zyklen.
Lizenzierung und Philosophie
OpenBSD nutzt die ISC-Lizenz für eigenen Code und bevorzugt BSD-ähnliche Lizenzen für integrierte Software. GPL-lizenzierte Komponenten werden minimiert oder durch eigene Implementierungen ersetzt. LibreSSL ersetzte OpenSSL, httpd ersetzte Apache – beide folgen denselben Prinzipien von Einfachheit, Korrektheit und Unabhängigkeit.
Die Projekt-Philosophie priorisiert Korrektheit über Features. Neue Funktionen werden nur integriert, wenn sie sicher implementierbar sind und den Wartungsaufwand nicht überproportional erhöhen. „Features are bugs“ – jede zusätzliche Funktionalität schafft potenzielle Schwachstellen.
Das Projekt lehnt Backwards-Compatibility ab, wenn diese Sicherheit oder Code-Klarheit beeinträchtigt. APIs ändern sich zwischen Releases, veraltete Interfaces verschwinden, Konfigurationsformate werden modernisiert. Stabilität bedeutet hier Sicherheit, nicht API-Konstanz.
Hardware-Unterstützung
OpenBSD läuft auf amd64 (x86_64), arm64, i386, sparc64, powerpc, riscv64, octeon (MIPS), alpha und weiteren Plattformen. Die Entwicklung fokussiert auf amd64 und arm64 als primäre Architekturen, andere Plattformen erhalten Community-Support.
Hardware-Treiber entstehen durch Reverse Engineering ohne Hersteller-NDAs. Das Projekt entwickelt offene Treiber basierend auf öffentlichen Spezifikationen und Hardware-Analyse. Diese Unabhängigkeit erlaubt vollständige Source-Code-Verfügbarkeit ohne rechtliche Einschränkungen.
Firmware-Blobs laden sich bei Bedarf separat über fw_update. Das Base-System enthält keine binären Firmware-Dateien; das Tool lädt diese vom offiziellen Server nach. Der Kernel kann ohne Firmware booten und funktioniert mit freien Treibern.
Community und Ressourcen
Das Projekt kommuniziert über Mailinglisten. misc@openbsd.org behandelt allgemeine Fragen, tech@openbsd.org diskutiert technische Entwicklung, bugs@openbsd.org sammelt Fehlerberichte. Die Archive sind öffentlich und durchsuchbar.
Die man-Pages bilden die primäre Dokumentation. Jedes Programm, jeder Systemcall und jede Konfigurationsdatei besitzt eine ausführliche Manual-Page. man intro gibt einen Überblick, apropos keyword findet relevante Seiten.
Die FAQ (Frequently Asked Questions) auf openbsd.org behandelt Installation, Konfiguration und typische Probleme. Das Dokument wird mit jedem Release aktualisiert und referenziert die aktuelle Version.
Verwendete Informationen
Diese Betrachtung bezieht sich auf:
- OpenBSD: 7.7, 7.8
- Projekt: openbsd.org (offizielles Projekt)
- Kontext: Server- und Desktop-System
- Stand: Oktober 2025
Weiterführende Artikel dieser Serie behandeln Installation, Systemkonfiguration und Sicherheitsgrundlagen im praktischen Einsatz.
