Es gibt wenige Behauptungen in der Linux-Welt, die so hartnäckig wiederholt werden wie die, dass Linux sicherer sei als Windows oder macOS. Man hört es in YouTube-Videos, in Distro-Vergleichen, in jedem zweiten Reddit-Thread und in den Marketingtexten der meisten freien Distributionen. Sie taugt zur Selbstvergewisserung, zur Werbung für Umsteiger, und sie ist trotzdem falsch, jedenfalls in der pauschalen Form, in der sie üblicherweise vorgetragen wird. Wer heute ein Standard-Ubuntu mit einem Standard-Windows-11 vergleicht, sieht auf der einen Seite ein durchgehärtetes Microsoft-System mit TPM-Pflicht, BitLocker Festplattenverschlüsselung im Default und ernstzunehmendem Defender, und auf der anderen Seite einen Desktop, dessen Sicherheitsmodell weitgehend aus einer Zeit stammt, in der Linux primär auf Servern lebte und der Endanwender nicht das Hauptziel war. Das ist eine unbequeme Wahrheit, die in der Linux-Community ungern ausgesprochen wird.
Die Theorie hinter dem Mythos ist Linus's Law, von Eric Raymond 1999 im Buch The Cathedral and the Bazaar griffig formuliert:
Given enough eyeballs, all bugs are shallow.
"Bei genügend Augen, die auf den Quellcode schauen, würden alle Fehler trivial."
Empirisch ist diese These längst widerlegt, und kein einzelner Vorfall hat das deutlicher gemacht als Heartbleed. Im Dezember 2011 committete der deutsche Doktorand Robin Seggelmann eine Implementierung der TLS-Heartbeat-Erweiterung in OpenSSL. Sein Code enthielt einen fehlenden Bounds-Check, der einem Angreifer erlaubte, in 64-Kilobyte-Häppchen den Speicher des Servers auszulesen, in dem typischerweise private Schlüssel, Sessiontokens und Passwörter lagen. Reviewer war Stephen Henson, einer der wenigen Hauptentwickler von OpenSSL. Der Bug wurde in OpenSSL 1.0.1 ausgeliefert und war ab März 2012 auf einem grossen Teil aller HTTPS-Server der Welt aktiv. Entdeckt wurde er erst im April 2014, von Neel Mehta bei Google und unabhängig davon von der finnischen Sicherheitsfirma Codenomicon.
Zwei Jahre lang konnte jeder, der von der Lücke wusste, ohne Spuren die Schlüssel des halben Internets abgreifen. Wie viele Augen genau nicht hingeschaut haben, lässt sich nicht beziffern.
Heartbleed ist kein Einzelfall, sondern der prominenteste Vertreter einer langen Reihe. PwnKit lag zwölf Jahre im Polkit-Code, Dirty COW neun Jahre im Kernel, Baron Samedit zehn Jahre in sudo, Looney Tunables Jahre in der glibc. Bei Komponenten, die im Herzen jeder Linux-Distribution sitzen und milliardenfach im Einsatz sind, blieben fundamentale Lücken über sehr lange Zeiträume unbemerkt, obwohl der Quellcode öffentlich war.
Open Source ist auditierbar, aber auditiert ist sie nur, wenn jemand das Audit auch tatsächlich durchführt, und das geschieht praktisch nie. Daraus folgt eine einfache Erkenntnis, die das Linux-Marketing seit zwanzig Jahren verschleiert: Open Source ist nicht automatisch sicher, und Closed Source ist nicht automatisch unsicher. Die Trust-Modelle sind unterschiedlich, und beide haben ihre blinden Flecken.
Heikler wird es, wenn ich vom Quellcode zum tatsächlichen Verhalten am Desktop wechsle. Auf macOS muss eine App den Zugriff auf den Dokumenten-Ordner, das Mikrofon oder den Bildschirm einzeln per TCC einfordern, sichtbar und widerrufbar. Auf Windows 11 läuft eine UWP-App in einem AppContainer, die Festplatte ist auf modernen Geräten standardmässig verschlüsselt, biometrische Daten liegen TPM-geschützt im Vault.
Eine klassische Linux-Anwendung dagegen, ob aus dem Repository, als AppImage geladen oder per pip nachgezogen, läuft mit den vollen Rechten meines Useraccounts und kann ~/.ssh, ~/.gnupg, das Firefox-Profil und alle meine Dokumente lesen, ohne dass irgendjemand fragt. Im Folgenden gehe ich Punkt für Punkt durch, an welchen Stellen das Linux-Desktop-Modell strukturell hinter den kommerziellen Konkurrenten zurückbleibt, warum die unkuratierten Paketquellen AUR, PPA und Copr ein echtes Trust-Problem haben, weshalb mein Fingerabdruck unter Linux fundamental unsicherer abgelegt ist als auf einem MacBook oder einem Windows-Laptop mit TPM, was X11 bis heute zur Sicherheitsbaustelle macht, und welche Default-Einstellungen praktisch alle Mainstream-Distributionen schuldig bleiben. Der Artikel wird in dieser Form viele Linux-User verärgern. Er soll auch provozieren, denn der Mythos schadet uns.
Heartbleed im Detail, oder warum viele Augen nichts gesehen haben
Heartbleed verdient einen genaueren Blick, weil er das Trust-Modell von Open Source in Reinform vorführt. OpenSSL ist die Bibliothek, auf der ein Grossteil der verschlüsselten Internet-Kommunikation aufbaut.
Apache, Nginx, OpenVPN, Postfix, IMAP- und POP-Server, MySQL, PostgreSQL, fast jeder TLS-Endpunkt der Welt verwendet OpenSSL oder ein Derivat davon. Die Library hatte zum Zeitpunkt des Heartbleed-Vorfalls einen einzigen vollzeitbeschäftigten Entwickler. Stephen Henson, der von der OpenSSL Software Foundation einen bescheidenen Lohn bezog. Der Rest war Freiwilligenarbeit. Spendeneinnahmen lagen jährlich im Bereich von wenigen tausend Dollar. Die Verantwortung für die Krypto-Grundlage des Webs ruhte auf den Schultern einer Handvoll unbezahlter und einem unterbezahlten Maintainer. Das war kein Geheimnis. Es war einfach niemandem gross aufgefallen, weil OpenSSL funktionierte und niemand laut nach mehr Geld rief. Erst nach Heartbleed gründete die Linux Foundation die Core Infrastructure Initiative und brachte Millionenbeträge zusammen, um die kritischsten Open-Source-Projekte zu stabilisieren. Vor dem Vorfall war das Modell schlicht: ihr verwendet es alle, niemand bezahlt dafür, und es funktioniert irgendwie weiter.
Der eigentliche Bug ist banal. Die TLS-Heartbeat-Erweiterung erlaubt es einem Client, einen Ping mit einer Nutzdaten-Länge an den Server zu senden, und der Server antwortet mit denselben Daten zurück, um die Verbindung am Leben zu halten. Seggelmanns Code übernahm die vom Client angegebene Länge ohne Prüfung gegen die tatsächliche Länge der mitgelieferten Daten. Wer als Client also "antworte mir mit den nächsten 64 Kilobyte ab dieser Position" sagte, ohne 64 Kilobyte mitzuschicken, bekam aus dem Heap des Servers das, was zufällig dort lag. Speicher in OpenSSL-Prozessen enthält private Schlüssel, frisch entschlüsselte Sessions, Passwörter aus laufenden Logins und beliebige andere Geheimnisse. Der Bug war kein subtiler Race, kein abgrundtiefer Cryptobruch, sondern ein vergessener Bounds-Check, wie er im ersten Semester C-Programmierung gelehrt wird. Genau das macht ihn zum perfekten Beispiel für die Schwäche des Many-Eyes-Arguments.
Der Commit von Seggelmann erfolgte am Silvesterabend des Jahres 2011. Henson reviewte und mergte den Patch wenig später. Beide haben später erklärt, sie hätten den Fehler übersehen, was in dieser Form auch glaubhaft ist. Was nicht erklärt wurde, ist, warum in den darauffolgenden zwei Jahren niemand sonst dieses Stück Code in einer der wichtigsten Sicherheits-Bibliotheken der Welt einer ernsthaften Prüfung unterzogen hat. Auch Canonical oder RedHat nicht die OpenSSL in ihren kommerziellen Distributionen mit diesem Bug ausgeliefert haben.
Die Antwort liegt im Anreizsystem freier Software. Wer auditiert, bekommt dafür kein Geld. Wer einen Bug findet, kann ihn melden, wird aber selten dafür bezahlt. Wer einen Bug findet und ihn nicht meldet, kann ihn an Geheimdienste oder an den grauen Markt verkaufen, oft für sechsstellige Beträge. Die Anreize zeigen nicht in Richtung Bugfixing. Genau diese Asymmetrie verschweigt der Many-Eyes-Mythos. Bei kommerzieller Closed-Source-Software gibt es interne Security-Teams, die für ihre Arbeit bezahlt werden. Bei Open Source gibt es engagierte Freiwillige und vereinzelt geförderte Projekte. Der Rest ist Prinzip Hoffnung.
Was Heartbleed zusätzlich dramatisch machte, war die Unmöglichkeit forensischer Aufklärung. Der Exploit hinterlässt im Standard-Logging keine Spuren. Wer angegriffen wurde, wusste nicht, ob seine privaten Schlüssel kompromittiert waren oder nicht. Folgerichtig mussten Betreiber weltweit ihre TLS-Schlüssel rotieren, neue Zertifikate ausstellen lassen, alle Sessions invalidieren und davon ausgehen, dass Passwörter in den vorausgehenden zwei Jahren möglicherweise abgegriffen worden waren. Der wirtschaftliche Schaden ging in die Milliarden. Verursacht hat ihn ein Patch, der nicht ordentlich reviewt wurde, in einer Bibliothek, die niemand bezahlte.
Sandboxing, oder das Fehlen davon, am Linux-Desktop
Wer einmal verstanden hat, wie wenig eine klassische Linux-Anwendung von ihrer Umgebung getrennt ist, kann das Argument der überlegenen Linux-Sicherheit am Desktop nicht mehr aufrechterhalten. Wenn ich auf meinem Ubuntu einen beliebigen Editor, ein heruntergeladenes AppImage oder ein per pip installiertes Tool starte, läuft dieser Prozess mit den vollen Rechten meines Useraccounts. Er kann meinen kompletten Home-Ordner lesen und schreiben. Er kann meine SSH-Keys aus ~/.ssh kopieren, mein GPG-Keyring durchblättern, das Firefox-Profil mit allen gespeicherten Passwörtern auslesen, das Chromium-Cookie-Storage abgreifen, meine Mail in Thunderbird durchforsten, meine Bitcoin-Wallet aus ~/.bitcoin abziehen. Er kann via D-Bus mit anderen Anwendungen reden, kann den X-Server anzapfen, kann Tastatureingaben mitlesen, sofern X11 läuft. Niemand fragt mich vorher. Das System hat schlicht keinen Mechanismus, um eine App davon abzuhalten. Das ist das Unix-Modell aus den 1970er Jahren, eingerichtet für ein Mehrbenutzersystem mit zentraler Verwaltung, weitergeführt auf einem Single-User-Desktop, auf dem der Useraccount alles ist, was zu schützen wäre.
Auf macOS sieht das fundamental anders aus. Eine App, die Zugriff auf den Dokumenten-Ordner haben will, muss das via TCC, dem Transparency-Consent-Control-Framework, einzeln einfordern. Apple hat die kritischen Ordner und Funktionen explizit isoliert: Schreibtisch, Dokumente, Downloads, iCloud-Inhalte, Bildschirmaufnahme, Mikrofon, Kamera, Vollzugriff auf die Festplatte. Jeder dieser Zugriffe löst einen sichtbaren Dialog aus, jeder kann später in den Systemeinstellungen widerrufen werden.
Auf Windows 11 läuft eine UWP-Anwendung in einem AppContainer mit eingeschränkten Rechten, der Zugriff auf Mikrofon und Kamera ist über die Datenschutz-Einstellungen reguliert, Controlled Folder Access schützt sensible Verzeichnisse vor unbekannten Anwendungen. Beide Systeme haben ein klares Privilege-Modell für die App, getrennt vom Userprofil. Linux hat das nicht.
Flatpak hätte hier den Anspruch, die Sicherheitslücke zu schliessen. Flatpak-Anwendungen laufen in einer Bubblewrap-Sandbox mit definierten Berechtigungen, das Portal-System vermittelt Zugriffe auf Dateien, Drucker und Kamera per User-Bestätigung, und die Permissions sind im Manifest deklariert. Das ist konzeptionell richtig. In der Praxis wird der Anspruch aber regelmässig durch das Recht --filesystem=home oder --filesystem=host unterlaufen. Wenn ein Flatpak diese Berechtigung im Manifest fordert, sieht es das gesamte Userhome oder gleich das ganze Dateisystem, und die Sandbox wird zur Dekoration.
Genau das tun verbreitete Flatpaks wie OBS, GIMP, LibreOffice oder VS Code, weil ihre Funktion ohne breiten Filesystem-Zugriff schwierig wäre. Der User sieht das im Flatpak-Manifest, falls er sich die Mühe macht, oder in Tools wie Flatseal. Die meisten User sehen es nicht.
Snap ist hier strenger, weil Canonical über AppArmor-Profile striktere Defaults erzwingt, hat aber sein eigenes Image-Problem mit dem zentralen, proprietären Snap Store und dem nervigen automatischen Update-Verhalten, das viele User dazu bringt, Snaps von ihren Systemen zu entfernen. Bubblewrap und Firejail sind als manuelle Sandboxing-Tools verfügbar, sind aber Bastel-Lösungen für Powernutzer, nicht der Standard-Schutz für die Masse.
Die Konsequenz dieser Architektur ist, dass jede Linux-Desktop-Anwendung in der Praxis vertrauenswürdig sein muss, weil das System sie nicht kontrollieren kann.
Vertrauenswürdig bedeutet: ich vertraue nicht nur dem Hauptentwickler, sondern allen Mitcontributoren, allen Build-Maschinen, allen Distributoren in der Lieferkette und der Integrität jedes Zwischenschritts. Ein einziger kompromittierter Build-Server in einem Upstream-Projekt reicht, um auf meinem Desktop einen Prozess zu starten, der mit den vollen Rechten meines Accounts macht, was er will. Die Verteidigungslinie liegt allein im Trust gegenüber allen Beteiligten, nicht im Betriebssystem.
AUR, PPA und Copr, das unsichtbare Trust-Problem
Die unkuratierten Paketquellen sind das vielleicht beste Beispiel für die Differenz zwischen postuliertem und gelebtem Sicherheitsmodell. Das Arch User Repository, kurz AUR, ist eine Sammlung von PKGBUILDs, also Build-Anleitungen, die von beliebigen Community-Mitgliedern eingereicht und gepflegt werden. Es gibt keine Code-Reviews, keine Hintergrundüberprüfungen, keine Identitätsprüfung der Person die das PKGBUILD anbietet. Wer einen Account hat, kann ein PKGBUILD hochladen, und wer das passende Tool installiert hat, kann es bauen und installieren.
Die offizielle Doku weist darauf hin, dass User PKGBUILDs vor der Installation prüfen sollen. In der Praxis tut das fast niemand. AUR-Helper wie yay oder paru zeigen das PKGBUILD zwar an, doch die meisten User bestätigen die Installation reflexartig, weil sie einfach das Programm haben wollen, das sie suchen. Ein bösartiges PKGBUILD kann beim Build-Prozess oder im Install-Hook beliebigen Code ausführen, mit den Rechten, die der User dem Helper gewährt. In der Regel sind das Root-Rechte für die Installation und Userrechte für den Build-Schritt. Beides reicht, um auf dem System Schaden anzurichten.
Es gab in den letzten Jahren mehrfach Vorfälle, bei denen AUR-Pakete kompromittiert wurden. Im Jahr 2018 wurde das Paket acroread mit Malware versehen, die nach der Installation ein Cronjob anlegte, der Daten an einen externen Server schickte. Es dauerte mehrere Tage, bis das auffiel. Im Jahr 2024 wurden die Pakete librewolf-fix-bin, firefox-patch-bin und zen-browser-patched-bin mit einem Remote-Access-Trojaner kompromittiert. Die Tatsache, dass sie populären Browser-Forks ähnelten und den Anschein offizieller Quellen erweckten, half den Angreifern. Gefunden wurden die Pakete erst, als ein einzelner User sich über eine ungewöhnliche Netzwerkaktivität wunderte und nachforschten. Wie viele Systeme in der Zwischenzeit kompromittiert wurden, ist unbekannt.
PPAs auf Ubuntu folgen dem gleichen Muster. Ein add-apt-repository ppa:user/projektname fügt eine Paketquelle hinzu, deren GPG-Key automatisch importiert wird, und ab dann werden Updates aus dieser Quelle eingespielt, als wären sie offiziell. Maintainer-Skripte in Debian-Paketen laufen als Root und können während Installation, Upgrade oder Deinstallation beliebigen Code ausführen. Launchpad als Hosting-Plattform liefert die Infrastruktur, prüft aber den Code nicht. Wer auf eine Tutorial-Website klickt und dort den Befehl sudo add-apt-repository ppa:irgendjemand/coolesprojekt sieht, hat in der Regel keine Möglichkeit zu wissen, wem er da gerade Vertrauen einräumt. Ein PPA-Maintainer kann seine Pakete jederzeit gegen kompromittierte Versionen austauschen, und das Update läuft beim nächsten apt upgrade automatisch durch.
Copr, das "Cool Other Package Repo" von Fedora, hat mit Abstand das problematischste Image-Problem dieser drei Mechanismen. Copr-Repositories werden auf der Infrastruktur des Fedora Project gehostet, sind über fedoraproject.org-Subdomains erreichbar, und das Aktivieren erfolgt mit einem dnf copr enable Befehl, der für viele User wie ein offizieller Fedora-Vorgang aussieht. Tatsächlich ist Copr genauso unkuratiert wie das AUR. Jeder mit einem Fedora-Account kann ein Repository anlegen und beliebige RPM-Spec-Dateien einreichen. Die Build-Maschinen sind zentral, das hilft gegen Build-Manipulation, aber nichts gegen bösartige Spec-Files. Im Februar 2024 wurde in der Diskussion um die XZ-Backdoor explizit auf Copr-Pakete als möglichen Verteilweg hingewiesen, weil sie im Vertrauensraum von Fedora liegen, aber keinem Review unterliegen. Der Disclaimer "Copr is community supported and not endorsed by Fedora" steht zwar in der Doku, ist aber im normalen User-Workflow nicht sichtbar.
Im Vergleich dazu der Mac App Store, der Microsoft Store und auch die Google-Play-Welt: alle drei haben einen mehrstufigen Review-Prozess, der nicht perfekt ist, aber Pakete zumindest auf offensichtliche Malware prüft, Code-Signierung erzwingt. Dass Apps trotzdem durchschlüpfen, kommt vor, ist aber die Ausnahme statt die Regel. Bei AUR, PPA und Copr ist die Regel, dass nichts geprüft wird, und die Ausnahme ist, dass jemand zufällig hinschaut. Wenn ich also höre, Linux sei sicherer, weil ich nicht aus einem zentralen App Store installieren muss, dann ist das eine Verwechslung von Freiheit und Sicherheit.
curl pipe sudo bash, die kulturell normalisierte Lieferkettenlücke
Die zweite kulturelle Eigenheit, die Linux-User selten als Sicherheitsproblem benennen, ist die Selbstverständlichkeit, mit der wir Software per curl | sudo bash installieren. Der Brave Browser empfiehlt das in seiner offiziellen Anleitung.
Der Befehl lautet typischerweise curl -fsSL https://example.com/install.sh | sh oder, schlimmer, mit sudo davor. Was passiert dabei wirklich: ich lade ein Shell-Skript von einem Server, das ich nie gesehen habe, und führe es sofort aus, ohne es zu lesen, ohne Signaturprüfung, ohne Versionspinning, ohne Review. Wenn der Server zwischen meinem Aufruf und der Antwort kompromittiert wird, oder wenn ein Angreifer den DNS-Eintrag manipuliert oder das CDN unterwandert, läuft auf meinem System ein beliebiges Skript mit meinen Userrechten oder mit Root.
Das wäre noch nicht so dramatisch, wenn es eine seltene Ausnahme wäre. Tatsächlich ist es der Standardweg, wie moderne Entwicklertools verteilt werden. Bei kommerzieller Software auf macOS oder Windows wäre dieses Vorgehen undenkbar. Niemand würde von einem Mac-User erwarten, dass er die Installation vom Brave Browser mit einem Befehl wie curl -fsS https://dl.brave.com/install.sh | sh erledigt. Auf Linux ist es Alltag.
Die Linux-Community hat einen Lieferketten-Angriffsvektor zu einer kulturellen Norm gemacht, und sie verteidigt diese Norm in der Regel mit dem Argument der Einfachheit und der Benutzerfreundlichkeit.
X11, eine Sicherheitsbaustelle aus den 1980er Jahren
X11 wurde 1987 spezifiziert, in einer Zeit, in der das Bedrohungsmodell ein anderes war. Mehrere User auf einem Server, die sich gegenseitig nicht ausspionieren sollten, waren das Hauptproblem. Innerhalb einer User-Session war alles erlaubt, weil die Annahme war, dass alle Anwendungen in der Session demselben User gehörten und sich daher gegenseitig vertrauen durften. Diese Annahme ist auf einem modernen Desktop falsch. Heute lade ich eine Software aus dem Internet herunter und starte sie unter meinem User. Der Mailclient, der Browser, Slack, ein Spiel, das Bash-Skript, das ich gerade laufen lasse, alle leben in derselben Session. Und alle können einander unter X11 belauschen.
Konkret bedeutet das: jeder X-Client, der in der gleichen Session läuft, kann an die Tastatureingaben aller anderen Fenster gelangen, indem er einfach den X-Server fragt. Er kann den Bildschirminhalt jedes anderen Fensters auslesen. Er kann Tastatureingaben in fremde Fenster injizieren. Tools wie xdotool, xinput und xrandr machen das trivial. Ein bösartiges Programm, das ich versehentlich starte, kann alles mitlesen, was ich tippe, einschliesslich Passwörter, kann Screenshots machen, während ich mit dem Online-Banking arbeite, und kann Tastatureingaben simulieren, um andere Anwendungen zu Aktionen zu zwingen. Es gibt keine Schutzschicht dazwischen. Der X-Server stellt all das per Protokoll zur Verfügung, weil das vor knapp vierzig Jahren als Feature konzipiert war.
Wayland repariert dieses Modell fundamental. Jede Wayland-Anwendung sieht nur ihre eigenen Fenster, kann nur eigene Eingaben abfragen, und Screen-Sharing oder Eingabeinjektion erfolgen ausschliesslich über explizite Portale, die der Compositor vermittelt. Das ist eine architektonische Sanierung, und sie ist überfällig. Ubuntu 26.04 hat den X-Session-Eintrag aus dem Login-Screen entfernt, Fedora ist diesen Schritt schon früher gegangen, und für die meisten Distributionen ist Wayland inzwischen Default. Allerdings: XWayland existiert weiterhin als Kompatibilitätsschicht für Anwendungen, die noch kein natives Wayland sprechen, und innerhalb dieser XWayland-Session gilt das alte X11-Modell mit allen seinen Schwächen. Wer Steam-Spiele, ältere Tools, manche Java-Anwendungen oder bestimmte proprietäre Programme nutzt, hat die XWayland-Brücke aktiv, und in der Brücke können diese Anwendungen sich gegenseitig wieder ausspionieren. Wayland-Anwendungen sind voneinander isoliert, XWayland-Anwendungen sind es untereinander nicht. Das ist ein Fortschritt, aber kein Vollschutz.
Auf macOS und Windows war Window-Isolation nie eine offene Frage, weil die Display-Server dieser Systeme von vornherein mit dem Anspruch einer Isolation gebaut wurden. Der Fakt, dass die Linux-Welt Jahrzehnte gebraucht hat, um diese Lücke zu schliessen, und dass sie auf vielen Systemen über XWayland weiterhin offensteht, ist kein Beleg für überlegene Sicherheit.
Festplattenverschlüsselung, ein hartnäckiges Default-Problem
Wenn ich heute einen Windows-11-Laptop kaufe, ist die Festplatte ab dem ersten Boot mit BitLocker verschlüsselt. Microsoft hat das mit Windows 11 zur Pflicht gemacht, getragen vom TPM-2.0-Chip, der den Schlüssel hardwaregebunden verwahrt. Auf einem MacBook ist FileVault in macOS aktiv immer eingeschaltet, weil die Secure Enclave Schlüssel und Verschlüsselungsoperationen kapselt. Wer ein modernes kommerzielles Notebook startet, hat ohne eigenes Zutun verschlüsselte Daten. Verliere ich das Gerät, sind die Daten ohne Login-Passwort und ohne den TPM- oder Secure-Enclave-gebundenen Schlüssel nicht zugänglich.
Auf Linux ist die Lage gemischt. Ubuntu bietet Full Disk Encryption mit LUKS seit Jahren an, allerdings als Opt-in im Installer. Wer die Standard-Installation durchklickt und nicht bewusst einen Haken setzt, bekommt ein unverschlüsseltes System. Seit Ubuntu 24.04 gibt es als experimentelle Option eine TPM-gebundene LUKS-Variante, die das Modell von BitLocker und FileVault nachbildet, doch sie ist nicht Default und gilt auch im aktuellen Ubuntu 26.04 als experimentell.
Linux Mint, Pop_OS, Elementary OS, Manjaro und die meisten anderen verbreiteten Desktops folgen demselben Opt-in-Modell. Fedora hat mit Fedora 42 einen Schritt nach vorne gemacht und aktiviert LUKS-Verschlüsselung im Anaconda-Installer per Default, das ist ein Fortschritt, aber Fedora ist immer noch eine Distribution unter vielen, und ihre Userbasis ist im Vergleich zu Ubuntu oder Mint bescheiden.
Die Konsequenz ist, dass ein durchschnittlicher Linux-Desktop-User mit hoher Wahrscheinlichkeit auf einem unverschlüsselten System arbeitet. Wer das Gerät verliert oder gestohlen bekommt, gibt damit alle seine Daten preis. SSH-Keys, gespeicherte Browserpasswörter, Mailarchive, lokale Dokumente, alles liegt offen. Auf macOS und Windows wäre das durch die Default-Verschlüsselung mindestens verzögert, oft komplett unterbunden. Das ist keine Frage der Möglichkeiten, sondern der Defaults, und Defaults sind das, was die grosse Mehrheit der User tatsächlich benutzt.
fprintd, oder warum mein Fingerabdruck auf der Festplatte liegt
Der Punkt, der mich persönlich am meisten ärgert, betrifft die biometrische Authentifizierung. Wer einen Linux-Laptop mit Fingerabdrucksensor besitzt und fprintd plus libpam-fprintd installiert, kann sich mit dem Finger einloggen, auch sudo per Fingerabdruck bestätigen, und das funktioniert in vielen Fällen erstaunlich gut. Was die meisten User nicht wissen: ihr Fingerabdruck-Template liegt anschliessend als gewöhnliche Datei auf der Festplatte, in der Regel unter /var/lib/fprint/ in einem Userunterverzeichnis. Die Datei ist mit Root-Rechten lesbar. Format und Inhalt hängen vom Sensor und vom libfprint-Treiber ab. In manchen Fällen handelt es sich um ein verarbeitetes Template, in anderen Fällen um etwas, das einer Bilddatei nahekommt. In jedem Fall ist es das, was der Login-Vorgang vergleicht, und es ist nicht hardwaregeschützt.
Auf einem MacBook ist das anders gelöst. Der Fingerabdrucksensor ist mit der Secure Enclave verbunden, einem dedizierten Coprozessor mit eigenem Speicher und eigenen Krypto-Funktionen. Das Template wird in der Enclave erzeugt und gespeichert, verlässt sie nie. Beim Login schickt der Sensor seine Messwerte an die Enclave, die Enclave vergleicht intern und gibt nur das Ergebnis nach aussen, ein Ja oder ein Nein. Selbst Apple hat keinen Zugriff auf das Template. Wer die Festplatte des Geräts ausbaut und ausliest, findet keine biometrischen Daten. Die Enclave ist aufwendig gegen physische Angriffe gehärtet, und bislang gibt es keinen öffentlich dokumentierten Weg, ihren Inhalt auszulesen.
Auf Windows-Laptops mit Windows Hello und TPM 2.0 ist die Architektur ähnlich. Das Template wird im Vault des Trusted Platform Module gespeichert, der Vergleich findet TPM-vermittelt statt, das Klartext-Template verlässt das TPM nicht. Wer die Festplatte ausliest, sieht verschlüsselte Container, die ohne den TPM-Schlüssel nutzlos sind.
Es gibt sogenannte Match-on-Chip-Sensoren, bei denen das Template auf dem Sensor selbst verbleibt und der Vergleich im Sensor stattfindet. Diese Sensoren sind unter Linux die Ausnahme, nicht die Regel. Die Mehrheit der unter libfprint unterstützten Sensoren liefert Rohdaten oder Templates an das Userland, und die Speicherung erfolgt im Filesystem.
Das ist kein Bug von fprintd, sondern eine Konsequenz der Hardware-Treiber-Lage und der Tatsache, dass Linux historisch keinen integrierten Secure-Element-Stack für biometrische Daten hatte. Praktisch heisst das: wenn ich meinen Linux-Laptop verliere oder ein Angreifer kurzzeitig physischen Zugriff bekommt, ist mein Fingerabdruck-Template potenziell extrahierbar. Bei einem MacBook oder einem aktuellen Windows-Laptop mit TPM 2.0 ist dieser Pfad geschlossen. Mein biometrisches Merkmal, das ich nicht ändern kann, weil ich mit demselben Finger ein Leben lang unterwegs bin, ist auf Linux schlechter geschützt als auf den kommerziellen Konkurrenzsystemen. Das ist 2026 nicht zeitgemäss.
Die ursprüngliche Diskussion in der freedesktop-Community zu diesem Thema, geführt im Kontext der ersten fprintd-Versionen, kam zum Schluss, dass Fingerabdrucksensoren auf Linux nur als Authentifizierungsfaktor taugen, nicht als Quelle für Schlüsselmaterial, weil das Template eben nicht hardwaregeschützt sei. Die Schlussfolgerung damals war pragmatisch und richtig: man verwendet den Fingerabdruck zur Convenience, das Passwort bleibt der eigentliche Schutz, und zum Beispiel der GNOME-Keyring wird weiterhin mit dem Userpasswort entschlüsselt, nicht mit dem Fingerabdruck. Das ist immerhin ehrlich, aber es ändert nichts daran, dass das gespeicherte Template angreifbar bleibt. Wer den Sensor nutzt und sich nicht damit beschäftigt, lebt mit einem Risiko, das auf macOS und Windows nicht existiert.
Hardware-Trust und TPM, das niemand ausnutzt
Die meisten Betriebssysteme verfügen heute über ein TPM Modul, weil moderne Hardware ohnehin mit TPM ausgeliefert wird. Genutzt wird der Chip unter Linux allerdings nur sporadisch. Es gibt systemd-cryptenroll, mit dem sich LUKS-Schlüssel an das TPM binden lassen, es gibt tpm2-tools für die manuelle Konfiguration, und es gibt Versuche, Secure Boot mit Measured Boot und TPM-basiertem Disk-Unlocking zu kombinieren. All das funktioniert, ist aber jenseits des Standardweges. Die Default-Installation bindet keinen Schlüssel an das TPM, der Disk-Encryption-Setup ignoriert es, und Tools wie systemd-pcrlock zur PCR-basierten Schlüsselbindung sind noch experimentell.
Auf Apple-Silicon-Macs ist die Secure Enclave fest in jedem Krypto-Vorgang integriert. Der File-System-Schlüssel ist enclave-gebunden, der Touch-ID-Sensor spricht direkt mit der Enclave, der Keychain nutzt enclave-basierte Wrapping-Operationen. Auf Windows 11 mit TPM 2.0 ist BitLocker TPM-gebunden, Windows Hello speichert seine Credentials TPM-geschützt, der Microsoft-Account wird via TPM an das Gerät verankert. Die Hardware-Trust-Stack ist auf den kommerziellen Systemen konsequent durchgezogen. Auf Linux ist er optional, lückenhaft und für Mainstream-User unerreichbar. Wer ihn aktiv manuell einrichtet, kommt sehr weit. Wer das nicht tut, hat einen TPM-Chip im Gerät, der die meiste Zeit Däumchen dreht.
Secure Boot ist die zweite Baustelle. Auf Windows ist Secure Boot eine Selbstverständlichkeit. Auf Linux ist es ein Reizthema mit komplizierter Geschichte und einem Ökosystem aus shim, MOK, Kernel-Modul-Signaturen und Distro-spezifischen Lösungen. Wer einen Custom-Kernel kompiliert, ein NVIDIA-Modul lädt oder DKMS-Pakete einsetzt, landet schnell in einer MOK-Verwaltung, die für die meisten User intransparent bleibt. Es funktioniert, aber es ist nichts, was sich in den Default-Installer integrieren lässt, und es ist auch nichts, das die Schutzwirkung von echtem Verified Boot wie auf macOS oder ChromeOS erreicht.
Anti-Malware, oder das Argument, das nicht mehr trägt
Das klassische Linux-Argument lautet, man brauche keine Antimalware-Software, weil es für Linux keine Malware gebe. Diese Behauptung ist gleich in mehreren Hinsichten überholt. Erstens gibt es Malware für Linux, sehr wohl, sie zielt nur historisch primär auf Server. Mirai-Botnet-Komponenten, Cryptominer, SSH-Bruteforce-Tools, Ransomware-Versionen für Linux-Server existieren in nennenswerter Zahl. Zweitens hat sich die Bedrohungslandschaft mit Supply-Chain-Angriffen verändert. Eine kompromittierte npm-Library, ein bösartiges Python-Paket auf PyPI, eine manipulierte Ruby-Gem oder ein verseuchtes Docker-Image lieferten in den letzten Jahren genug Beispiele dafür, dass auch Linux-Entwickler-Workstations regelmässig Ziel von Angriffen waren. Drittens entwickelt sich der Linux-Desktop weiter, und mit Steam Deck, Ubuntu-Standard-Notebooks und der wachsenden Linux-Userbasis wird der Marktanteil interessant genug, um gezielte Desktop-Malware lohnenswert zu machen.
ClamAV, der quasi einzige Open-Source-Anti-Malware-Stack auf Linux, ist primär für Mailserver gedacht, scannt Anhänge, ist solide, aber kein Endpoint-Schutz. Echtzeit-Schutz, Verhaltensanalyse, EDR-Funktionen, das alles fehlt. Auf Windows ist Defender integriert, hat Verhaltensanalyse, Cloud-basierte Heuristiken, Anti-Ransomware-Module und Controlled Folder Access. Auf macOS gibt es XProtect, Gatekeeper und MRT, ergänzt durch eine restriktive Code-Signing-Policy, die unsignierte Software ohne explizite User-Aktion gar nicht erst startet. Beide Systeme erkennen heute eine signifikante Bandbreite an Malware, bevor sie ausgeführt wird. Linux hat dieses Sicherheitsnetz nicht. Wer auf Linux Malware abbekommt, weil ein heruntergeladenes AppImage oder ein Pip-Paket kompromittiert war, hat keinen System-internen Mechanismus, der das früh erkennt.
Das Argument "ich brauche das nicht, weil ich nur aus offiziellen Quellen installiere" ist 2026 dünn. Selbst offizielle Quellen sind kompromittierbar, wie der Codecov-Vorfall, der event-stream-Vorfall in npm, die XZ-Backdoor und etliche andere Episoden gezeigt haben. Vertrauen in die Quelle ersetzt keinen Endpoint-Schutz, es verlagert das Problem nur.
Updates, Disziplin und das fehlende Livepatching
Auf Windows und macOS bekommt der User Updates aufgedrängt, manchmal sogar gegen seinen Willen, was kulturell oft kritisiert wird. Aus Sicherheitssicht ist diese Aufdringlichkeit allerdings eine Schutzfunktion. Wer ein Windows-11-Notebook nicht patcht, wird vom System genötigt, irgendwann zu rebooten, weil die monatlichen Patch-Dienstage sich automatisch durchsetzen. Apple aktualisiert XProtect-Definitionen unbemerkt im Hintergrund, oft mehrmals pro Woche. Auf Linux liegt die Update-Disziplin beim User. Wer apt update vergisst, vergisst es. Wer Fedora auf einem alten Release lässt, bleibt dort, bis er aktiv migriert. Rolling-Distros wie Arch oder openSUSE Tumbleweed sind hier im Vorteil, weil Updates kontinuierlich kommen, doch sie verlangen ihrerseits Disziplin und tragen das Risiko von Breaking Changes.
Kernel-Updates erfordern auf Linux einen Reboot, sofern man kein Livepatching einsetzt. Livepatching ist verfügbar, allerdings primär in kommerziellen Angeboten: Canonical Livepatch ist Teil von Ubuntu Pro mit Limitierung auf wenige kostenlose Maschinen, Red Hat hat kpatch, SUSE hat kGraft, Oracle hat Ksplice. Auf einem typischen Ubuntu-Desktop ohne Pro-Subscription bleibt der Kernel zwischen Reboots veraltet, was bei Lücken wie Dirty Pipe oder Looney Tunables einen wochenlangen Risikozeitraum bedeutet.
Auf macOS und Windows wird der Kernel ebenfalls nur per Reboot ersetzt, doch beide Systeme zwingen den Reboot innerhalb überschaubarer Frist und kombinieren ihn mit System-Integrity-Checks, die manche Klassen von Persistenz-Angriffen mitabräumen. Auf Linux bleibt das eine Frage der eigenen Disziplin.
Firmware-Updates über fwupd und das LVFS sind ein Lichtblick. Wer einen unterstützten Hersteller hat, bekommt BIOS- und Mikrocode-Updates automatisch über GNOME Software oder das fwupd-CLI. Allerdings ist die Hersteller-Beteiligung lückenhaft, viele Notebooks ausserhalb der Dell-Lenovo-HP-Achse fallen durchs Raster, und für ältere Geräte gibt es oft gar keine Updates. Auf Windows liefert Windows Update plus die OEM-Updater eine breitere Abdeckung, auf macOS sowieso, weil Apple Hard- und Software in einer Hand kontrolliert.
Was Linux trotzdem gut macht
Damit dieser Artikel nicht als reiner Verriss endet, ein notwendiger Gegenakzent. Linux hat bei Sicherheit einige strukturelle Vorteile, die nicht weggewischt werden sollten. Die Transparenz des Quellcodes ist real und nützlich, auch wenn sie nicht automatisch zu Sicherheit führt. Wer einen Verdacht hat, kann ihn auf Linux überprüfen. Auf Windows oder macOS bleibt vieles intransparent, selbst die Betreiber müssen darauf vertrauen, was Microsoft und Apple ihnen mitteilen.
Linux kennt keine Telemetrie-Pflicht, keine erzwungenen Cloud-Konten, keine Zwangs-Updates zur Unzeit, kein Werbe-ID-System, das systemweit mitliest. Wer Wert auf Datenkontrolle legt, hat auf Linux substanziell bessere Möglichkeiten, sein System abzudichten, als auf den kommerziellen Konkurrenten. Hier ist einfach wider wichtig zu verstehen, dass Datenschutz und Sicherheit zwei unterschiedliche Dinge sind.
Die Granularität der Konfiguration ist ein weiterer echter Vorteil. Wer SELinux versteht und einsetzt, hat ein Mandatory-Access-Control-Modell, das Windows in dieser Form nicht bietet. AppArmor liefert Profile, die granular festlegen, welche Pfade ein Daemon lesen oder schreiben darf. Wer mit nftables, iptables oder firewalld arbeitet, kann seinen Netzwerkverkehr feiner kontrollieren als mit der Windows-Firewall in der GUI. Wer Container-Technologien wie Podman, LXC oder systemd-nspawn nutzt, kann Anwendungen isolieren auf eine Art, die auf macOS oder Windows nicht oder nur mit Drittanbieter-Software zur Verfügung steht.
Es gibt ausserdem Linux-Distributionen, die aktiv für Sicherheit gebaut sind, in einer Tiefe, die Windows und macOS nicht anbieten. Qubes OS isoliert jede Anwendung in einer eigenen Xen-VM, mit klar definierten Vertrauenszonen für Banking, Browsen, Arbeit und Privates.
Tails ist ein amnestisches Live-System für anonymes Arbeiten über Tor. Whonix kombiniert Workstation- und Gateway-VMs für Tor-vermittelte Sessions. Kicksecure härtet ein Debian-Derivat mit aggressiven Defaults. Secureblue ist ein Fedora-Atomic-Build mit hartcodierten Sicherheitsprofilen. Diese Systeme bieten Schutzlevel, die kein Windows und kein macOS in dieser Form erreicht. Sie sind allerdings, und das ist der Punkt, nicht das, was der durchschnittliche Linux-User auf seinem Notebook installiert.
Die Aktualisierungsgeschwindigkeit bei kritischen Lücken ist ein weiterer Pluspunkt. Distros wie Debian, Fedora und Ubuntu reagieren auf CVEs in Stunden bis Tagen. Ein Patch für Heartbleed war wenige Stunden nach Disclosure verfügbar, in den meisten Distributionen am gleichen Tag eingespielt. Bei Microsoft und Apple braucht ein Patch in der Regel länger, weil er den internen QA-Prozess durchlaufen muss. Wer aktiv updated, ist auf Linux oft schneller geschützt als auf den kommerziellen Systemen.
Fazit und warum der Mythos uns schadet
Linux ist nicht sicherer als Windows oder macOS, jedenfalls nicht in der Standard-Konfiguration der Mainstream-Distributionen. Linux ist anders sicher. Es bietet andere Werkzeuge, andere Trust-Modelle und andere Möglichkeiten zur Härtung. Wer das System aktiv konfiguriert, SELinux versteht, Disk Encryption aktiviert, Wayland verwendet, Flatpak-Permissions kontrolliert, einen TPM-Schlüsselbund einrichtet und seine Update-Disziplin pflegt, kann ein Linux-System in einen Zustand bringen, der sehr viele Angriffsvektoren schliesst. Wer Ubuntu installiert, durchklickt und drauflosarbeitet, fährt mit einem Sicherheitsmodell, das in zentralen Punkten dem Stand von 2008 entspricht, während Windows 11 und ein aktuelles macOS in den letzten zehn Jahren architektonisch fundamental aufgerüstet haben.
Der Mythos der überlegenen Linux-Sicherheit schadet uns aus drei Gründen. Er suggeriert Linux-Usern eine Sicherheit, die ihre Default-Konfiguration nicht hergibt, und führt damit zu Sorglosigkeit bei Update-Disziplin, Quellen-Wahl und Konfiguration. Er verhindert ehrliche Diskussionen darüber, welche strukturellen Probleme das Linux-Desktop-Ökosystem hat und welche Lösungen wir bauen müssten, um sie zu schliessen. Und er reproduziert ein Selbstbild der Community, das Kritik abwehrt, statt sich auf Verbesserungen einzulassen.
Sicherheit wird nicht durch das Wiederholen von Slogans erreicht, sondern durch das Schliessen konkreter Lücken, durch bessere Defaults, durch ehrliche Bestandsaufnahmen und durch Geld an den richtigen Stellen, allen voran bei den unterfinanzierten Kernprojekten, ohne die das ganze Ökosystem zusammenbrechen würde.
Heartbleed war ein Weckruf, nach dem die Linux Foundation die Core Infrastructure Initiative gegründet hat. Das hat geholfen, aber nicht alles geheilt. Die XZ-Backdoor von 2024 hat gezeigt, dass das Trust-Modell freier Software auch zwölf Jahre nach Heartbleed an denselben Stellen verletzbar ist. Wir können das Modell verbessern, indem wir Maintainer bezahlen, Defaults verschärfen, Sandboxing ernst nehmen, Hardware-Trust integrieren und ehrlich darüber sprechen, wo wir stehen. Wir können es nicht verbessern, indem wir Marketing-Slogans wiederholen, die offensichtlich nicht halten was sie versprechen.
Linux verdient einen ehrlichen Sicherheitsdiskurs.
