FreeBSD auf einem Laptop — für viele war das lange Zeit ein Witz. WLAN? Vielleicht. Grafiktreiber? Hoffentlich. Ruhezustand? Nein. Wer FreeBSD auf einem Laptop betreiben wollte, brauchte Geduld, Leidensfähigkeit und idealerweise Hardware, die zufällig kompatibel war.
Das FreeBSD Laptop-Projekt ändert das. Seit seinem Start im vierten Quartal 2024 arbeitet die FreeBSD Foundation systematisch daran, die Lücken zu schließen, die FreeBSD auf moderner Laptop-Hardware von einer frustrierenden Erfahrung zu einem produktiven Erlebnis machen. Mit einem Budget von über 750.000 USD allein für das erste volle Jahr und einem ähnlichen Investment für 2026 ist das kein Nebenprojekt mehr — es ist eine der größten gezielten Investitionen in die Desktop-Relevanz von FreeBSD.
Was 2025 erreicht wurde
Das erste volle Jahr des Projekts brachte messbare Fortschritte in allen Kernbereichen:
WLAN
FreeBSD 15.0 liefert WiFi 4 und WiFi 5 für Intel- und Realtek-Hardware. Der neue iwx(4)-Treiber bietet eine native Alternative zu iwlwifi(4) für neuere Intel-Chipsätze, und rtwn(4) unterstützt jetzt 802.11ac (VHT) für RTL8812A und RTL8821A. Die Arbeit an WiFi 6 läuft.
Grafik
Die Grafiktreiber wurden auf Linux 6.9 aktualisiert und sind in FreeBSD 15.0 verfügbar (über den drm-latest-kmod-Port). Linux 6.10 ist in Arbeit — und das ist die Mindestversion, die für das Framework Laptop 16″ mit AMD Ryzen AI 300 Serie benötigt wird.
Audio
Zwei neue Werkzeuge — sndctl(8) und mididump(1) — sowie Bugfixes und eine verbesserte automatische Sound-Umleitung für HDA-Soundkarten machen die Audioerfahrung auf Laptops spürbar besser.
Installer
FreeBSD 15.0 kann nun Firmware-Pakete direkt nach der Basisinstallation herunterladen. Und für FreeBSD 15.1 steht ein Meilenstein an: KDE Plasma als Installationsoption direkt im Installer. Statt nach der Installation mühsam einen Desktop aufzusetzen, wird man künftig beim Installieren einfach „KDE Desktop“ ankreuzen können.
Ruhezustand
Modern Standby (S0i3) soll in FreeBSD 15.1 verfügbar werden, Hibernate (S4) möglicherweise in 15.2. Für Laptop-Nutzer ist das entscheidend — ohne funktionierenden Schlafmodus ist ein Laptop nicht praktikabel.
Der Fahrplan für 2026
Die Roadmap für das laufende Jahr ist ambitioniert. Laut dem Phoronix-Bericht vom April 2026 arbeiten die Entwickler daran, die Linux-Grafiktreiber von Version 6.13 bis 6.18 LTS zu portieren. Wenn alles nach Plan läuft, könnte FreeBSD Ende 2026 auf dem Stand des aktuellen Linux-Kernels ~6.19 sein.
Besonders wichtig: Intel Xe-Treiber-Unterstützung. Intels neue Grafikarchitektur für Lunar Lake und Battlemage benötigt den Xe-Treiber, der auf FreeBSD noch nicht verfügbar ist. Ohne ihn sind aktuelle Intel-Laptops mit FreeBSD nicht nutzbar.
Weitere Ziele für 2026:
S4 Hibernate — Vollständiger Ruhezustand mit Festplattenverschlüsselung
WiFi 6 — Unterstützung für neuere Realtek- und Mediatek-Adapter
USB4 und Thunderbolt — Für Docking-Stationen und externe GPUs
Der KDE-Desktop-Installer ist der sichtbarste Meilenstein des Laptop-Projekts. Wenn ein neues FreeBSD-System installiert wird, kann man künftig direkt eine grafische Oberfläche mit auswählen — ähnlich wie bei Ubuntu oder Fedora.
Das Test-Setup umfasst bereits Intel- und AMD-Grafik sowie den generischen VESA-Treiber. Ein NVIDIA-Treiber-Auswahlmenü wurde kürzlich zum Installer hinzugefügt, was Desktop-Tests mit NVIDIA-Hardware ermöglicht. VirtualBox- und VMware-Kompatibilität sind als nächste Schritte geplant.
Das ist mehr als eine Bequemlichkeit. Es ist ein Signal: FreeBSD ist nicht mehr nur für Server und Nerd-Laptops. Es will ein Desktop-Betriebssystem sein, das man installieren und nutzen kann, ohne die Kommandozeile zu fürchten.
Unterstützte Hardware
Das Projekt veröffentlicht eine Liste unterstützter Laptops auf GitHub. Sie wächst kontinuierlich, und die Foundation bittet die Community aktiv um Testberichte und Feedback.
Warum das wichtig ist
Man könnte argumentieren, dass FreeBSD ein Server-Betriebssystem ist und Laptop-Unterstützung unnötig. Aber das ignoriert die Realität: Entwickler arbeiten auf Laptops. Administratoren brauchen portable Diagnose-Werkzeuge. Und jedes Betriebssystem, das auf dem Desktop nicht nutzbar ist, verliert Entwickler an die Konkurrenz.
Das Laptop-Projekt ist keine Spielerei. Es ist eine Investition in die Zukunft von FreeBSD als Plattform. Je mehr Menschen FreeBSD auf ihrem Laptop nutzen, desto mehr Entwickler werden es verbessern. Es ist ein positiver Kreislauf, der jetzt in Gang gekommen ist.
Die dritte Release Candidate für FreeBSD 15.1, Kritische x86-Bootloader-Bugs, eine Flut von KI-entdeckten Sicherheitslücken und der Rückblick auf den Frankfurter Hackathon – diese Woche war bei FreeBSD wieder viel geboten.
FreeBSD 15.1-RC3 veröffentlicht – Release verschiebt sich auf Mitte Juni
Das wohl wichtigste Ereignis der Woche: Colin Percival kündigte am 6. Juni FreeBSD 15.1-RC3 an. Der dritte Release Candidate war nötig geworden, weil ein kritischer Bug im x86-Bootloader entdeckt wurde, der das System beim Booten zum Hängen bringen konnte – insbesondere, aber nicht ausschließlich, wenn Intel-Microcode-Updates geladen werden.
Die offizielle Ankündigung warnt ausdrücklich: Beim Upgrade auf RC3 muss der aktualisierte EFI-Bootloader installiert werden. Der ursprünglich für Anfang Juni geplante Release-Termin verschiebt sich damit auf Mitte Juni.
RC2 (vom 31. Mai) hatte bereits PadLock-RNG-Unterstützung für VIA/Zhaoxin-Prozessoren wieder aufgenommen und die Sicherheitsfixes aus SA-26:19 bis SA-26:24 integriert. RC3 baut darauf auf und fügt den kritischen Bootloader-Fix hinzu.
Verfügbar sind Images für amd64, powerpc64(le), armv7, aarch64 (inkl. RPI, PINE64, ROCK64) und riscv64, sowie VM-Images (QCOW2, VHD, VMDK, raw), OCI-Container-Images und Amazon-EC2-AMI-Images.
Sicherheitsadvisories – KI-gestützte Schwachstellenjagd zeigt Wirkung
Die Welle von Sicherheitsadvisories, die Ende Mai veröffentlicht wurde (SA-26:18 bis SA-26:24), dominiert weiterhin die Diskussionen. Bemerkenswert ist, dass ein Großteil dieser Schwachstellen durch KI-gestützte Sicherheitsforschung entdeckt wurde:
SA-26:18.setcred – Stack-Buffer-Overflow via setcred(2)
Eine Schwachstelle im neuen setcred(2)-Systemaufruf ermöglichte einen Stack-Buffer-Overflow, der zur lokalen Privilegieneskalation führen konnte (CVE-2026-45250).
SA-26:19.file – Kernel Use-After-Free über File-Descriptor-Syscalls
Entdeckt von der Firma Calif.io. Ein Use-After-Free im Kernel über Dateideskriptor-Systemaufrufe.
SA-26:20.fusefs – Heap-Overflow in FUSE_LISTXATTR
Entdeckt vom AISLE Research Team. Ein Heap-Overflow im FUSE-Dateisystem-Code.
SA-26:21.ptrace – Fehlende Validierung in ptrace(PTSCREMOTE)
Gefunden von Forschern mit GLM-5.1 von Z.ai. Unprivilegierte lokale Nutzer konnten Berechtigungen auf Root eskalieren.
Ebenfalls vom AISLE Research Team. Ein Überlauf des Dateideskriptor-Sets in select(2) führte zu einem Stack-Overflow. CVE-2026-39457 und CVE-2026-39461 wurden zugewiesen.
SA-26:23.bsdinstall – RCE über WLAN-Scan beim Installer
Ein sorgfältig gestalteter Netzwerkname (SSID) konnte während des WLAN-Scans in bsdinstall/bsdconfig zur Befehlsausführung führen.
Unkorrekte Manipulation von Berechtigungslisten in libcap_net konnte die Berechtigungen eines Prozesses erweitern.
Älteres Advisory aus April: SA-26:14.pf – pf-Stack-Overflow über SCTP
Bereits am 29. April veröffentlicht, aber für das Verständnis der aktuellen Welle relevant: Ungültige SCTP-Pakete konnten durch ungebundene Rekursion in pf zu einem Stack-Overflow und Kernel-Panic führen (CVE-2026-7164).
AISLE: Drei setuid-root-Stack-Buffer-Overflows aufgedeckt
Das AISLE Research Team veröffentlichte am 25. Mai einen detaillierten Blogpost über die Entdeckung von drei separaten Stack-Buffer-Overflows in FreeBSD, die alle über denselben grundlegenden Angriffspfad erreichbar waren:
ping6: Der setuid-root-Befehl verlor einen Sicherheitscheck, den das eng verwandte ping-Programm behalten hatte. Ein lokaler Nutzer konnte durch Öffnen vieler Dateideskriptoren und anschließendes Ausführen von /sbin/ping6 Deskriptoren über 1023 erzwingen und damit FD_SET()-Aufrufe ohne Bounds-Check erreichen.
libnv: Derselbe FD_SET-Überlauf in der NV-Code-Bibliothek.
libcasper: Ironischerweise traf der Fehler auch die Capsicum/Casper-Infrastruktur, die eigentlich zur Sandbox-Isolation gedacht ist.
Besonders interessant: Der ping6-Bug war bereits 2002 in ähnlichem Code behoben worden, der entsprechende Guard wurde aber bei einem späteren Refactoring entfernt und nie wiederhergestellt.
Blogposts und Artikel
„An AI audit of FreeBSD“ (blog.calif.io, 28. Mai)
Calif.io veröffentlichte einen umfassenden Rückblick auf ihre KI-gestützte Audit-Kampagne gegen FreeBSD. Ergebnis: 15 Kernel-Bugs, darunter 3 Remote Code Execution (RCE), 5 Local Privilege Escalation (LPE) und 1 bhyve-Escape. Der Blogpost dokumentiert den Prozess und die Ergebnisse im Detail.
„CVE-2026-7270: How I Get Root on FreeBSD with a Shell Script“ (blog.calif.io, 7. Mai)
Ein weiterer Calif.io-Artikel, der demonstriert, wie ein einzelnes Shell-Skript ausreichte, um Root-Zugriff auf einem FreeBSD-System zu erlangen.
AISLE: „AISLE matches Anthropic Mythos on FreeBSD zero-days“ (6. Mai)
AISLE berichtet, dass sie drei der acht FreeBSD-Sicherheitsadvisories aus April 2026 unabhängig reproduzieren konnten, die auch von Nicholas Carlini bei Anthropic (Claude Mythos) gefunden wurden.
CVE-2026-42511: Eine 21 Jahre alte Remote-Code-Execution-Schwachstelle in dhclient, bei der das BOOTP-Dateifeld nicht korrekt escaped wurde und so beliebige dhclient.conf-Direktiven injiziert werden konnten.
Frankfurt Area FreeBSD Hackathon Recap (FreeBSD Foundation, 2. Juni)
Die FreeBSD Foundation veröffentlichte den Rückblick auf das erste regionale Hackathon im Frankfurter Raum (24.–26. April). Ergebnisse: 120 geschlossene Bug-Reports, erfolgreiche Implementierung von SBOM-Funktionalität (Software Bill of Materials) und eine deutsche Übersetzung von Sylve.
„FreeBSD May 2026 Security Batch – An Operator’s Triage Guide“ (maxiujun.com)
Eine praktische Triage-Anleitung für Admins: Von den sieben gleichzeitig veröffentlichten Advisories sind zwei kernel-seitig und trivial durch lokale Nutzer ausnutzbar – diese sollten zuerst gepatcht werden.
Mailinglisten-Diskussionen
mtree(1) POLA-Verletzung
Gleb Smirnoff wies auf der freebsd-current-Liste darauf hin, dass der aktuelle Import von mtree(1) aus NetBSD eine POLA-Verletzung (Principle of Least Astonishment) darstellt: Das Verhalten bei Prüfsummen hat sich geändert. Jose Luis Duran und Xin LI diskutierten mögliche Korrekturen; ein Differential (D56013) wurde eingereicht, um fehlende Einträge nachzuziehen.
15.1-Release-Planung
Die Mailinglisten zeigen die typische Endphase-Aktivität: RC1, RC2 und RC3 wurden jeweils mit Ankündigungen auf freebsd-stable veröffentlicht. Die Verzögerung durch die zusätzlichen Release-Kandidaten wird auf den Listen gemischt aufgenommen – Verständnis für die Sicherheitslücken, aber auch Ungeduld beim Warten auf den finalen Release.
Ausblick
BSDCan 2026 und das FreeBSD Developer Summit finden am 17.–18. Juni in Ottawa, Kanada, statt.
FreeBSD 15.1-RELEASE wird voraussichtlich Mitte Juni erscheinen, sofern keine weiteren kritischen Probleme auftauchen.
Die KI-gestützte Sicherheitsforschung (Calif.io, AISLE, Anthropic Mythos) hat sich als ernstzunehmende Kraft etabliert – weitere Funde sind zu erwarten.
Diese Woche war eine der security-intensivsten Wochen in der jüngeren FreeBSD-Geschichte. Zwischen KI-entdeckten Schwachstellen, einem neuen Release-Kandidaten und der Executive Directorin, die FreeBSD auf einem Laptop daily-drived, gab es viel zu besprechen.
FreeBSD 15.1-RC1 veröffentlicht
Am 29. Mai veröffentlichte Colin Percival den ersten Release-Kandidaten für FreeBSD 15.1. Der RC1 enthält eine Reihe von Security-Fixes (dazu unten mehr), Verbesserungen am fwget-Firmware-Tool sowie kleinere Kernel-Bugfixes und Manpage-Updates.
Die 15.1-RELEASE ist für Juni geplant, vorausgesetzt, es tauchen keine weiteren Überraschungen auf. Bisher lief der Release-Zyklus relativ glatt: BETA1 kam am 2. Mai, und der RC1 ist der bisher letzte Meilenstein.
Am 20. Mai veröffentlichte FreeBSD sieben Security-Advisories auf einen Schlag — genug, um selbst erfahrene Operatoren ins Schwitzen zu bringen. Xiujun Ma hat eine hervorragende Triage-Anleitung veröffentlicht, die ich jedem Administrator empfehle.
Die beiden kritischsten:
SA-26:18.setcred — Kernel-Level RCE
Die setcred(2)-Systemfunktion kopiert eine benutzerdefinierte Liste ergänzender Gruppen in einen Kernel-Stack-Buffer fester Größe — ohne die Länge zu prüfen. Das Ergebnis: Ein Stack-Overflow im Kernel, der beliebige Codeausführung auf Kernelebene ermöglicht. Jeder lokale Nutzer kann das ausnutzen, keine spezielle Konfiguration nötig, alle unterstützten FreeBSD-Versionen betroffen. Sofort patchen.
SA-26:21.ptrace — Lokale Privilegieneskalation (CVE-2026-45253)
Fehlende Parametervalidierung in der PT_SC_REMOTE-ptrace-Operation ermöglicht es unprivilegierten lokalen Nutzern, beliebige Systemaufrufe innerhalb eines Zielprozesses auszuführen. Lokal → Root. Auf Multi-User-Systemen und Jail-Hosts ebenfalls sofort patchen.
Die weiteren fünf Advisories:
Advisory
Problem
Dringlichkeit
SA-26:24.cap_net
Capsicum-Berechtigungslimit kann umgangen werden
Diese Woche
SA-26:22.libcasper
Stack-Overflow via select(2) bei >1024 Filedeskriptoren (CVE-2026-45252)
Diese Woche
SA-26:23.bsdinstall
Root-RCE über böswillige WLAN-SSIDs beim Scannen (CVE-2026-45255)
Vor nächster Installation
SA-26:20.fusefs
Kernel-Heap-Disclosure/Injection über bösartigen FUSE-Daemon
Nur wenn fusefs.kogeladen
SA-26:19.file
file(1) / libmagic-Problem
Diese Woche
KI-entdeckte Schwachstellen: Calif.io und AISLE
Das ist die große Geschichte dieser Woche: KI-Systeme finden jetzt aktiv FreeBSD-Kernel-Bugs.
Calif.io — „An AI Audit of FreeBSD“
Das Sicherheitsforschungsunternehmen Calif.io hat einen ausführlichen Blogpost veröffentlicht, der ihre KI-gestützte Audit des FreeBSD-Kernels beschreibt. In wenigen Wochen fand die KI:
5 lokale Privilegieneskalationen
1 bhyve Guest-to-Host-Escape
Eine Handvoll Memory Disclosures und DoS-Bugs
Insgesamt 15 Kernel-Bugs, alle an das FreeBSD-Security-Team gemeldet. Bemerkenswert ist der Ansatz: Calif.io hat sich mit dem FreeBSD-Team abgestimmt, sich auf deren Prioritäten fokussiert und nur High/Critical-Bugs gemeldet — keine CVE-Jagd, sondern gezielte Hilfe.
Zu den veröffentlichten Exploits gehört setcred (CVE-2026-45250): Ein Ein-Zeichen-sizeof-Fehler in kern_setcred_copyin_supp_groups wird zu einem Stack-Overflow, der zu einer lokalen Root-Shell führt. Nur FreeBSD 14.4 ist ausnutzbar, obwohl der gleiche Bug in 14.3 und 15.0 vorhanden ist.
AISLE — Autonome Schwachstellenforschung
Das AISLE Research Team hat ebenfalls zugeschlagen. Am 25. Mai veröffentlichten sie einen Bericht über drei Stack-Buffer-Overflows in ping6, libnv und libcasper — alle über denselben grundlegenden Mechanismus erreichbar: FD_SET()mit Filedeskriptoren >1023.
Der ping6-Bug ist besonders pikant: Das Binary läuft setuid-root, also kann jeder lokale Nutzer den Schwachstellenpfad in einem Prozess mit effektiver UID 0 triggern. Ironischerweise hatte FreeBSD genau diese Fehlerklasse 2002 schon einmal in verwandtem Code behoben — die Schutzmaßnahme in ping6 verschwand aber bei einem späteren Refactoring und kam nie zurück.
AISLE hat außerdem einen 21 Jahre alten RCE in dhclient (CVE-2026-42511) entdeckt und berichtet, dass ihr autonomes System drei der acht April-Security-Advisories unabhängig gefunden hat — auf Augenhöhe mit Anthropics „Claude Mythos“.
Deb Goodkin daily-drived FreeBSD auf einem Framework-Laptop
Deb Goodkin, Executive Director der FreeBSD Foundation seit 2005, hat auf der Open Source Summit + ELC NA 2026 in Minneapolis über ihre Erfahrungen mit FreeBSD als Daily-Driver auf einem Framework-Laptop gesprochen. Bisher lief bei ihr — wie bei vielen — ein anderes OS auf dem Laptop, weil FreeBSD „wie ein Berg“ wirkte.
Ihre Erkenntnisse:
Touchscreen funktionierte sofort
KDE-Desktop lief stabil
Peripherie wie WLAN-Maus klappte problemlos
Zoom funktionierte nach einigem Suchen
Webcam brauchte manuelle Einrichtung
Microsoft Teams funktionierte nur teilweise
Das passt zum laufenden Laptop Integration Testing Project der Foundation, das 2026 die Grafik- und WLAN-Treiberlücke zu Linux schließen will.
NVIDIA-Treiber-Update
Der NVIDIA-Grafiktreiber in den FreeBSD-Ports wurde auf Version 595.71.05 aktualisiert. Wer NVIDIA-Hardware unter FreeBSD betreibt, sollte die Port-Aktualisierung einplanen.
Mailinglisten-Diskussionen
Boot-Probleme: Es gab mehrere Berichte über Boot-Zeit-Probleme und Hänger bei 15.1-Installationen, insbesondere im diskless-Betrieb. Die Diskussionen auf freebsd-stableund freebsd-current sind noch im Gange.
15.1-BETA1-Pkgbase-Fingerprint-Problem: Graham Perrin meldete ein Problem mit den Fingerabdrücken der Basispakete in 15.1-BETA1, das Colin Percival zur Kenntnis genommen hat.
OpenBSD 7.9 (Nachbar-Notiz)
Am 30. Mai wurde OpenBSD 7.9 veröffentlicht — mit Unterstützung für bis zu 255 CPU-Kerne und WiFi 6. Nicht direkt FreeBSD, aber für alle BSD-Interessierten erwähnenswert.
Fazit der Woche
Die große Erkenntnis: KI-gestützte Sicherheitsforschung ist kein theoretisches Konzept mehr, sondern findet aktiv Kernel-Bugs in FreeBSD. Gleichzeitig zeigt die Kooperation zwischen Calif.io/AISLE und dem FreeBSD-Team, wie das konstruktiv aussehen kann — kurze Reports, vorgeschlagene Patches, direkte Kommunikation statt CVE-Zahlen-Jagd.
Die 15.1-RELEASE rückt näher und bringt alle diese Fixes mit. Wer Multi-User-Systeme betreibt, sollte SA-26:18.setcred und SA-26:21.ptrace sofort patchen — die restlichen Advisories diese Woche.
Die vergangene Woche war eine der ereignisreichsten für FreeBSD seit Langem: Sechs Sicherheitslücken wurden gleichzeitig veröffentlicht, FreeBSD 15.1 erreichte den Release-Candidate-Status, und die FreeBSD Foundation zeigt sich von der eigenen Desktop-Nutzung überrascht.
FreeBSD 15.1-RC1 veröffentlicht
Am 22. Mai gab Colin Percival die Veröffentlichung von FreeBSD 15.1-RC1 bekannt — der erste und voraussichtlich letzte Release Candidate vor dem geplanten Final Release Anfang Juni. RC1 steht für amd64, powerpc64, powerpc64le, armv7, aarch64 (inkl. RPI, PINE64, PINEBOOK, ROCK64, ROCKPRO64) und riscv64 zur Verfügung.
Die Änderungen seit Beta 3 umfassen:
Die sechs neuen Security Advisories SA-26:18 bis SA-26:24 (siehe unten)
Verbesserungen an fwget(8) zur automatischen Erkennung benötigter Firmware für weitere WLAN-Karten
EC2 „small“-Instanzen führen firstboot_pkgs nicht mehr standardmäßig aus
freebsd-update fragt nicht mehr nach dem Merge von /etc/ssl/cert.pem
Diverse Kernel-Bugfixes und Manpage-Updates
Der gesamte Satz an Installations-Images, VM-Images (QCOW2, VHD, VMDK, Raw), OCI-Container-Images und EC2-AMI-Images steht auf den üblichen Download-Mirrors bereit.
Schwere Sicherheitswoche: Sechs Advisories gleichzeitig
Am 20. Mai veröffentlichte das FreeBSD Security Team gleich sechs Security Advisories — und gleich mehrere davon wurden durch KI-gestützte Schwachstellensuche entdeckt.
Die schwerwiegendste Schwachstelle der Woche. Ein sizeof-Typfehler in kern_setcred_copyin_supp_groups()(sys/kern/kern_prot.c) führt zu einem Kernel-Stack-Buffer-Overflow im setcred(2)-Systemaufruf. Die Fehlerkette: sizeof(*groups) ergibt 8 Bytes (Zeigergröße) statt der erwarteten 4 Bytes (sizeof(gid_t)). Ein unprivilegierter lokaler Nutzer kann damit Root-Rechte erlangen — sogar auf Systemen mit SMAP/SMEP. Die Schwachstelle wurde von Przemyslaw Frasunek unter dem Namen „FatGid“ veröffentlicht und betrifft FreeBSD 14.3, 14.4 und 15.0.
Betroffen: 14.3 (behoben in p14), 14.4 (behoben in p5), 15.0 (behoben in p9). FreeBSD 13.x und früher sind nicht betroffen, da setcred(2) dort nicht existiert.
SA-26:19.file — Kernel Use-After-Free
Fehlerhafter Dateideskriptor-Systemaufruf kann zu Use-After-Free im Kernel führen. Entdeckt von Calif.io (KI-gestützte Schwachstellensuche).
SA-26:20.fusefs — Heap-Overflow in FUSE_LISTXATTR
Der Kernel verarbeitet erweiterte Attributlisten von Userspace-FUSE-Daemons ohne korrekte NUL-Terminierungsprüfung. Entdeckt vom AISLE Research Team (autonome Schwachstellensuche).
SA-26:21.ptrace — Fehlende Validierung in ptrace(PTSCREMOTE)
Fehlende Eingabevalidierung ermöglicht unprivilegierten lokalen Nutzern die Eskalation zu Root. Entdeckt mit GLM-5.1 von Z.ai.
SA-26:22.libcasper — Stack-Overflow über select(2)
Überlauf des Dateideskriptor-Sets in select(2) innerhalb von libcasper führt zu Stack-Overflow. Entdeckt vom AISLE Research Team.
SA-26:23.bsdinstall — Remote Code Execution über WLAN-Scan
Ein speziell gestalteter Netzwerkname (SSID) kann während des WiFi-Scans in bsdinstall und bsdconfig zur Ausführung beliebiger Befehle führen. Praktisch relevant bei der Installation in WLAN-Umgebungen.
Fehlerhafte Manipulation von Limitierungslisten in libcap_net kann die Berechtigungen eines Prozesses erweitern. Entdeckt vom AISLE Research Team.
Fazit: Bemerkenswert ist, dass mehrere dieser Schwachstellen durch KI-basierte Werkzeuge entdeckt wurden (Calif.io, GLM-5.1, AISLE Research Team). Dies markiert einen Wendepunkt im Sicherheitsaudit von Betriebssystemen.
FreeBSD 15.1 Beta 3 (17. Mai)
Die dritte Beta von FreeBSD 15.1 brachte am vergangenen Wochenende ebenfalls wichtige Neuerungen:
OpenZFS 2.4.2 wurde integriert (Bugfixes und Verbesserungen)
Cloud-Images führen nun automatisch pkg upgrade beim ersten Boot durch, um Sicherheitsupdates anzuwenden
Kerberos wurde aktualisiert
Scripted bsdinstall-Installationen nutzen nun pkgbase
Geplantes KDE-Desktop-Installationsprofil wurde auf FreeBSD 15.2 verschoben, da das Skript noch an neue NVIDIA-Treiber und veraltete Teile angepasst werden muss
FreeBSD Foundation Executive Director täglich FreeBSD auf Laptop
Deb Goodkin, Executive Director der FreeBSD Foundation seit 2005, berichtete auf der Open Source Summit North America (OSS 2026) in Minneapolis über ihre Erfahrungen, FreeBSD erstmals als tägliches Betriebssystem auf einem Framework-Laptop zu nutzen. Bisher hatte sie FreeBSD jedes Mal als „Berg“ empfunden, wenn sie es auf Laptops probierte. Mit der KDE-Desktop-Umgebung funktionierte der Touchscreen sofort, ebenso Peripheriegeräte. Probleme blieben jedoch: Zoom funktionierte nur nach Aufwand, die Webcam benötigte manuelle Schritte, und Microsoft Teams funktionierte nur teilweise. Ein ermutigendes Zeichen, aber auch ein ehrlicher Blick auf den noch bestehenden Nachholbedarf im Desktop-Bereich.
Ian Wagner veröffentlichte einen hilfreichen Blogbeitrag über die Konfiguration unterschiedlicher Package-Repositorien pro Jail unter FreeBSD. Mit AppJail lassen sich Jails deklarativ verwalten, und der Beitrag zeigt, wie man spezifische Jails auf den latest-Zweig der Ports umstellt, wenn man aktuellere Pakete benötigt, während andere beim quarterly-Zweig bleiben.
FreeBSD Resource Monitoring, Accounting, and Troubleshooting (Larvitz Blog)
Ein ausführlicher Beitrag über Ressourcenüberwachung und Fehlerbehebung auf FreeBSD-Systemen — von „der Server fühlt sich langsam an“ bis hin zu konkreten Diagnosewerkzeugen.
Migration von Ubuntu 16.04 zu FreeBSD
Ein Blog, der 10 Jahre auf Ubuntu 16.04 lief, berichtete über die Migration zu FreeBSD — motiviert durch das Ende des Lebenszyklus von Ubuntu 16.04 und die Aussicht auf langfristige Stabilität.
Valuable News — 18. Mai (vermaden)
Die wöchentliche Linksammlung von vermaden bietet wie immer einen guten Überblick über BSD- und UNIX-relevante Artikel der Woche.
Mailinglisten-Diskussionen
pkgbase-Upgrade von 15.0 auf 15.1
Die Diskussionen um den pkgbase-Upgrade-Pfad von 15.0-RELEASE auf 15.1-BETA2 zeigen, dass der Übergang zur neuen Standard-Installationsmethode noch nicht ganz reibungslos verläuft. Probleme mit Kernel-Modulen (kmods) und der pkgbase-quarterly-Repos wurden ausführlich diskutiert.
Boot-Time Bugs auf freebsd-stable
Garrett Wollman berichtete über Probleme beim Booten seiner Server-Flotte und löste eine Diskussion über Boot-Time-Verhalten und Fehlerbehandlung aus.
Diskless-Systeme mit 15.1
Daniel Braniss und Bjoern Zeeb diskutierten Probleme mit diskless-Setups unter FreeBSD 15.1, die zum Hängen führen können.
Ausblick
Wenn alles nach Plan verläuft, erscheint FreeBSD 15.1-RELEASE voraussichtlich am 2. Juni 2026. Das KDE-Desktop-Installationsprofil wird auf 15.2 (erwartet im Dezember) verschoben. Bis dahin bleibt die manuelle Installation über pkg der empfohlene Weg.
Die Woche war geprägt von der dritten Beta von FreeBSD 15.1, einer wichtigen Sicherheitslücke in execve(), Diskussionen über die KDE-Desktop-Installation und der Verschiebung dieses Features auf 15.2, sowie zwei libnv-Sicherheitslücken, die Ende April offengelegt wurden und nach wie vor Aufmerksamkeit verdienen. Hier ist der Überblick.
FreeBSD 15.1 Beta 3 veröffentlicht
Am Wochenende wurde FreeBSD 15.1-BETA3 als neuester Testkandidat veröffentlicht. Das Release rückt damit in die heiße Phase — nächste Woche wird der Release Candidate (RC) erwartet, und wenn alles glatt läuft, soll FreeBSD 15.1-RELEASE am 2. Juni 2026erscheinen.
Die wichtigsten Änderungen in Beta 3:
OpenZFS 2.4.2 wurde integriert — die neueste OpenZFS-Version mit diversen Fehlerkorrekturen und kleinen Verbesserungen.
Cloud-Images führen nun beim ersten Boot automatisch pkg upgrade durch, um Sicherheitsupdates des Basissystems anzuwenden. Das ist ein sinnvoller Schritt für Cloud-Deployments, die oft aus veralteten Images starten.
Kerberos wurde aktualisiert.
bsdinstall nutzt bei skriptgesteuerten Installationen jetzt pkgbase.
Die Beta-Phase lief bisher relativ ruhig — BETA1 und BETA2 in den Wochen davor brachten vor allem Zstd 1.5.7, Fehlerkorrekturen in ifconfig, lockf, stat, tail, certctl sowie Kernel-Fixes für nullfs, so_splice und VT.
Rückblick BETA2 (8. Mai)
Update auf Zstd 1.5.7
bsdinstall nutzt nun konsistent pkg.freebsd.org für Package-Bootstrap
Diverse Userland- und Kernel-Fixes
Kritische Sicherheitslücke in execve() — CVE-2026-7270
Eine ernste Sicherheitslücke im Kernel wurde Ende April veröffentlicht und hat diese Woche weiterhin Diskussionsstoff geliefert. FreeBSD-SA-26:13.exec beschreibt einen Operator-Vorrang-Fehler (operator precedence) in der Implementierung von execve(2), der zu einem Pufferüberlauf führt. Angreiferkontrollierte Daten können in angrenzende Argument-Puffer überschreiben und Kernel-Zustand korrumpieren, was zur Erlangung von Root-Rechten durch unprivilegierte Nutzer führen kann.
Die Lücke betrifft alle unterstützten FreeBSD-Versionen (13.5 bis 15-Branch). Patches wurden innerhalb von Stunden veröffentlicht, und die Behebung besteht im Hinzufügen expliziter Klammern zur Durchsetzung der beabsichtigten Auswertungsreihenfolge sowie einer Verschärfung der Größenprüfungen.
Reaktionen der Community
Positiv: Rasche Reaktion — das Advisory erschien weniger als eine Stunde nach Entdeckung des Fehlers, Patches für alle Zweige waren am selben Tag verfügbar.
Kritisch: Es gibt keinen Workaround. Administratoren, die keinen sofortigen Reboot durchführen können (z. B. bei High-Availability-Systemen), bleiben verwundbar.
Quellcode-basierte Installationen erfordern Kernel-Rekompilierung und Reboot, was auf älterer Hardware Stunden dauern kann.
Zwei libnv-Sicherheitslücken (SA-26:16 und SA-26:17)
Ebenfalls am 29. April wurden zwei Sicherheitslücken in libnv veröffentlicht, die weiterhin relevant sind:
SA-26:16 (CVE-2026-39457): Stack-Overflow über select() — wenn ein Socket-Deskriptor größer als FD_SETSIZE (1024) ist, wird der Dateideskriptor-Satz von select(2) überlaufen. Ein Angreifer, der ein Programm dazu bringen kann, viele Dateideskriptoren zu öffnen, kann einen Stack-Overflow auslösen und bei setuid-Root-Programmen lokale Privilegien eskalieren. Entdeckt von Joshua Rogers (AISLE Research Team).
SA-26:17 (CVE-2026-35547): Heap-Overflow in libnv — die Nachrichtengröße wird beim Verarbeiten des Headers nicht korrekt validiert, was Schreiben außerhalb der Heap-Allokation ermöglicht. Dies kann Abstürze, Panics oder mögliche Privilegieneskalation durch unprivilegierte Nutzer verursachen. Entdeckt von Mariusz Zaborski.
Beide Lücken betreffen alle unterstützten FreeBSD-Versionen und haben keinen Workaround. Ein Upgrade und Reboot ist zwingend erforderlich.
KDE-Desktop-Installation verschoben auf FreeBSD 15.2
Die lang erwartete KDE-Desktop-Option im FreeBSD-Installer wurde erneut verschoben — diesmal von 15.1 auf 15.2 (voraussichtlich Dezember 2026). Ursprünglich für 15.0 geplant, dann auf 15.1 verschoben, muss das Skript wegen neuer NVIDIA-Treiber aktualisiert und veraltete Teile entfernt werden. Nach dem Commit in CURRENT wird eine Testphase in STABLE benötigt, was den Zeitrahmen für 15.1 nicht mehr einhält.
Bis dahin bleibt der manuelle Weg: KDE Plasma nach der Installation via pkg aufsetzen.
Mailinglisten-Diskussionen
Update-Strategie und Timing (freebsd-current)
Bob Prohaska startete eine Diskussion über bevorzugte Update-Strategien für selbst gehostete FreeBSD-Systeme. Auf stable-Zweigen ist die Sache einfach: freebsd-update nutzen. Auf current wird es komplexer. Warner Losh, Rick Macklem, Mark Millard und andere diskutierten die Vor- und Nachteile verschiedener Ansätze — eine nützliche Lektüre für jeden, der current im Produktivbetrieb nutzt.
PKGBASE: Upgrade von 15.0 auf 15.1-BETA2
Vermaden fragte nach dem Upgrade-Pfad von FreeBSD 15.0-RELEASE auf 15.1-BETA2 im PKGBASE-Modell. Colin Percival bestätigte, dass dieser Pfad noch nicht vollständig dokumentiert ist. Das PKGBASE-System ist weiterhin als experimentell markiert, und der Minor-Upgrade-Pfad benötigt noch Arbeit.
Beach Cleaning Project: Infrastruktur-Aufräumung
Die FreeBSD Foundation veröffentlichte Ende April einen ausführlichen Bericht zum Beach Cleaning Project, der auch diese Woche noch Aufmerksamkeit erhält. Das Projekt zielt darauf ab, die Sicherheitsresilienz des FreeBSD-Basissystems zu verbessern:
Maschinenlesbares Inventar von über 1.000 Komponenten im Basissystem, darunter 73 Third-Party-Komponenten
OpenSSL 3.5 LTS wurde rechtzeitig für FreeBSD 15.0 integriert (statt OpenSSL 3.0, das im September 2026 EOL erreicht)
SBOM-Generierung (Software Bill of Materials) im SPDX 2/3-Format
CODEOWNERS-ähnliche Berichte für bessere Wartbarkeit
Vorbereitung auf den Import von pkg ins Basissystem als Teil des pkgbase-Übergangs
Gefördert wurde das Projekt von Alpha-Omega.
Blogbeiträge der Woche
Vermaden: FreeBSD PKGBASE Minor Upgrades
Vermaden veröffentlichte einen praktischen Leitfaden zum Upgrade von FreeBSD 15.0 auf 15.1-BETA2 mit PKGBASE und ZFS Boot Environments. Der Artikel zeigt Schritt für Schritt, wie man eine neue BE erstellt, pkg-Repository konfiguriert, das Basissystem aktualisiert und bei Problemen zurückkehren kann — inklusive eines alternativen Wegs mit --chroot.
Going Back to BSD
Pete veröffentlichte einen persönlichen Blogbeitrag über seine Rückkehr zu BSD nach Jahrzehnten mit Linux. Er beschreibt den Wechsel von Linux (Arch) zu FreeBSD, die Einrichtung von Mailservern mit Bastille-Jails und die erfrischende Einfachheit des rc-Systems im Vergleich zu systemd. Ein nostalgischer und praktischer Bericht.
Ausblick
Die nächste Woche steht im Zeichen des Release Candidates für FreeBSD 15.1. Wenn keine unerwarteten Probleme auftreten, wird das finale Release am 2. Juni 2026 erwartet. Administratoren sollten dringend die drei Sicherheitslücken (execve, libnv x2) patchen, falls noch nicht geschehen.
Die vergangene Woche war eine der ereignisreichsten im FreeBSD-Projekt seit langem: Zwei Beta-Releases, ein massiver Security-Advisory-Bundle, aufsehenerregende KI-gestützte Schwachstellenfunde und ein neuer Blogpost zum pkgbase-Upgrade-Pfad. Hier ist der Überblick.
FreeBSD 15.1: Beta 1 und Beta 2 veröffentlicht
Der Release-Zyklus für FreeBSD 15.1 nimmt Fahrt auf. Nachdem Colin Percival am 2. Mai 15.1-BETA1 angekündigt hat, folgte bereits am 8. Mai 15.1-BETA2 — der wöchentliche Rhythmus wird eingehalten.
Änderungen in Beta 2 (gegenüber Beta 1)
Zstd auf 1.5.7 aktualisiert — aktuelle Upstream-Kompressionsunterstützung
less auf v692 aktualisiert
bsdinstall nutzt jetzt konsistent pkg.FreeBSD.org für Package-Bootstrap-Operationen
nuageinit parst user_data nur noch bei Bedarf als YAML
rtadvd(8) beachtet jetzt pltime und vltime in Interface-Deklarationen
Diverse Userland-Bugfixes: ifconfig(8), lockf(1), stat(1), tail(1), certctl(8)
Kernel-Bugfixes: nullfs, so_splice, vt(4)
Verschiedene Manual-Page- und Test-Korrekturen
Verfügbare Architekturen
Images gibt es für amd64, powerpc64, powerpc64le, armv7, aarch64 (inkl. RPI, PINE64, ROCK64-Varianten) und riscv64. Zusätzlich stehen VM-Disk-Images (QCOW2, VHD, VMDK, Raw), OCI-Container-Images (static, dynamic, runtime, notoolchain, toolchain) und Amazon-EC2-AMIs zur Verfügung.
Zeitplan
Beta 3 wird für nächste Woche erwartet
Release Candidate die Woche darauf
15.1-RELEASE am 2. Juni 2026 — sofern alles planmäßig verläuft
Schwerwiegende Sicherheitslücken — 8 Advisories am 29. April
Am 29. April veröffentlichte FreeBSD einen ganzen Schwung an Security Advisories, die in dieser Woche breit diskutiert wurden:
Advisory
Modul
Beschreibung
Schwere
SA-26:11
amd64
Fehlende Large-Page-Verarbeitung in pmap_pkru_update_range()
Hoch
SA-26:12
dhclient
Remote Code Execution über bösartige DHCP-Optionen (CVE-2026-42511)
Kritisch
SA-26:13
execve
Lokale Privilegieneskalation über execve(2)
Hoch
SA-26:14
pf
Stack-Overflow beim Parsen manipulierter SCTP-Pakete
Hoch
SA-26:15
dhclient
Remote auslösbbarer Out-of-Bounds-Heap-Write in dhclient
Kritisch
SA-26:16
libnv
Stack-Overflow über select()-File-Descriptor-Set-Overflow
Hoch
SA-26:17
libnv
Heap-Overflow in libnv
Hoch
Zusätzlich wurde am 1. Mai EN-26:11 veröffentlicht: Eine Errata-Notice, die ein zu striktes dhclient-Lease-Validation-Verhalten korrigiert — ein Nebenprodukt der Security-Fixes.
Der 21 Jahre alte dhclient-RCE (CVE-2026-42511)
Besonders bemerkenswert: Die Schwachstelle in dhclient (SA-26:12) existierte seit über 20 Jahren im Code. Das BOOTP-Dateifeld wurde ohne Escaping von eingebetteten Doppelquotes in die Lease-Datei geschrieben, was die Injektion beliebiger dhclient.conf-Direktiven ermöglichte — und damit Remote Code Execution nach einem Systemneustart.
KI-gestützte Schwachstellenforschung: AISLE vs. Anthropic Mythos
Am 7. Mai veröffentlichte die Firma AISLE einen Blogpost, der für Aufsehen sorgte: Ihr Multi-Modell-System hatte drei kritische Schwachstellen in FreeBSD entdeckt — unabhängig von und parallel zu den Funden, die Anthropics „Claude Mythos“ gemacht hatte.
AISLEs Funde:
Den 21 Jahre alten dhclient-RCE (CVE-2026-42511)
Einen remoten auslösbaren Heap-Buffer-Overflow in dhclient
Einen Stack-Buffer-Overflow in ping6 (lokale Privilegieneskalation)
Alle drei wurden am 13. April entdeckt, am 14. April gemeldet und am 29. April gepatcht.
Interessant ist die Debatte, die AISLE mit ihrem Fund anstößt: KI-gestützte Sicherheitssysteme können auch mit kleineren, günstigeren Modellen sehr effektiv arbeiten — ein gut designtes System schlägt reine Skalierung durch größere Modelle. AISLE verweist auf ihre Studie, dass Sicherheitsfähigkeit „zerklüftet“ (jagged) ist: Kleine Modelle können bei vielen sicherheitsrelevanten Aufgaben größere übertreffen.
FreeBSD Foundation: „Cleaning Up Critical Infrastructure“
Am 20. April (in dieser Woche noch stark rezipiert) veröffentlichte die FreeBSD Foundation einen ausführlichen Blogpost über das Alpha-Omega Beach Cleaning Project. Kernpunkte:
OpenSSL 3.5 LTS wurde rechtzeitig für FreeBSD 15.0 integriert — das avoids einen Unsupported-Fork von OpenSSL 3.0 (EOL September 2026) für über vier Jahre
Eine maschinenlesbare Inventarisierung des Basissystems wurde erstellt: über 1.000 Komponenten in einer YAML-basierten Datenbank, darunter 73 Third-Party-Importe
SBOM-Generierung über SPDX 2 und SPDX 3 Formate
CODEOWNERS-artige Reports für bessere Wartungszuständigkeit
Vorbereitung für den Import von pkg ins Basissystem als Teil der pkgbase-Transition
Vermaden: PKGBASE Minor Upgrades mit ZFS Boot Environments
Am 10. Mai veröffentlichte der bekannte FreeBSD-Blogger Vermaden einen praktischen Leitfaden für Minor-Upgrades (z. B. 15.0 auf 15.1) mit PKGBASE und ZFS Boot Environments. Da PKGBASE noch als experimentell markiert ist und freebsd-update(8) für Minor-Releases nicht mehr verfügbar ist, zeigt er zwei Methoden:
Klassische Methode: Neue ZFS BE erstellen, chroot, pkg.repo konfigurieren, pkg upgrade -r FreeBSD-base
Alternative Methode: Nutzung von pkg --chroot und ABI/OSVERSION-Overrides ohne manuelles devfs-Mounting
Beide Methoden erlauben ein sicheres Rollback über ZFS Boot Environments, falls das Upgrade Probleme verursacht.
Q1 2026 Status Report: 45 Einträge
Der FreeBSD Status Report für das erste Quartal 2026 wurde am 23. April veröffentlicht — mit rekordträchtigen 45 Einträgen. Highlights:
Cyber Resilience Act (CRA) Readiness Project — Vorbereitung auf EU-Regulierung
amd64 FRED-Unterstützung — neue CPU-Flexibilitätsfeatures
LinuxKPI 802.11 und Native Wireless Update — Fortschritte bei WiFi-Treibern
Suspend/Resume- und Hibernate-Verbesserungen
Sylve — eine einheitliche Systemmanagement-Plattform für FreeBSD
daemonless — native FreeBSD OCI-Container ohne Daemon
KDE auf FreeBSD — Fortschritte bei Plasma 6 und Wayland
FreeBSD auf EC2 und STACKIT Cloud Integration
bhyve: Full CPUID Control, Management GUI
Ausblick
Mit Beta 3 in der kommenden Woche und dem Release Candidate danach rückt FreeBSD 15.1-RELEASE am 2. Juni schnell näher. Wer auf unterstützten Versionen läuft, sollte die Security-Advisories vom 29. April dringend einspielen — insbesondere den kritischen dhclient-RCE. Und für alle, die pkgbase testen, liefert Vermadens Anleitung einen guten Ausgangspunkt.
Die Woche war geprägt von gleich zwei kritischen Security Advisories, dem Erscheinen des umfangreichen Q1-Statusberichts und dem Startschuss für den 15.1-Release-Zyklus. Außerdem rückt das End-of-Life für FreeBSD 13 näher — Zeit zum Handeln für alle, die noch auf dieser Version sitzen.
Zwei Security Advisories am selben Tag
Am 21. April veröffentlichte das FreeBSD Security Team zwei Advisories, die beide von Nicholas Carlini mithilfe von Claude (Anthropic) entdeckt wurden. Dass ein KI-gestützter Fuzzing-Ansatz zwei unabhängige Kernel-Bugs aufdeckt, ist bemerkenswert und deutet auf eine neue Ära in der Sicherheitsforschung hin.
SA-26:10.tty — Use-After-Free im TIOCNOTTY-Handler (CVE-2026-5398, HIGH 8.4)
Der TIOCNOTTY-ioctl erlaubt es einem Prozess, sich von seinem kontrollierenden Terminal zu lösen. Die Implementierung bereinigte jedoch nicht den Rückzeiger von der Terminal-Struktur zur Session des aufrufenden Prozesses. Wenn der Prozess danach beendet wird, bleibt ein Dangling Pointer im Kernel zurück — und ein böswilliger Prozess kann diesen nutzen, um sich Root-Privilegien zu verschaffen.
Betroffen sind alle unterstützten FreeBSD-Versionen (13.5, 14.3, 14.4, 15.0). Es gibt keinen Workaround — ein Update und Reboot sind zwingend erforderlich.
SA-26:11.amd64 — Fehlende Large-Page-Behandlung in pmap_pkru_update_range() (CVE-2026-6386)
Die Funktion pmap_pkru_update_range() aktualisiert Page-Tabellen-Einträge, wenn Memory Protection Keys (PKRU) auf einen Adressbereich angewendet werden. Sie berücksichtigte jedoch nicht die Anwesenheit von 1GB-Largepage-Mappings, die über shm_create_largepage() erzeugt wurden. Statt einen Page-Directory-Eintrag korrekt als Largepage zu erkennen, wurde er als Zeiger auf eine weitere Page-Table-Page interpretiert.
Die Konsequenz: Ein unprivilegierter Nutzer kann den Kernel dazu bringen, Userspace-Memory als Page-Table zu behandeln und so Speicher zu überschreiben, auf den er eigentlich keinen Zugriff haben sollte. Auch hier: Alle Versionen betroffen, kein Workaround, Update erforderlich.
Fazit: Wer amd64-Systeme betreibt, sollte umgehend patchen. Beide Bugs sind lokal ausnutzbar, SA-26:10 sogar zur Rechteausweitung auf Root. Der Hinweis auf KI-gestütztes Fuzzing als Entdeckungsquelle ist ein klares Signal: Die Angreifer nutzen diese Werkzeuge bereits — die Verteidiger müssen es auch.
Q1 2026 Status Report: 45 Einträge
Am 22. April erschien der Q1 2026 Status Report mit 45 Einträgen — der erste unter einem neu durchgesetzten, strengen Redaktionsschedule. Die Highlights:
Alpha-Omega Beach Cleaning
Die FreeBSD Foundation setzt ihr Beach-Cleaning-Projekt fort, finanziert durch die Alpha-Omega-Initiative der Linux Foundation. Ziel: Sicherheitslücken in Drittanbieter-Software des Basissystems finden und beheben — proaktiv, nicht reaktiv. Das Repository umfasst Build-Infrastruktur und Fuzzing-Setup für Komponenten wie libxml2, SQLite und weitere Base-System-Abhängigkeiten. Die Verbindung zu den beiden neuen SAs ist offensichtlich: Strukturiertes Fuzzing zahlt sich aus.
Cyber Resilience Act (CRA) Readiness
Die EU verabschiedete den Cyber Resilience Act — und FreeBSD muss sich darauf vorbereiten. Die Foundation hat ein dediziertes CRA-Readiness-Projekt gestartet, das monatliche Updates liefert. Kernfragen: Welche SBOM-Anforderungen treffen FreeBSD zu? Wie wird Vulnerability-Management dokumentiert? Für alle, die FreeBSD in EU-konformen Produkten einsetzen, ist dieses Projekt essenziell.
Laptop Testing & Integration
Das Laptop Integration Testing Project hat eine Python-Anwendung vorgestellt, die FreeBSD-Kompatibilität auf Laptops automatisiert testet. Die Foundation bittet die Community, Hardware-Probes einzusenden, um eine öffentliche Kompatibilitätsmatrix aufzubauen. Fortschritte gab es auch bei:
S0ix (Modern Standby): Suspend/Resume-Unterstützung für moderne Laptops
Hibernate (Suspend-to-Disk): Weiter in Entwicklung
CPPC: AMD CPPC-Unterstützung für Zen 2+ Prozessoren (als Out-of-Tree-Modul verfügbar)
Intel FRED: Konstantin Belousov (kib) hat die ersten Patches für Intels Flexible Return and Event Delivery eingereicht — CPUID-, MSR- und CR4-Bits sind im Main, die vollständige FRED-Unterstützung steht zur Review
Sylvea v0.2.3
Das Verwaltungstool Sylvea erreichte Version 0.2.3 mit verbesserter Jail- und VM-Unterstützung. Ein leichtgewichtiges GUI für Bhyve, Jails, ZFS und Netzwerk — eine interessante Alternative zu webbasierten Tools wie TrueNAS.
HPC Initiative
FreeBSD bekommt Ports für Slurm, OpenMPI und UCX — High-Performance-Computing kommt auf der Plattform an. Das ist ein Nischen-, aber strategisch wichtiger Schritt.
Cloud
FreeBSD auf EC2 mit aktualisierten AMIs, plus eine neue STACKIT Cloud Integration (ein europäischer Cloud-Provider, der zur IAD-Gruppe gehört).
Ports-Updates
KDE Plasma 6.6.3
OpenJDK 21/25
Wazuh 4.14.3 (Security Monitoring)
FreeBSD 15.1: Code Slush erreicht
Der 15.1-Release-Zyklus hat am 17. April den Code Slush erreicht — Commits auf den stable/15-Branch benötigen keine explizite Genehmigung mehr, aber neue Features sollten vermieden werden. Der weitere Zeitplan:
Meilenstein
Datum
releng/15.1 Branch
1. Mai 2026
BETA1
1. Mai 2026
BETA2
8. Mai 2026
BETA3
15. Mai 2026
RC1
22. Mai 2026
RELEASE
2. Juni 2026
15.0 erreicht End-of-Life am 30. September 2026. Stable/15 wird bis Ende 2029 unterstützt.
FreeBSD 13.5: EOL am 30. April
Wer noch FreeBSD 13.5 betreibt, hat weniger als eine Woche Zeit zum Upgrade. Am 30. April endet der Support — danach gibt es keine Security-Patches mehr. Die Release Engineering Team hat die wöchentlichen Snapshot-Builds für stable/13 bereits eingestellt.
Die Migration auf 14.4 oder 15.0 ist jetzt dringend. Insbesondere nach SA-26:10 und SA-26:11 wäre es fahrlässig, auf einer EOL-Version zu bleiben.
ZFS: Snapshot-Automount-Deadlock behoben
Hamza (ixhamza) hat zwei wichtige ZFS-Fixes beigesteuert:
Snapshot-Automount-Deadlock bei gleichzeitigem zfs recv — Wenn ein Snapshot automounted wird, während gleichzeitig ein zfs recv läuft, konnte das System deadlocken. Der Fix reorganisiert die Locking-Reihenfolge.
AVL-Tree-Panic bei Snapshot-Automount-Race — Eine Race-Condition beim parallelen Mounten von Snapshots konnte einen AVL-Tree-Panic auslösen. Gelöst durch Umstellung auf AVL-Lookup statt Linear-Scan.
Zusätzlich gab es einen Fix für einen Memory Leak in zfsctl_snapshot_mount — die Options-Struktur wurde nicht korrekt freigegeben.
Für alle, die zfs recv im Betrieb nutzen (und das sollte jeder tun, der Replication einsetzt), sind diese Fixes relevant. Der Deadlock trat in der Praxis auf, wie ein offener Issue (#18073) zeigt.
BastilleBSD plant Einstellung
BastilleBSD hat Pläne angekündigt, einen teilzeit FreeBSD/Bastille-Sysadmin (ca. 20 Std./Woche) einzustellen — Fokus auf EMEA/APAC-Zeitzonen. Der Start ist für Mitte/Ende 2026 geplant, in Zusammenarbeit mit dem Bastille-Gründer an einem Cybersecurity-Startup. Ein Zeichen dafür, dass das Jail-Management-Ökosystem professionalisiert wird.
TopBar: Desktop-Umgebung für Wayland
Auf DiscoverBSD wurde TopBar vorgestellt — eine anpassbare Desktop-Umgebung, die mit Quickshell und QML für Wayland-Compositoren wie MangoWM und Hyprland gebaut wird. Sie integriert Statusleiste, App-Launcher, Lockscreen und Wallpaper-Management in ein einziges kohärentes System. Für FreeBSD-Laptop-Nutzer, die Wayland nutzen wollen, eine interessante Entwicklung.
ZFS Performance-Optimierung ohne neue Hardware
Ein Artikel auf DiscoverBSD fasst ZFS-Performance-Tipps zusammen, die ohne Hardware-Investitionen auskommen:
Recordsize an Workload anpassen (16K für Datenbanken, 1M–4M für Storage)
LZ4-Kompression aktivieren — reduziert oft I/O-Overhead statt ihn zu erhöhen
Pool-Topologie: Breite RAIDz-Konfigurationen durch gespiegelte VDEVs ersetzen für mehr Parallelität
Prefetch deaktivieren bei Random-Access-Workloads (Datenbanken)
Nichts Neues für ZFS-Veteranen, aber eine brauchbare Zusammenfassung für Einsteiger.
Was diese Woche bedeutet
Zwei kritische SAs in einer Woche, beide von KI-gestütztem Fuzzing entdeckt — das ist ein Weckruf. Die Werkzeuge werden besser, und die Angreifer nutzen sie auch. Der Q1-Statusbericht zeigt ein gesundes Projekt: Laptop-Support wächst, HPC kommt an, die CRA-Vorbereitung ist professionell. Und mit dem Code Slush für 15.1 rückt die nächste Release näher.
Wer noch auf 13.5 sitzt: Jetzt upgraden. Wer 15.0 oder 14.4 läuft: Jetzt patchen. Alles andere ist fahrlässig.
Die Woche war geprägt von gleich zwei kritischen Security Advisories, dem Erscheinen des umfangreichen Q1-Statusberichts und dem Startschuss für den 15.1-Release-Zyklus. Außerdem rückt das End-of-Life für FreeBSD 13 näher — Zeit zum Handeln für alle, die noch auf dieser Version sitzen.
Zwei Security Advisories am selben Tag
Am 21. April veröffentlichte das FreeBSD Security Team zwei Advisories, die beide von Nicholas Carlini mithilfe von Claude (Anthropic) entdeckt wurden. Dass ein KI-gestützter Fuzzing-Ansatz zwei unabhängige Kernel-Bugs aufdeckt, ist bemerkenswert und deutet auf eine neue Ära in der Sicherheitsforschung hin.
SA-26:10.tty — Use-After-Free im TIOCNOTTY-Handler (CVE-2026-5398, HIGH 8.4)
Der TIOCNOTTY-ioctl erlaubt es einem Prozess, sich von seinem kontrollierenden Terminal zu lösen. Die Implementierung bereinigte jedoch nicht den Rückzeiger von der Terminal-Struktur zur Session des aufrufenden Prozesses. Wenn der Prozess danach beendet wird, bleibt ein Dangling Pointer im Kernel zurück — und ein böswilliger Prozess kann diesen nutzen, um sich Root-Privilegien zu verschaffen.
Betroffen sind alle unterstützten FreeBSD-Versionen (13.5, 14.3, 14.4, 15.0). Es gibt keinen Workaround — ein Update und Reboot sind zwingend erforderlich.
SA-26:11.amd64 — Fehlende Large-Page-Behandlung in pmap_pkru_update_range() (CVE-2026-6386)
Die Funktion pmap_pkru_update_range() aktualisiert Page-Tabellen-Einträge, wenn Memory Protection Keys (PKRU) auf einen Adressbereich angewendet werden. Sie berücksichtigte jedoch nicht die Anwesenheit von 1GB-Largepage-Mappings, die über shm_create_largepage() erzeugt wurden. Statt einen Page-Directory-Eintrag korrekt als Largepage zu erkennen, wurde er als Zeiger auf eine weitere Page-Table-Page interpretiert.
Die Konsequenz: Ein unprivilegierter Nutzer kann den Kernel dazu bringen, Userspace-Memory als Page-Table zu behandeln und so Speicher zu überschreiben, auf den er eigentlich keinen Zugriff haben sollte. Auch hier: Alle Versionen betroffen, kein Workaround, Update erforderlich.
Fazit: Wer amd64-Systeme betreibt, sollte umgehend patchen. Beide Bugs sind lokal ausnutzbar, SA-26:10 sogar zur Rechteausweitung auf Root. Der Hinweis auf KI-gestütztes Fuzzing als Entdeckungsquelle ist ein klares Signal: Die Angreifer nutzen diese Werkzeuge bereits — die Verteidiger müssen es auch.
Q1 2026 Status Report: 45 Einträge
Am 22. April erschien der Q1 2026 Status Report mit 45 Einträgen — der erste unter einem neu durchgesetzten, strengen Redaktionsschedule. Die Highlights:
Alpha-Omega Beach Cleaning
Die FreeBSD Foundation setzt ihr Beach-Cleaning-Projekt fort, finanziert durch die Alpha-Omega-Initiative der Linux Foundation. Ziel: Sicherheitslücken in Drittanbieter-Software des Basissystems finden und beheben — proaktiv, nicht reaktiv. Das Repository umfasst Build-Infrastruktur und Fuzzing-Setup für Komponenten wie libxml2, SQLite und weitere Base-System-Abhängigkeiten. Die Verbindung zu den beiden neuen SAs ist offensichtlich: Strukturiertes Fuzzing zahlt sich aus.
Cyber Resilience Act (CRA) Readiness
Die EU verabschiedete den Cyber Resilience Act — und FreeBSD muss sich darauf vorbereiten. Die Foundation hat ein dediziertes CRA-Readiness-Projekt gestartet, das monatliche Updates liefert. Kernfragen: Welche SBOM-Anforderungen treffen FreeBSD zu? Wie wird Vulnerability-Management dokumentiert? Für alle, die FreeBSD in EU-konformen Produkten einsetzen, ist dieses Projekt essenziell.
Laptop Testing & Integration
Das Laptop Integration Testing Project hat eine Python-Anwendung vorgestellt, die FreeBSD-Kompatibilität auf Laptops automatisiert testet. Die Foundation bittet die Community, Hardware-Probes einzusenden, um eine öffentliche Kompatibilitätsmatrix aufzubauen. Fortschritte gab es auch bei:
S0ix (Modern Standby): Suspend/Resume-Unterstützung für moderne Laptops
Hibernate (Suspend-to-Disk): Weiter in Entwicklung
CPPC: AMD CPPC-Unterstützung für Zen 2+ Prozessoren (als Out-of-Tree-Modul verfügbar)
Intel FRED: Konstantin Belousov (kib) hat die ersten Patches für Intels Flexible Return and Event Delivery eingereicht — CPUID-, MSR- und CR4-Bits sind im Main, die vollständige FRED-Unterstützung steht zur Review
Sylvea v0.2.3
Das Verwaltungstool Sylvea erreichte Version 0.2.3 mit verbesserter Jail- und VM-Unterstützung. Ein leichtgewichtiges GUI für Bhyve, Jails, ZFS und Netzwerk — eine interessante Alternative zu webbasierten Tools wie TrueNAS.
HPC Initiative
FreeBSD bekommt Ports für Slurm, OpenMPI und UCX — High-Performance-Computing kommt auf der Plattform an. Das ist ein Nischen-, aber strategisch wichtiger Schritt.
Cloud
FreeBSD auf EC2 mit aktualisierten AMIs, plus eine neue STACKIT Cloud Integration (ein europäischer Cloud-Provider, der zur IAD-Gruppe gehört).
Ports-Updates
KDE Plasma 6.6.3
OpenJDK 21/25
Wazuh 4.14.3 (Security Monitoring)
FreeBSD 15.1: Code Slush erreicht
Der 15.1-Release-Zyklus hat am 17. April den Code Slush erreicht — Commits auf den stable/15-Branch benötigen keine explizite Genehmigung mehr, aber neue Features sollten vermieden werden. Der weitere Zeitplan:
Meilenstein
Datum
releng/15.1 Branch
1. Mai 2026
BETA1
1. Mai 2026
BETA2
8. Mai 2026
BETA3
15. Mai 2026
RC1
22. Mai 2026
RELEASE
2. Juni 2026
15.0 erreicht End-of-Life am 30. September 2026. Stable/15 wird bis Ende 2029 unterstützt.
FreeBSD 13.5: EOL am 30. April
Wer noch FreeBSD 13.5 betreibt, hat weniger als eine Woche Zeit zum Upgrade. Am 30. April endet der Support — danach gibt es keine Security-Patches mehr. Die Release Engineering Team hat die wöchentlichen Snapshot-Builds für stable/13 bereits eingestellt.
Die Migration auf 14.4 oder 15.0 ist jetzt dringend. Insbesondere nach SA-26:10 und SA-26:11 wäre es fahrlässig, auf einer EOL-Version zu bleiben.
ZFS: Snapshot-Automount-Deadlock behoben
Hamza (ixhamza) hat zwei wichtige ZFS-Fixes beigesteuert:
Snapshot-Automount-Deadlock bei gleichzeitigem zfs recv — Wenn ein Snapshot automounted wird, während gleichzeitig ein zfs recv läuft, konnte das System deadlocken. Der Fix reorganisiert die Locking-Reihenfolge.
AVL-Tree-Panic bei Snapshot-Automount-Race — Eine Race-Condition beim parallelen Mounten von Snapshots konnte einen AVL-Tree-Panic auslösen. Gelöst durch Umstellung auf AVL-Lookup statt Linear-Scan.
Zusätzlich gab es einen Fix für einen Memory Leak in zfsctl_snapshot_mount — die Options-Struktur wurde nicht korrekt freigegeben.
Für alle, die zfs recv im Betrieb nutzen (und das sollte jeder tun, der Replication einsetzt), sind diese Fixes relevant. Der Deadlock trat in der Praxis auf, wie ein offener Issue (#18073) zeigt.
BastilleBSD plant Einstellung
BastilleBSD hat Pläne angekündigt, einen teilzeit FreeBSD/Bastille-Sysadmin (ca. 20 Std./Woche) einzustellen — Fokus auf EMEA/APAC-Zeitzonen. Der Start ist für Mitte/Ende 2026 geplant, in Zusammenarbeit mit dem Bastille-Gründer an einem Cybersecurity-Startup. Ein Zeichen dafür, dass das Jail-Management-Ökosystem professionalisiert wird.
TopBar: Desktop-Umgebung für Wayland
Auf DiscoverBSD wurde TopBar vorgestellt — eine anpassbare Desktop-Umgebung, die mit Quickshell und QML für Wayland-Compositoren wie MangoWM und Hyprland gebaut wird. Sie integriert Statusleiste, App-Launcher, Lockscreen und Wallpaper-Management in ein einziges kohärentes System. Für FreeBSD-Laptop-Nutzer, die Wayland nutzen wollen, eine interessante Entwicklung.
ZFS Performance-Optimierung ohne neue Hardware
Ein Artikel auf DiscoverBSD fasst ZFS-Performance-Tipps zusammen, die ohne Hardware-Investitionen auskommen:
Recordsize an Workload anpassen (16K für Datenbanken, 1M–4M für Storage)
LZ4-Kompression aktivieren — reduziert oft I/O-Overhead statt ihn zu erhöhen
Pool-Topologie: Breite RAIDz-Konfigurationen durch gespiegelte VDEVs ersetzen für mehr Parallelität
Prefetch deaktivieren bei Random-Access-Workloads (Datenbanken)
Nichts Neues für ZFS-Veteranen, aber eine brauchbare Zusammenfassung für Einsteiger.
Was diese Woche bedeutet
Zwei kritische SAs in einer Woche, beide von KI-gestütztem Fuzzing entdeckt — das ist ein Weckruf. Die Werkzeuge werden besser, und die Angreifer nutzen sie auch. Der Q1-Statusbericht zeigt ein gesundes Projekt: Laptop-Support wächst, HPC kommt an, die CRA-Vorbereitung ist professionell. Und mit dem Code Slush für 15.1 rückt die nächste Release näher.
Wer noch auf 13.5 sitzt: Jetzt upgraden. Wer 15.0 oder 14.4 läuft: Jetzt patchen. Alles andere ist fahrlässig.
Docker ist überall. Jedes Tutorial, jeder Workshop, jeder Stack-Overflow-Thread — alles dreht sich um Container. Und ehrlich: Das hat Gründe. Docker hat die Bereitstellung von Software radikal vereinfacht. Aber hier ist die unbequeme Frage, die sich kaum jemand stellt: Was macht Docker eigentlich, das ein Betriebssystem nicht schon kann?
Die Antwort, die ich im Lauf der Jahre gefunden habe, lautet: Erstaunlich wenig — wenn das Betriebssystem FreeBSD heißt.
Dieser Artikel ist mein Versuch, die Diskussion über Container-Isolation neu aufzurollen — nicht als Docker-Bashing, sondern als ehrlicher technischer Vergleich zwischen zwei Philosophien, die das gleiche Problem auf grundverschiedene Weise lösen.
Was ist ein Jail?
Ein FreeBSD-Jail ist, auf den Punkt gebracht, ein chroot mit Netzwerk. Und das ist nicht abwertend gemeint — es ist die präzise Beschreibung.
Wenn du unter Linux chroot /mein/verzeichnis ausführst, hast du einen Prozess, der ein anderes Dateisystem-Root sieht. Aber er teilt sich den Kernel, die Netzwerk-Interfaces, die Prozess-Tabelle, die User-IDs — alles. Ein chroot isoliert das Dateisystem, aber sonst nichts. Deswegen heisst es auch nicht umsonst chroot — change root, nicht isolate.
Ein Jail geht weiter. Viel weiter. Ein Jail-Prozess bekommt:
Ein eigenes Dateisystem-Root (wie chroot)
Ein eigenes Netzwerk-Interface (eigene IP, eigener Hostname)
Eine eigene Prozess-Tabelle (Prozesse im Jail sehen nur andere Prozesse im Jail)
Eigene User-IDs (root im Jail ist nicht root auf dem Host)
Eigene Netzwerk-Stacks (eigene Ports, eigene Firewall-Regeln möglich)
Und das alles ohne einen Hypervisor. Ohne Virtualisierung. Ohne Emulation. Der Kernel läuft weiter — ein einziger Kernel, der die Isolation direkt bereitstellt, und das als Design.
Das war’s. Kein Dockerfile. Kein Build-Kontext. Keine Registry. Ein Befehl, und du hast einen isolierten Prozess, der in seinem eigenen Teil des Systems läuft.
Jails existieren seit dem Jahr 2000. Sie waren da, als Linux noch über chroot stolperte und Container ein Konzept war, das man in Vorlesungen über Betriebssysteme erwähnte. FreeBSD hat das Problem der Prozessisolation vor über 25 Jahren im Kernel gelöst — und die Lösung ist bis heute stabil, sicher und geradezu banal einfach.
Docker-Anatomie: Der Zoo
Lass uns einen Schritt zurücktreten und anschauen, was Docker eigentlich ist. Nicht die Marketing-Version. Die echte Architektur.
Docker besteht aus:
dockerd — Ein Daemon, der im Hintergrund läuft und alle Container verwaltet. Er hat Root-Rechte. Er lauscht auf einem Socket. Er ist ein Single Point of Failure und ein Single Point of Compromise.
Docker Registry — Docker Hub (oder eine private Registry), wo Images gespeichert werden. Du pullst Images, du pushst Images. Du hängst an der Verfügbarkeit einer externen Infrastruktur.
Image Layers — Jedes Image besteht aus Schichten. Jede Schicht ist ein diff über der vorherigen. Das macht Images transportabel, aber es erzeugt einen ganzen Stack von Overlay-Dateisystemen, der zur Laufzeit übereinander gelegt wird.
Dockerfile — Ein eigenes Build-Format mit eigener Syntax. FROM, RUN, COPY, ENTRYPOINT. Ein Mini-Package-Manager-Ökosystem in Textform.
Eigener Package-Manager — apk in Alpine, apt in Debian-Images, oft gemischt. Docker hat keinen eigenen Package-Manager, aber es zwingt dich, den der Base-Distribution zu nutzen — innerhalb eines Build-Contexts, der isoliert vom Rest deines Systems ist.
Docker Compose — Weil ein Container selten allein kommt. Du brauchst ein YAML-File, um mehrere Container zu orchestrieren. Compose ist de facto ein eigenes Tool mit eigener Syntax und eigenen Konventionen.
Swarm / Kubernetes — Weil Compose nicht für Produktion reicht. Swarm ist praktisch tot. Kubernetes ist… Kubernetes. Ein eigenes Ökosystem mit eigenem Vokabular, eigenen Konzepten, eigener Komplexität.
Das ist ein ganzer Zoo. Und ich meine das nicht nur umgangssprachlich. Docker hat sich von einem Tool zur Prozessisolation zu einer Plattform entwickelt, die ein eigenes Betriebssystem innerhalb deines Betriebssystems aufbaut. Eigene Networking-Lösung. Eigene Storage-Treiber. Eigene Build-Pipeline. Eigene Orchestrierung.
Wenn du Docker einsetzt, betreibst du ein Schichtenmodell:
Jede Schicht hat ihre eigenen Fehlerquellen, ihre eigenen Konfigurationsmöglichkeiten, ihre eigenen Bugs. Und jede Schicht nimmt dir Kontrolle ab und gibt dir Abstraktion. Ob das ein fairer Trade ist, hängt davon ab, was du brauchst. Aber es ist ein Trade — und den sollte man mit offenen Augen machen.
Jail-Anatomie: Das, was übrig bleibt, wenn man alles weglässt
Jetzt der Kontrast. Ein FreeBSD-Jail besteht aus:
Kernel-Isolation — Der FreeBSD-Kernel bietet Isolation direkt an. Kein Daemon dazwischen. Keine Runtime. Der Kernel ist die Runtime.
Netzwerk-Isolation — Jedes Jail bekommt sein eigenes IP-Interface. Kein NAT nötig (aber möglich). Kein Bridge-Netzwerk, das du erst verstehen musst. Einfach eine IP, und der Traffic kommt an.
Dateisystem-Isolation — Das Jail-Root ist ein Verzeichnis. Alles darunter gehört zum Jail. Alles außerhalb existiert für Prozesse im Jail nicht.
Und das war’s. Kein Daemon. Keine Registry. Keine Layer. Kein Build-System. Keine YAML-Datei mit 40 Zeilen, um drei Services zu starten.
Das ist die komplette Konfiguration. Kein YAML. Keine Environment-Variablen, die durch drei Dateien gereicht werden. Keine Networks, die du erst definieren musst. Die Konfiguration ist lesbar, greifbar, debuggbar.
Wenn etwas schiefgeht, greifst du auf die Standard-FreeBSD-Tools zurück. ps, top, sockstat, dmesg — alles funktioniert wie gewohnt, weil es ein echtes System ist, kein Container-Abstraktionslayer.
Die ZFS-Verbindung: Instant-Cloning
Hier wird es spannend. FreeBSD und ZFS sind ein Traumpaar — und Jails profitieren davon massiv.
Stell dir vor, du willst eine neue Instanz deiner Web-Anwendung aufsetzen. Mit Docker: Image pullen, Container starten. Mit Jail und ZFS geht etwas viel Eleganters:
# Snapshot des Basis-Jails erstellen
zfs snapshot zroot/jails/base@clean
# Klonen — dauert Sekundenbruchteile, dank Copy-on-Write
zfs clone zroot/jails/base@clean zroot/jails/webapp2
# Jail konfigurieren und starten
# (Eintrag in /etc/jail.conf)
jail -c webapp2
Das war’s. Der Clone ist da. Sofort. Kein Download. Kein Layer-Aufbau. Kein Caching. ZFS nutzt Copy-on-Write, also belegt der Clone initially keinen zusätzlichen Speicherplatz. Erst wenn sich Dateien zwischen Clone und Original unterscheiden, wird Platz belegt.
Und das Beste: Du kannst das automatisieren. Ein kleines Skript, das einen ZFS-Snapshot nimmt, klont, die Jail-Konfiguration anpasst, und fertig. Kein CI/CD-Pipeline nötig, die ein Docker-Image baut und pusht. Du kannst es natürlich trotzdem tun — aber du musst nicht.
pkgbase: Sauberes Base-System-Management
FreeBSD bietet seit einiger Zeit pkgbase — Pakete für das Base-System. Das bedeutet, du kannst das FreeBSD-Base-System innerhalb eines Jails wie jedes andere Paket aktualisieren:
Statt freebsd-update in jedem Jail laufen zu lassen oder das Base-System manuell zu bauen, kannst du Versionierte, reproduzierbare Base-System-Pakete nutzen. In Kombination mit ZFS-Snapshots bedeutet das: Du kannst ein Jail auf eine bestimmte Base-Version zurückrollen, ohne dass irgendwelche Overlay-Layer involviert sind.
Das ist reproduzierbar. Das ist transparent. Das ist genau das, was Docker mit seinen Layer-Caching verspricht, aber tatsächlich nur mühsam nachbaut.
Praktischer Vergleich: Eine Web-Anwendung deployen
Lass uns das konkret machen. Wir wollen eine typische Web-Anwendung deployen: Nginx als Reverse Proxy, eine App (sagen wir: eine Go-Binary), und PostgreSQL als Datenbank.
Image-Layer-Caching führt zu veralteten Abhängigkeiten
Der Docker-Daemon muss laufen
Netzwerk zwischen Containern ist ein Bridge-Netzwerk mit eigenen Eigenheiten
Volumes werden vergessen oder falsch gemountet
Environment-Variablen müssen durchgereicht werden
Image-Grösse bläht auf, weil jeder Layer seinen eigenen Overhead hat
Mit FreeBSD-Jails
ZFS-Dataset für das Jail erstellen — zfs create zroot/jails/webapp
Base-System installieren — pkgbase oder bsdinstall oder aus einem Snapshot klonen.
Jail konfigurieren — Eintrag in /etc/jail.conf. 10 Zeilen.
Pakete installieren — Im Jail: pkg install nginx postgresql16-server. Oder du installierst deine Go-Binary direkt per scp oder pkg install.
Services konfigurieren — Standard FreeBSD-Konfiguration. /etc/rc.conf im Jail, Nginx-Konfig, PostgreSQL-Konfig.
Jail starten — service jail start webapp
Prüfen — jls, jexec webapp ps aux, Standard-Logs unter /var/log
Fehlerquellen:
Konfigurationsfehler (wie überall)
Aber: Kein Daemon, der abstürzen kann
Kein Overlay-Filesystem, das korrumpiert
Keine Layer, die sich unerwartet verhalten
Netzwerk ist echtes Netzwerk — was du konfigurierst, ist was du bekommst
Der Unterschied ist nicht nur die Anzahl der Schritte. Es ist die Art der Komplexität. Bei Docker ist die Komplexität in der Toolchain. Bei Jails ist die Komplexität im System — aber das System ist transparent, dokumentiert, und verhält sich wie erwartet, weil es ein echtes Betriebssystem ist, kein Abstraktionslayer.
Security: Isolation per Design vs. Isolation nachgerüstet
Dies ist der Punkt, der mich am meisten bewegt.
FreeBSD-Jails existieren seit dem Jahr 2000. Sie wurden von Anfang an als Isolationsmechanismus designt. Die Sicherheitsgarantien sind Teil des Kernel-Designs:
Ein Prozess in einem Jail kann nicht auf Prozesse ausserhalb zugreifen.
Ein Prozess in einem Jail kann nicht Kernel-Module laden.
Ein Prozess in einem Jail kann nicht Netzwerk-Interfaces ausser seinem eigenen sehen.
root in einem Jail ist nicht root auf dem Host.
Diese Garantien sind nicht optional. Sie sind nicht ein Config-Flag, das du setzen kannst — oder vergessen kannst. Sie sind die Default-Annahme des Systems.
Docker? Docker lief jahrelang mit Containern, die als root liefen. Die Standard-Konfiguration gab Containern volle Root-Rechte auf dem Host. User-Namespaces wurden erst 2016 eingeführt — und waren jahrelang experimentell. Seccomp-Profile kamen hinzu, aber die Standard-Profile waren lasch und komplexe Profile waren schwer zu schreiben. Capability-Dropping existiert, aber die meisten Container liefen (und laufen) mit zu vielen Capabilities.
Die Geschichte von Container-Security unter Linux ist eine Geschichte von Nachbesserungen. Jedes Jahr kamen neue Mechanismen hinzu: Namespaces, cgroups, Seccomp, AppArmor, SELinux, User-Namespaces, Rootless-Mode. Jeder einzelne Mechanismus ist sinnvoll. Aber zusammen ergeben sie ein Patchwork, das tiefes Expertenwissen erfordert, um es korrekt zu konfigurieren.
FreeBSD-Jails? Da gibt es nichts nachzurüsten. Die Isolation war 2000 da. Sie ist 2026 immer noch da. Und sie hat sich bewährt — in Produktion, in Hosting-Umgebungen, in Firmen, die seit Jahrzehnten Jails betreiben.
25 Jahre getestete Kernel-Isolation vs. ein Patchwork aus nachgerüsteten Linux-Mechanismen.
Ein konkretes Beispiel
Stell dir vor, ein Angreifer bekommt Shell-Zugriff in deinem Container.
Im Docker-Container (ohne User-Namespaces):
Der Angreifer ist root.
Er kann alle Prozesse im Container sehen.
Er kann Netzwerk-Verbindungen des Hosts potenziell sehen (je nach Konfiguration).
Er kann Capabilities ausnutzen, die der Container hat.
Escalation zum Host ist historisch wiederholt gelungen.
Im Jail:
Der Angreifer sieht nur Prozesse im Jail.
Er sieht nur das Netzwerk-Interface des Jails.
Selbst als root im Jail kann er nicht auf den Host zugreifen.
Escalation erfordert einen Kernel-Bug — und FreeBSD hat eine exzellente Security-Historie.
Der Unterschied ist architektonisch, nicht konfiguratorisch.
Performance: Direkter Zugriff vs. Layer-Stack
Performance ist nicht das wichtigste Argument für Jails — aber es ist ein schönes Nebenargument.
Ein Docker-Container läuft auf einem Overlay-Filesystem. Das bedeutet: Jeder Schreibzugriff geht durch einen Layer-Stack. OverlayFS (oder AUFS, oder Btrfs, oder Device Mapper — je nachdem, was du konfiguriert hast) muss bei jedem Dateizugriff prüfen, in welchem Layer die Datei liegt. Das kostet Zeit. Bei vielen kleinen Schreibzugriffen (Datenbanken, Logs) spürst du das.
Ein Jail läuft auf einem echten Dateisystem. ZFS, UFS — was immer du nutzt. Kein Overlay. Keine Layer-Auflösung. Direkter Zugriff. Punkt.
Dann der Daemon: Docker hat dockerd. Ein Prozess, der im Hintergrund läuft, Ressourcen verbraucht, und ein Angriffsziel ist. Jails haben keinen Daemon. Der Kernel macht die Isolation. Kein Prozess, der sterben kann. Kein Prozess, den du überwachen musst.
Und Layer-Caching? Docker macht viel Aufwand darum, Layer zwischen Images wiederzuverwenden. Das ist clever, aber es ist ein Workaround für ein Problem, das gar nicht existieren müsste. Mit ZFS und pkgbase hast du Copy-on-Write und geteilte Datasets. Gleicher Effekt, weniger Komplexität.
Die Zahlen sprechen für sich, auch wenn der Unterschied bei einfachen Workloads marginal ist:
Metrik
Docker
Jail
Startup-Zeit
0.5-3s
0.1-0.5s
Dateisystem-Overhead
Overlay-Layer
Nativ (ZFS/UFS)
Daemon-Overhead
Ja (dockerd)
Nein
Netzwerk-Overhead
Bridge/NAT
Nativ (direkt oder NAT)
Memory-Overhead
Container-Runtime
Nur Kernel
Bei hunderten von Jails/Containern macht das einen messbaren Unterschied. Bei ein paar dutzend ist es vernachlässigbar — aber es ist trotzdem ein Unterschied, der auf architektonischer Eleganz beruht, nicht auf Micro-Optimierung.
Wann Docker Sinn macht — und wann Jails die bessere Wahl sind
Ich bin kein Dogmatiker. Docker hat seinen Platz. Lass uns ehrlich sein:
Docker ist die bessere Wahl, wenn:
Du Microservices deployst, die von Dritten kommen. Wenn jemand ein Docker-Image bereitstellt, ist es einfacher, das zu nutzen, als es in ein Jail zu portieren.
Du in einem Team arbeitest, das Docker kennt. Das ist vielleicht das wichtigste Argument. Docker ist die Lingua franca der DevOps-Welt. Neue Kollegen kennen Docker. Jails müssen sie erst lernen.
Du Kubernetes brauchst. K8s ist das Standard-Orchestrierungstool. Es funktioniert mit Docker (oder containerd). Es gibt kein Äquivalent für Jails — und das wird es wahrscheinlich auch nie geben.
Du Cloud-native arbeitest. AWS, GCP, Azure — sie alle bieten native Docker-Unterstützung. FreeBSD-Jails auf AWS? Machbar, aber du bist auf dich gestellt.
Du schnelle Prototypen brauchst.docker run -it ubuntu bash ist schneller als ein Jail aufzusetzen — es sei denn, du hast einen ZFS-Snapshot bereit.
Jails sind die bessere Wahl, wenn:
Du dein eigenes Hosting betreibst. Eigener Server, eigenes Rechenzentrum, eigene Infrastruktur. Hier hast du die volle Kontrolle und kannst Jails optimal nutzen.
Du langfristige Stabilität willst. FreeBSD und Jails sind seit Jahrzehnten stabil. Keine Breaking Changes im Isolations-Modell. Kein Daemon, der updated werden muss.
Du Security ernst nimmst. Kernel-level Isolation statt nachgerüsteter Linux-Mechanismen. Kein Daemon mit Root-Rechten.
Du Einfachheit schätzt. Weniger Moving Parts. Weniger, was kaputtgehen kann. Standard-Betriebssystem-Werkzeuge statt eines ganzen Ökosystems.
Du ZFS nutzt. Die Kombination aus Jails und ZFS ist mächtiger als Docker je sein kann — Instant-Cloning, Snapshots, Replication, Deduplizierung. Alles nativ, alles integriert.
Du Vollständige Kontrolle willst. Über das Betriebssystem, über die Isolation, über die Netzwerk-Konfiguration. Jails geben dir die volle Macht des Betriebssystems, nicht die Teilmenge, die Docker freigibt.
Die ehrliche Wahrheit ist: Die meisten kleinen bis mittleren Deployments brauchen kein Kubernetes. Sie brauchen kein Docker-Ökosystem. Sie brauchen Isolation, Reproduzierbarkeit und Einfachheit. Und genau das bieten Jails.
Die Philosophie: FreeBSD vertraut dem Admin, Docker vertraut dem Workflow
Hier wird es philosophisch — und das ist der Kern meines Arguments.
Docker vertraut dem Workflow. Docker sagt: „Wir machen es einfach, Container zu bauen, zu „verschiffen“ und zu orchestrieren. Du musst nicht verstehen, wie das Betriebssystem funktioniert. Du musst verstehen, wie Docker funktioniert.“ Und das funktioniert — solange du in Dockers Workflow bleibst. Wenn du etwas ausserhalb des Workflows brauchst, wird es kompliziert. Eigene Netzwerk-Konfiguration? Da gibt es ein Plugin. Eigene Storage-Lösung? Da gibt es einen Volume-Treiber. Eigenes Orchestrierung? Da gibt es… naja, Kubernetes.
FreeBSD vertraut dem Admin. FreeBSD sagt: „Hier ist ein mächtiges Betriebssystem mit 30 Jahren Erfahrung. Hier sind die Werkzeuge. Du weisst, was du tust. Mach dein Ding.“ Jails sind ein Werkzeug im Werkzeugkasten, nicht das gesamte Werkzeugkasten-Inventar. Du kannst sie mit ZFS kombinieren, mit pf konfigurieren, mit Ansible automatisieren, mit devfs feinabstimmen. Alles ist kombinierbar, weil alles Teil desselben Betriebssystems ist.
Das ist ein fundamentaler Unterschied in der Design-Philosophie:
Docker abstrahiert das Betriebssystem weg. Der Container ist die Einheit. Das Betriebssystem darunter ist ein Implementierungsdetail.
FreeBSD gibt dir das Betriebssystem als Plattform. Der Jail ist ein Feature des Betriebssystems, kein Ersatz dafür.
Beide Ansätze haben ihre Berechtigung.
Wenn du ein Linux-Admin bist, der Docker nutzt, kennst du das Gefühl: „Warum funktioniert dieser Container lokal, aber nicht in Produktion?“ Overlay-Filesystem-Unterschiede. Netzwerk-Konfiguration. Environment-Variablen. Volume-Mounts. Jede Schicht kann ein Problem sein.
Mit Jails? Wenn es im Jail funktioniert, funktioniert es. Weil das Jail ein echtes Betriebssystem ist. Keine Überraschungen.
Die Sache mit dem Ökosystem
Ein Argument, das oft gegen Jails vorgebracht wird: „Docker hat ein riesiges Ökosystem. Jails haben das nicht.“
Stimmt. Docker Hub hat Millionen von Images. Für Jails gibt es keine zentrale Registry.
Aber lass uns ehrlich sein: Wie viele dieser Millionen Images nutzt du wirklich? Und wie viele davon sind veraltet, unsicher, oder einfach schlechte Basis-Images?
In der Praxis brauchst du eine Handvoll gut gepflegter Basis-Images. Und die kannst du dir mit Jails leicht selbst bauen. Ein ZFS-Snapshot eines sauberen FreeBSD-Base-Systems, und du hast dein eigenes „Image“ — reproduzierbar, versioniert, effizient.
Ausserdem: Die Abhängigkeit von Docker Hub ist ein Risiko. Images verschwinden. Tags werden überschrieben. Die Registry kann ausfallen. Mit einem eigenen ZFS-basierten Jail-Setup bist du unabhängig.
Und was Automatisierung angeht: Tools wie Ansible, Salt, oder einfache Shell-Skripte arbeiten mit Jails genauso gut wie mit Docker. Vielleicht nicht so elegant wie ein docker-compose up, aber dafür transparent und nachvollziehbar.
Der praktische Betrieb: Jails im Alltag
Lass mich einen typischen Arbeitsablauf beschreiben, wie ich ihn auf meinen Servern nutze:
Ein Befehl. Das gesamte Jail — Dateisystem, Konfiguration, alles — wird auf den neuen Server übertragen. Inkrementelle Updates? zfs send -i mit Snapshots. Effizient, schnell, zuverlässig.
Vergleiche das mit docker save und docker load. Oder mit einer Registry. Oder mit docker-compose und Environment-Variablen, die du manuell übertragen musst. ZFS send/recv ist eleganter, weil es auf Dateisystem-Ebene arbeitet — und weil es von einem Werkzeug stammt, das seit 2005 in Produktion ist.
Was Docker besser macht (und warum das okay ist)
Ich will fair sein. Docker hat Dinge, die Jails nicht bieten:
Portabilität. Ein Docker-Image läuft auf jedem Linux-System mit Docker. Ein Jail läuft nur auf FreeBSD. Wenn du heterogene Infrastruktur hast, ist Docker die bessere Wahl.
Ökosystem. Docker Hub, Docker Compose, Docker Swarm, Kubernetes — das Ökosystem ist riesig und gut dokumentiert. Für Jails gibt es Bastille und pot, aber sie sind kein K8s.
Entwickler-Workflow.docker build und docker push sind etabliert. CI/CD-Pipelines unterstützen Docker nativ. Jails erfordern mehr manuelle Arbeit in der Pipeline.
Cloud-Integration. Jeder Cloud-Provider bietet native Container-Support. FreeBSD-Jails musst du selbst betreiben.
Aber — und das ist wichtig — diese Vorteile sind Ökosystem-Vorteile, keine technischen Vorteile. Docker ist populärer, nicht besser isoliert. Docker hat mehr Werkzeuge, nicht sicherere Isolation. Docker ist bequemer, nicht performanter.
Wenn du dich für Docker entscheidest, tust du das wegen des Ökosystems, nicht wegen der Technologie. Und das ist eine legitime Entscheidung — solange du dir bewusst bist, dass es eine Entscheidung für Bequemlichkeit und gegen Einfachheit ist.
Die Philosophie (nochmal, tiefer)
Ich möchte nochmal auf die Philosophie zurückkommen, weil sie mich nicht loslässt.
Die Container-Bewegung hat einen wichtigen Punkt gebracht: Prozesse sollten isoliert sein. Das ist richtig. Das ist gut. Das ist etwas, das FreeBSD seit dem Jahr 2000 weiss.
Aber die Container-Bewegung hat auch etwas mitgebracht, das weniger gut ist: Die Idee, dass das Betriebssystem ein Implementierungsdetail ist. Dass du Container brauchst, weil das Betriebssystem nicht gut genug ist. Dass du Docker brauchst, weil Linux nicht von sich aus isolieren kann.
Und hier ist die Ironie: Linux kann isolieren. Mit Namespaces, cgroups, Seccomp. Aber Linux hat sich entschieden, diese Mechanismen als Bausteine anzubieten, die du zusammensetzen musst — und das hat Docker übernommen. Docker ist der Wrapper, der die Bausteine zusammensteckt.
FreeBSD hat sich anders entschieden. FreeBSD hat die Isolation in den Kernel gebaut, als zusammenhängendes Konzept. Nicht als Bausteine. Sondern als Design. Und das Resultat ist einfacher, sicherer und leichter zu verstehen.
FreeBSD vertraut dem Admin. Der Admin weiss, was er tut. Er braucht keinen Daemon, der ihm die Isolation abnimmt. Er braucht einen Kernel, der Isolation bereitstellt, und Werkzeuge, die transparent sind.
Docker vertraut dem Workflow. Der Workflow weiss, was gut für dich ist. Du brauchst nicht zu verstehen, wie die Isolation funktioniert. Du musst nur docker run tippen.
Beide Philosophien haben ihren Platz. Aber wenn du ein Admin bist, der sein System versteht — und das bist du, wenn du diesen Artikel liest —, dann weisst du, welche Philosophie dir mehr gibt.
Fazit: Container-Infrastruktur, wenn man das Betriebssystem ernst nimmt
Container sind keine schlechte Idee. Prozessisolation ist essenziell. Aber die Art und Weise, wie Docker sie implementiert — mit einem Daemon, mit Layern, mit einer Registry, mit einem ganzen Ökosystem — ist nicht die einzige Art, Isolation zu erreichen. Und sie ist für viele Use-Cases nicht die beste.
FreeBSD-Jails bieten Isolation auf Kernel-Ebene, seit über 25 Jahren. Ohne Daemon. Ohne Registry. Ohne Layer. Ohne Komplexität. In Kombination mit ZFS bieten sie Instant-Cloning, atomare Updates, und effiziente Migration — alles mit Standard-Betriebssystem-Werkzeugen.
Wenn du dein Betriebssystem ernst nimmst — wenn du weisst, was unter der Haube passiert, wenn du Kontrolle über Einfachheit bevorzugst, wenn du Stabilität über Hype wählst —, dann sind Jails die bessere Wahl. Nicht immer. Nicht für jeden. Aber für die meisten, die ihre eigene Infrastruktur betreiben und wissen, was sie tun.
Docker hat die Container-Welt revolutioniert. Das bestreite ich nicht. Aber Revolution bedeutet nicht, dass das Alte obsolet ist. Manchmal bedeutet es nur, dass das Alte vergessen wurde.
Jails sind nicht vergessen. Sie sind gereift. Sie sind bewährt. Und sie warten darauf, von Leuten genutzt zu werden, die Einfachheit über Komplexität wählen.
Die Frage ist nicht: „Warum Jails statt Docker?“
Die Frage ist: „Warum Docker, wenn Jails alles können, was du brauchst — und weniger mitbringen, was du nicht brauchst?“
Zehn Jahre lang war die Antwort auf fast jede IT-Frage dieselbe: Cloud. Neue Applikation? Cloud. Altes System migrieren? Cloud. Storage wächst? Cloud. Skalierung nötig? Cloud. Die Cloud war nicht nur eine Technologie — sie war eine Ideologie. „Cloud-first“ stand in den Strategiepapieren von Unternehmen, die nicht einmal verstanden hatten, was „first“ in diesem Kontext bedeutet.
Jetzt, zehn Jahre später, kommt die Ernüchterung. Nicht bei allen, aber bei vielen. Die Rechnungen sind da. Die Abhängigkeiten sind da. Die Fragen, die man hätte stellen sollen, bevor man migriert hat, sind immer noch da — nur dass sie jetzt teurer zu beantworten sind.
Einleitung
Die Migration in die Cloud war die dominierende IT-Strategie der letzten Dekade. Getrieben von Versprechen wie „unbegrenzter Skalierung“, „pay-as-you-go“ und „Zero Administration“ haben Unternehmen aller Größen Systeme, Daten und Prozesse in die Cloud verlagert — oft ohne die langfristigen Konsequenzen zu verstehen.
Heute beginnt eine Gegenbewegung. Nicht weil die Cloud gescheitert ist — sie hat ihre Vorteile —, sondern weil die Unternehmen, die in den letzten Jahren massiv in die Cloud gewandert sind, feststellen, dass die versprochene Einfachheit mit einem Preis kommt, der nicht nur finanziell ist.
Die Frage ist nicht mehr: „Cloud oder nicht?“ Die Frage ist: „Wofür Cloud, wofür On-Premise, und wie beides so kombinieren, dass die Souveränität über die eigenen Daten und Prozesse erhalten bleibt?“
Die Cloud-Revolution — und was sie wirklich verändert hat
Was die Cloud versprach
Die Argumente für die Cloud waren — und sind — attraktiv:
Skalierung. Mehr Last? Ein paar Klicks, und die Ressourcen sind da. Keine neue Hardware bestellen, kein Rack einbauen, kein Kabel ziehen. Die Cloud skaliert theoretisch unbegrenzt, und diese Skalierung ist innerhalb von Minuten verfügbar, nicht Wochen oder Monaten.
Geschwindigkeit. Eine neue Instanz starten, ein neues Deployment ausrollen, einen neuen Service aufsetzen — in der Cloud geht das in Minuten. On-Premise brauchte früher Tage oder Wochen für Hardware-Beschaffung und Einrichtung. In der Cloud ist alles sofort verfügbar.
Weniger Betriebsaufwand. Keine Server, die man warten muss. Keine Klimaanlage im Serverraum. Keine Hardware-Reparaturen am Freitagabend. Keine Ersatzteil-Lieferketten. Der Cloud-Provider kümmert sich um alles — Strom, Kühlung, Hardware, Netzwerk, physische Sicherheit.
Kapex vs. Opex. Statt hoher Investitionskosten (Capital Expenditure) für Hardware gibt es monatliche Betriebskosten (Operational Expenditure). Das ist für die Finanzabteilung attraktiv: planbare Kosten, keine Abschreibungen, keine Restwerte.
Managed Services. Datenbanken, Message Queues, Container-Orchestrierung, Authentication — alles als Service verfügbar. Kein Betrieb, keine Patches, keine Skalierungssorgen. Der Provider macht das.
Was die Cloud wirklich verändert hat
Die Cloud hat die Einstiegshürde massiv gesenkt. Das ist ihr größter Verdienst. Startups können heute innerhalb von Stunden eine Produktionsinfrastruktur aufbauen, die früher Wochen gedauert hätte. Kleine Unternehmen können auf Enterprise-Grade-Services zugreifen, ohne Enterprise-Grade-Personal zu brauchen.
Aber die Cloud hat auch die Wahrnehmung von IT-Kosten verzerrt. Die monatliche Rechnung fühlt sich anders an als eine einmalige Hardware-Investition — aber über drei bis fünf Jahre gerechnet ist sie oft teurer. Viel teurer. Und das ist nicht die einzige Überraschung.
Die Nachteile — die Rechnung kommt
Kostenentwicklung
Die Cloud ist billig, wenn man klein anfängt. Und sie wird teuer, wenn man wächst. Nicht linear teuer — exponentiell teuer.
Daten-Egress. Daten in die Cloud zu schicken ist kostenlos. Daten aus der Cloud herauszuholen kostet Geld. Das ist kein Zufall — es ist das Geschäftsmodell. AWS berechnet $0.09 pro GB für Daten-Transfer nach draußen. Bei einem Terabyte sind das $90. Bei zehn Terabyte $900. Und das ist nicht die einmalige Migration — das ist jede Replikation, jeder Backup-Restore, jeder Datenabgleich.
Storage-Kosten. S3-Storage kostet $0.023 pro GB und Monat (Standard-Tier). Das klingt wenig. Bei 50 TB sind das $1.150 pro Monat. Bei 500 TB — und das ist für mittelständische Unternehmen keine ungewöhnliche Größenordnung — sind es $11.500 pro Monat. $138.000 pro Jahr. Für Storage. Ohne Compute, ohne Netzwerk, ohne Managed Services.
Compute-Kosten. Eine m5.xlarge-Instanz bei AWS kostet ca. $0,192 pro Stunde. Das sind $1.682 pro Jahr. Eine vergleichbare Dedizierte-Server-Miete kostet ca. $200–400 pro Jahr. Faktor 4–8. Und bei Dediziert-Servern ist die Rechenleistung garantiert, nicht geteilt mit anderen Instanzen auf derselben Hardware.
Lizenz-Kosten. Microsoft-Lizenzen in der Cloud sind oft teurer als on-prem. Oracle-Lizenzen in der Cloud sind ein Albtraum. Red Hat Subscriptions in der Cloud kosten mehr als on-prem. Die Cloud macht Softwarelizenzen nicht billiger — sie macht sie teurer, weil die Cloud-Provider ihre Margen draufschlagen.
Der Faktor 3–10. Studien von 451 Research, IDC und mehreren Cloud-Financial-Management-Firmen zeigen konsistent: Über einen Zeitraum von 3–5 Jahren sind Cloud-Kosten für dauerhaft laufende Workloads 3- bis 10-mal höher als vergleichbare On-Premise-Kosten. Das gilt nicht für kurzlebige Workloads, nicht für Burst-Szenarien, nicht für Startups in der Wachstumsphase — aber für den typischen Dauerbetrieb mittelständischer und großer Unternehmen.
Vendor Lock-in
Die Cloud ist wie ein Hotel: Check-in ist einfach. Check-out ist das Problem.
Proprietäre Services. Wer AWS Lambda, DynamoDB, S3 Event Notifications, SQS, SNS und CloudFormation einsetzt, hat eine Architektur gebaut, die auf AWS funktioniert — und nur auf AWS. Die Migration weg davon ist nicht nur technisch aufwendig, sie ist organisatorisch eine Katastrophe, weil jede Komponente berührt werden muss.
Datenformate. Selbst wenn die Daten theoretisch portabel sind — SQL ist SQL, oder? —, sind die Unterschiede zwischen AWS Aurora, Google Cloud SQL und Azure Database für PostgreSQL substanziell genug, dass eine Migration kein einfacher Dump/Restore ist.
Operational Lock-in. Wer CloudFormation, Terraform-Provider-spezifische Module oder AWS CDK einsetzt, hat Infrastruktur-Code, der nicht portabel ist. Die IaC-Abstraktion, die eigentlich Unabhängigkeit schaffen sollte, ist selbst abhängig vom Provider.
Vertragsstrukturen. Reserved Instances, Savings Plans, Enterprise Agreements — die Vertragsstrukturen der Cloud-Provider sind darauf ausgelegt, Kunden langfristig zu binden. Der Rabatt für ein 3-Jahres-Commitment ist attraktiv, aber er bedeutet: Drei Jahre lang bezahlt man für Ressourcen, unabhängig davon, ob man sie noch braucht.
Datenhoheit
Wer seine Daten in der Cloud hat, hat sie nicht. Der Cloud-Provider hat sie. Und der Cloud-Provider hat eine Rechtsordnung, der er unterliegt.
Cloud Act. Der US-Cloud-Act von 2018 ermächtigt US-Behörden, Daten von US-Unternehmen auch dann einzufordern, wenn die Daten in einem Rechenzentrum außerhalb der USA liegen. AWS, Azure und Google sind US-Unternehmen. Das bedeutet: Daten, die bei diesen Providern liegen — egal ob in Frankfurt, Tokio oder Sydney — können von US-Behörden angefordert werden, ohne dass der Kunde davon erfährt.
GDPR. Die DSGVO verlangt, dass personenbezogene Daten in der EU verarbeitet werden oder ein angemessenes Schutzniveau besteht. Der EU-US Data Privacy Framework ist die aktuelle Lösung — aber er ist ein politisches Abkommen, kein technisches. Und er kann, wie sein Vorgänger (Privacy Shield), jederzeit für ungültig erklärt werden.
Datenzugriff durch Provider. Die AGB der großen Cloud-Provider erlauben ihnen Zugang zu Kunden-Daten in bestimmten Fällen — etwa bei Verdacht auf Missbrauch oder auf Anordnung eines Gerichts. Die Verschlüsselung der Daten ändert daran nichts, wenn der Provider die Schlüssel verwaltet.
Souveränität ist kein theoretisches Konzept. Für Unternehmen im öffentlichen Sektor, im Gesundheitswesen, in der Finanzindustrie und in kritischen Infrastrukturen ist Datenhoheit keine Frage der Präferenz, sondern der regulatorischen Pflicht. Wer Patientendaten, Finanzdaten oder Regierungsdaten in einer US-Cloud speichert, riskiert nicht nur Bußgelder — er riskiert den Entzug der Betriebserlaubnis.
Datenschutz
Datenschutz ist nicht dasselbe wie Datenhoheit. Datenhoheit fragt: Wer kann rechtlich auf meine Daten zugreifen? Datenschutz fragt: Wie schütze ich meine Daten vor unbefugtem Zugriff?
In der Cloud teilt man die Verantwortung mit dem Provider. Das „Shared Responsibility Model“ von AWS, Azure und Google ist klar definiert: Der Provider sichert die Infrastruktur, der Kunde sichert die Daten. Aber in der Praxis bedeutet das:
Der Provider hat physischen Zugriff auf die Hardware.
Der Provider kontrolliert das Hypervisor-Management.
Der Provider kann Memory-Dumps erstellen.
Der Provider hat Zugriff auf verschlüsselte Daten, wenn die Entschlüsselung in der Cloud stattfindet.
Das ist kein Misstrauen gegen die Provider. Es ist die Anerkennung einer Tatsache: Wer die Schlüssel nicht selbst verwaltet, hat keine volle Kontrolle über den Zugriff. Und „volle Kontrolle“ ist genau das, was Datenschutz in vielen Szenarien verlangt.
On-Premise ist nicht tot
Die Proklamation „On-Premise ist tot“ war die am häufigsten wiederholte Unwahrheit der letzten zehn Jahre. On-Premise war nie tot. On-Premise war nur nicht mehr sexy.
Was sich geändert hat
On-Premise bedeutet nicht mehr: Ein kalter Keller, ein Rack, ein überlasteter Administrator. Moderne On-Premise-Infrastruktur sieht anders aus:
Infrastructure as Code. Ansible, Terraform, Salt, Puppet — die gleichen Tools, die in der Cloud verwendet werden, funktionieren on-prem. Die Konfiguration ist versioniert, reproduzierbar, automatisiert. Der Unterschied zwischen Cloud und On-Premise ist nicht mehr die Automatisierung — es ist nur noch der Ort, wo die Hardware steht.
Virtualisierung ist gereift. Proxmox, bhyve, KVM — moderne Virtualisierungslösungen bieten Snapshots, Live-Migration, Resource-Pooling und Hochverfügbarkeit. Der Funktionsumfang ist mit Cloud-Virtualisierung vergleichbar, nur dass man die Hardware selbst kontrolliert.
ZFS. ZFS als Storage-Grundlage bietet Datenintegrität, Snapshots, inkrementelle Replikation, Kompression und Caching — alles, was man für robusten On-Premise-Storage braucht. ZFS macht den Unterschied zwischen „ein Filesystem“ und „ein Storage-Management-System“.
Container. Docker, Podman, Kubernetes on-prem — Container laufen nicht nur in der Cloud. Ein On-Premise-Kubernetes-Cluster mit Terraform-Provisioning und Ansible-Konfiguration ist kein Hexenwerk mehr.
Automatisches Patching. FreeBSD mit pkgbase, Ubuntu mit unattended-upgrades, Red Hat mit auto-updates — die Automatisierung von Security-Patches ist on-prem genauso möglich wie in der Cloud.
Stabilität
On-Premise-Infrastruktur ist stabil, wenn sie richtig gebaut ist. „Richtig gebaut“ heißt:
ZFS mit Redundanz. Mirror oder RAID-Z vdevs, reguläre Scrubs, Snapshots, Replikation auf einen zweiten Server.
CARP oder keepalived für Hochverfügbarkeit. Automatisches Failover bei Server-Ausfall.
Monitoring. Prometheus, Grafana, Alertmanager — die gleichen Tools wie in der Cloud.
Proaktive Wartung. ZFS-Scrubs wöchentlich, Smart-Monitoring für Disk-Failures, Firmware-Updates planvoll, nicht panisch.
Die Unterscheidung ist wichtig: Instabile On-Premise-Infrastruktur ist kein Argument gegen On-Premise. Es ist ein Argument gegen instabile Infrastruktur.
Sicherheit
On-Premise ist sicherer als die Cloud — wenn man die Security-Kontrolle nutzt, die man hat. In der Cloud gibt man physische Sicherheit und Netzwerk-Sicherheit an den Provider ab. On-Premise behält man beides:
Physische Kontrolle. Der Server steht im eigenen Rack. Kein fremder Administrator hat Zugriff. Kein Cloud-Provider-Mitarbeiter kann ein Image erstellen.
Netzwerk-Kontrolle. Die Firewall ist die eigene Firewall. Die Netzwerkstruktur ist die eigene Netzwerkstruktur. Es gibt keinen Shared-Tenant-Netzwerk-Pfad, über den ein anderer Cloud-Kunde Angriffe durchführen kann.
Verschlüsselung. Daten können on-prem verschlüsselt werden, mit eigenen Schlüsseln, eigener Verwaltung, eigenem KMS. Die Entschlüsselung findet auf der eigenen Hardware statt, nicht auf einem Server, der einem US-Konzern gehört.
Kosteneffizienz
Die Rechnung ist einfach, wenn man sie ehrlich macht:
Hardware-Anschaffung. Ein Server mit 256 GB RAM, 2x 1 TB NVMe und 4x 8 TB HDD kostet ca. 8.000–15.000 € — je nach Spezifikation. Geschrieben über 5 Jahre: 1.600–3.000 € pro Jahr.
Strom und Kühlung. Ca. 500–1.500 € pro Jahr pro Server, je nach Effizienz.
Netzwerk und Housing. Wenn man nicht selbst hostet: Colocation kostet ca. 100–300 € pro Monat pro HE. 1.200–3.600 € pro Jahr.
Personal. Das ist der größte Kostenfaktor — aber das Personal braucht man in der Cloud auch. Cloud-Infrastruktur managt sich nicht selbst.
Vergleich: Dieselbe Rechenleistung und denselben Storage in der Cloud kosten — konservativ geschätzt — 30.000–80.000 € pro Jahr. Bei wachsendem Storage-Volumen wird der Unterschied größer, nicht kleiner.
Der Break-Even liegt typischerweise bei 18–24 Monaten. Danach ist On-Premise günstiger. Und der Kostenvorteil wächst, weil die Hardware bezahlt ist, während die Cloud-Rechnung jeden Monat kommt.
Wann Cloud sinnvoll ist
Die Cloud ist nicht schlecht. Sie ist das falsche Default.
Cloud ist sinnvoll, wenn:
Burst-Workloads. Lastspitzen, die unvorhersehbar sind und kurzfristig viel Ressourcen brauchen. Black Friday, eine virale Kampagne, ein einmaliger Daten-Processing-Job. Die Cloud kann in Minuten skalieren und danach wieder schrumpfen. On-Premise muss die Hardware für den Worst Case vorhalten.
Prototyping und MVPs. Wenn man nicht weiß, ob ein Produkt funktioniert, ist die Cloud der richtige Ort. Keine Hardware-Investition, keine Verpflichtung. Wenn das Produkt funktioniert und die Last stabil wird, kann man migrieren.
Globale Verteilung. Wenn man Server in Singapur, São Paulo und Frankfurt braucht — in der nächsten Woche —, ist die Cloud die einzige Option. On-Premise braucht Zeit für Standortsuche, Hardware-Lieferung und Einrichtung.
Managed Services, die man selbst nicht betreiben will. Wenn man kein Elasticsearch-Expertise hat und nicht aufbauen will, dann ist AWS OpenSearch eine vernünftige Wahl. Wenn man kein Kafka-Cluster betreiben kann, dann ist Confluent Cloud eine Lösung. Der Schlüssel ist: Man wählt den Service bewusst, nicht als Default.
Kurzlebige Umgebungen. Test, Staging, CI/CD-Runner — Umgebungen, die man hochfährt, benutzt und wieder abschaltet. Die Cloud ist ideal für Ressourcen, die nicht 24/7 laufen müssen.
Wann On-Premise besser ist
On-Premise ist besser, wenn:
Dauerhafte Workloads. Workloads, die 24/7/365 laufen und deren Ressourcenbedarf vorhersehbar ist. Webserver, Datenbanken, Dateispeicher, interne Anwendungen — das ist das Kerngeschäft, und das gehört on-prem.
Große Datenmengen. Storage ist in der Cloud teuer. Bei 100+ TB wird die Rechnung absurd. On-Premise mit ZFS und großen Platten ist wirtschaftlich, und die Daten liegen dort, wo man sie kontrolliert.
Regulatorische Anforderungen. DSGVO, B3S, Kritis, Medizinprodukte-Verordnung — wenn der Gesetzgeber Datenhoheit verlangt, ist On-Premise keine Option, sondern eine Pflicht.
Langfristige Kosteneffizienz. Wenn man die Last für die nächsten 3–5 Jahre abschätzen kann, ist On-Premise günstiger. Deutlich günstiger.
Latenz-empfindliche Anwendungen. Die Netzwerk-Latenz zwischen Rechenzentrum und Nutzer ist on-prem minimiert. In der Cloud gibt es die Latenz zum nächsten Cloud-Region-Endpoint — und die ist für Echtzeit-Anwendungen nicht immer akzeptabel.
Daten, die nicht die Firma verlassen dürfen. Geheimnisse, Patente, Forschungsdaten, Kunden-Personas — es gibt Daten, die aus rechtlichen, ethischen oder strategischen Gründen nicht auf fremder Infrastruktur liegen dürfen.
Hybridmodelle — oft die beste Lösung
Die falsche Debatte ist „Cloud oder On-Premise“. Die richtige Debatte ist: „Was gehört wo hin?“
Das Prinzip der minimalen Cloud
Nutze die Cloud für das, was sie besser kann als On-Premise. Nutze On-Premise für alles andere. Das klingt banal, ist aber die Konsequenz einer ehrlichen Bewertung:
Managed Spezial-Services → Cloud. ML-Training, spezialisierte Datenbanken, Services, die man selbst nicht betreiben kann oder will.
Praktisches Hybrid-Setup
Ein konkretes Beispiel für ein mittelständisches Unternehmen:
On-Premise:
ZFS-Storage-Server mit 200 TB (Datenbanken, Dateispeicher, Backups)
Proxmox- oder bhyve-Cluster für interne Anwendungen
Git-Server (Gitea oder GitLab)
Identity Management (FreeIPA, Keycloak)
Monitoring (Prometheus, Grafana)
E-Mail-Server
Cloud:
CDN für die Website und statische Assets
Cloud-Runner für CI/CD (nur bei Bedarf)
Disaster Recovery: Replikation der kritischsten Daten in einen Cloud-Object-Store (verschlüsselt, mit eigenen Schlüsseln)
Burst-Compute für Lastspitzen (z.B. Quartalsende-Reporting)
Die monatliche Cloud-Rechnung für dieses Setup: vielleicht 500–2.000 €. Nicht 20.000 €. Nicht 50.000 €. Weil das Kerngeschäft on-prem läuft, und die Cloud nur das macht, was sie gut kann.
Die Rückkehr-Strategie
Für Unternehmen, die bereits massiv in der Cloud sind und die Kostenstruktur hinterfragen:
1. Inventur. Welche Workloads laufen in der Cloud? Welche davon laufen dauerhaft? Welche kosten am meisten?
2. Klassifikation. Welche Workloads sind Cloud-native (Lambda, DynamoDB, SQS)? Welche sind portabel (Docker-Container, Standard-Datenbanken, Webserver)?
3. Identifikation der Migrationskandidaten. Portable, dauerhafte Workloads mit hohem Daten-Volumen sind die besten Kandidaten für eine Rückkehr on-prem.
4. Pilot-Migration. Eine Workload auswählen, migrieren, Kosten vergleichen. Nicht alles auf einmal — iterativ vorgehen.
5. Optimierung. Nach der Migration: Cloud-Kosten für die verbleibenden Workloads optimieren. Reserved Instances, Spot-Instances, Right-Sizing.
Digitale Souveränität — mehr als ein Buzzword
Digitale Souveränität bedeutet: Die Fähigkeit, über die eigenen Daten, Prozesse und Infrastruktur selbst zu bestimmen. Nicht abhängig zu sein von einem einzelnen Provider, einem einzelnen Land, einer einzelnen Rechtsordnung.
Das ist kein nationalistisches Konzept. Es ist ein pragmatisches. Wer seine Infrastruktur nicht kontrolliert, kontrolliert sein Geschäft nicht. Wer seine Daten nicht kontrolliert, kontrolliert seine Zukunft nicht.
Die Cloud hat die Illusion erzeugt, dass Infrastruktur kein Problem mehr ist — man mietet sie ja einfach. Aber Infrastruktur war nie das Problem. Das Problem ist die Abhängigkeit. Und die Abhängigkeit ist in den letzten zehn Jahren größer geworden, nicht kleiner.
On-Premise ist die Antwort auf diese Abhängigkeit. Nicht als Absolutum — „alles on-prem“ ist genauso dogmatisch wie „alles Cloud“ —, sondern als bewusste Entscheidung: Was muss ich selbst kontrollieren? Was kann ich auslagern? Und wie stelle ich sicher, dass ich das Ausgelagerte bei Bedarf zurückholen kann?
Fazit
Die Cloud hat die IT-Landschaft verändert. Sie hat den Einstieg erleichtert, die Skalierung beschleunigt und die Betriebsmodelle transformiert. Aber sie hat auch Abhängigkeiten geschaffen, Kosten getrieben und Datenhoheit aufgeweicht.
On-Premise ist die Rückbesinnung auf das, was wirklich zählt: Kontrolle über die eigenen Daten, Kosteneffizienz für dauerhafte Workloads und Unabhängigkeit von einzelnen Providern.
Die beste Lösung ist Hybrid: Cloud für das, was die Cloud besser kann. On-Premise für alles andere. Und eine Architektur, die beides verbindet, ohne die Souveränität aufzugeben.
Die Unternehmen, die das verstehen, werden die nächsten zehn Jahre dominieren. Die anderen werden weiter monatliche Cloud-Rechnungen bezahlen — und sich fragen, warum ihre IT so teuer ist.