Sicherheitsarbeit am Linux-Kernel

• Das Linux-Kernel-Sicherheitsteam behebt gemeldete Schwachstellen so schnell wie möglich und merged sie in das öffentliche Repository, ohne gesonderte Mitteilungen oder Ankündigungen zu veröffentlichen
• Dieses Team ist von dem Kernel-CVE-Team, das für die Vergabe von CVEs zuständig ist, getrennt; alle Beteiligten handeln als Privatpersonen und arbeiten unabhängig von ihrer Unternehmenszugehörigkeit
• Sicherheitsbugs werden genauso behandelt wie normale allgemeine Bugs und nach der Behebung nicht gesondert als „Sicherheitspatch“ gekennzeichnet
• Eine Geheimhaltung (Embargo) von mehr als 7 Tagen wird nicht aufrechterhalten; die meisten Fixes werden sofort öffentlich gemacht
• Dieser Ansatz berücksichtigt die Eigenheiten von Open Source und vielfältige Einsatzumgebungen und wahrt Transparenz sowie Unabhängigkeit bei der Sicherheitsarbeit am Kernel

---

Die Rolle des Linux-Kernel-Sicherheitsteams

• Das Kernel-Sicherheitsteam ist eine Gruppe von Entwicklern, die gemeldete potenzielle Sicherheitsbugs einordnet und schnell behebt
  • Sie übernehmen die reaktive Sicherheitsarbeit getrennt von den langfristigen Präventionsmaßnahmen des Kernel Self-Protection Project
• Das Meldeverfahren erfolgt über einfache Text-E-Mails; HTML, binäre Anhänge und Verschlüsselung sind nicht erlaubt
  • Verschlüsselte Meldungen können wegen der Struktur mit mehreren Empfängern nicht verarbeitet werden
• Die Teammitglieder sind zentrale Entwickler, die wichtige Kernel-Subsysteme vertreten, und dürfen Diskussionsinhalte weder mit ihrem Arbeitgeber noch mit Außenstehenden teilen
  • Diese Unabhängigkeit ermöglicht ein konsistentes Vorgehen unabhängig von rechtlichen Anforderungen verschiedener Länder, etwa dem CRA

Ablauf der Fehlerbehebung

• Wenn ein gemeldeter Bug mit einem bestimmten Subsystem zusammenhängt, wird der entsprechende Subsystem-Maintainer in die E-Mail-Diskussion einbezogen, um das Problem zu lösen
  • Bei Subsystemen, in denen wiederholt Probleme auftreten, nimmt der Maintainer mitunter direkt an der Mailingliste des Sicherheitsteams teil
• Wenn der Melder einen Patch zur Behebung bereitstellt, wird ihm die Anerkennung dafür gegeben; andernfalls lösen die Entwickler das Problem selbst
• Nach Abschluss der Korrektur wird sie in den Mainline-Kernel-Branch und stabile Releases gemerged

Embargo-Richtlinie

• Eine nicht öffentliche Frist von mehr als 7 Tagen ist nicht zulässig, die meisten Fixes werden sofort veröffentlicht
• Nach der Korrektur kann der Melder auf Wunsch eine externe Mitteilung veröffentlichen, das Sicherheitsteam selbst macht jedoch keinerlei Ankündigungen
• Die Vergabe von CVEs übernimmt anschließend das Kernel-CVE-Team, getrennt vom Sicherheitsteam

Das Prinzip „Ein Bug ist nur ein Bug“

• Linus Torvalds stellte 2008 klar, dass Sicherheitsbugs nicht gesondert markiert werden sollten
  • Die Unterscheidung als „Sicherheitsfix“ verzerrt seiner Ansicht nach die Bedeutung anderer Bugs
• Alle Bugfixes sind gleich wichtig und werden ohne Unterscheidung nach Sicherheit, Funktion oder Performance sofort übernommen

Warum es keine Sicherheitsankündigungen gibt

• Nahezu jeder Bug auf Kernel-Ebene kann potenziell ein Sicherheitsproblem werden
  • Dazu gehören Speicherlecks, Denial-of-Service und Informationslecks in verschiedensten Formen
• Aufgrund der Open-Source-Natur kennen Entwickler die tatsächliche Umgebung der Nutzer nicht
  • Was für einen Nutzer eine kleine Korrektur ist, kann für einen anderen eine kritische Schwachstelle sein
• Daher ist die Richtlinie einfach
  • Bekannte Bugs sofort beheben
  • Korrigierte Releases so schnell wie möglich ausliefern
• Die Position lautet, dass es gefährlicher ist, bekannte Bugs unbehandelt zu lassen, als sich darüber zu sorgen, dass ein Fix Probleme verursachen könnte

Hardware-Sicherheitsprobleme

• Fälle wie Spectre und Meltdown, die sowohl Betriebssystem als auch Hardware betreffen, erfordern ein Ausnahmeverfahren
  • Dafür gibt es die „Hardware Security Policy“, über die die Zusammenarbeit über eine eingeschränkte verschlüsselte Mailingliste erfolgt
• Dieser Prozess ist langsam und komplex, doch in letzter Zeit werden viele Hardware-Bugs ohne dieses Verfahren gelöst
• Künftig dürften lange Embargos durch die Anforderungen des CRA an Reaktionszeiten noch schwieriger werden

Hintergrund zur Entstehung des Kernel-Sicherheitsteams

• Vor 2005 gab es keine offizielle Sicherheitskontaktstelle
  • Meldungen liefen nur über informelle Netzwerke zwischen Entwicklern
• 2005 begann die Diskussion mit einem E-Mail-Vorschlag von Steve Bergman;
  Chris Wright schrieb anschließend einen Patch, der einen Sicherheitskontakt und Dokumentation hinzufügte
  • Danach wurde ein zentraler E-Mail-Alias ([e-mail]) offiziell etabliert

Keine Sicherheitsankündigungen und keine Vorabbenachrichtigungen

• Das Kernel-Sicherheitsteam betreibt weder Sicherheitsankündigungen irgendeiner Art noch eine Vorabbenachrichtigungsliste
  • Die Vergabe von CVE-IDs übernimmt das Kernel-CVE-Team; das Sicherheitsteam ist daran nicht beteiligt
• Es gibt viele Anfragen nach einer Vorabbenachrichtigungsliste, doch wegen des Leckrisikos und des Prinzips der Öffentlichkeit existiert sie nicht
  • Die Haltung lautet: „Wenn eine Regierung das erlauben würde, wäre das Projekt wahrscheinlich in der Praxis gar nicht im Einsatz.“

---

[GN⁺]

Hacker-News-Kommentare

• In letzter Zeit entwickeln sich Technologien rasant weiter, die das Virtualisierungserlebnis auf Linux-Desktops nahtloser machen
  GPU-Treiber unterstützen über Mesa native Kontexte, und auch die Sharing-Funktionen zwischen Gast und Host unter Wayland werden verbessert
  Früher brauchte man komplexes Protokoll-Parsing wie mit sommelier oder wayland-proxy-virtwl, doch inzwischen setzt das Projekt wl-cross-domain-proxy das ordentlich um
  Als VMMs, die diese Funktionen nutzen, gibt es muvm, und als Lösung, die sie integriert, munix

  • Wirklich interessant. Ich frage mich, ob man Apps zwischen Maschinen, die munix verwenden, live migrieren kann
    Es wäre großartig, wenn man eine VM anhalten, übertragen und dann wieder fortsetzen könnte

• Deshalb ist Red Hat auch 2025 noch wichtig
  Solche Infrastrukturarbeit wird immer gebraucht

  • Man könnte eher das Gegenteil behaupten
    Wenn Red Hat sicherheitsrelevante Commits cherry-pickt, woher sollen sie wissen, welche Upstream-Commits sicherheitsrelevant sind, wenn das dort nicht kenntlich gemacht wird?

• Manchmal träume ich von einem 100 % sicheren OS
  Vielleicht sind formale Verifikation oder Rust der Schlüssel
  Ich hätte gern die Gewissheit, nicht gehackt werden zu können

  • Ein „OS, das nicht gehackt werden kann“ klingt toll. Aber am Ende bleiben Social-Engineering-Angriffe
    Der Mensch selbst ist letztlich die größte Schwachstelle
  • Solche Versuche gab es schon mehrfach. Microsofts Verve OS ist ein typisches Beispiel
    Sogar Assembler wurde verifiziert, und auch Dafny stammt von dort
    Aber auf dem Markt hat „schnell ausliefern statt gute Qualität“ Vorrang, deshalb dauert es Jahrzehnte, bis solche Ideen im Mainstream ankommen
  • Die Isolationsfunktionen, die in den meisten Fällen durch Sicherheitsbugs kompromittiert werden, werden in der Praxis oft nur aus Gründen der Verwaltungsfreundlichkeit genutzt
    Für echte Isolation braucht man Virtualisierung oder physische Trennung
    Deshalb ist es schwer, viele Mitwirkende für ein „100 % sicheres OS“ zu gewinnen
    Wenn dich das Thema trotzdem interessiert, gibt es mehrere OS-Entwicklungsprojekte
  • Dann nimm eben Qubes OS
  • Was Menschen geschaffen haben, können Menschen auch brechen
    Sicherheit ist ein endloser Wettlauf

• Andererseits unterstützt Gregs persönliche Website selbst im Jahr 2026 noch immer kein TLS

  • Ehrlich gesagt finde ich, dass es bis zur breiten Unterstützung von Encrypted Client Hello nicht wirklich nötig ist
    Die Einrichtung mit Caddy ist zwar einfach, aber bei einer statischen Website wie einem persönlichen Blog ist der praktische Nutzen von Verschlüsselung minimal
    Domain und IP werden ohnehin im Klartext offengelegt, also macht es keinen großen Unterschied

• Wenn sie das wirklich so meinen, hätten sie dann nicht die CNA entfernen müssen?

  • Das würde im Grunde bedeuten: „Jeder Sicherheitsforscher kann Kernel-Schwachstellen nach Belieben definieren“
    Aber manche Forscher neigen dazu, nur die Zahl der CVEs erhöhen zu wollen, und versuchen deshalb, selbst harmlosen Bugs hohe Priorität zu geben

• „Wenn man beim Melden eines Sicherheitsproblems Verschlüsselung erzwingt, sollte man diese Richtlinie überdenken (gemeint ist die britische Regierung)“
  Dieser Teil ist einfach nur lustig

• Die Aussage „Ein Bug ist nur ein Bug“ ist zu simpel
  Ein DoS, der Root-Rechte erfordert, und eine Systemübernahme durch einen nicht privilegierten Benutzer sind völlig unterschiedlich
  Manche Bugs verursachen klar einen Bruch der Sicherheitsgrenze und sollten als Sicherheitsbugs klassifiziert werden
  Greg wird das seit Jahrzehnten erklärt
  Unterm Strich ist der Kernel nicht vollständig gepatcht, wenn man nicht die neueste Version fährt
  CVEs werden gemieden, Fixes für Schwachstellen in Commit-Logs versteckt, und Angreifer erkennen das daran

  • „Dass nur die neueste Version gepatcht wird, gilt doch für die meiste Software, oder nicht?“
    Ich verstehe nicht, warum das hier extra betont werden muss

• Kunden verlangen Kernel-bezogene Patches in Docker-Images
  Dabei enthält Docker gar keinen Kernel
  Es sollte eine Möglichkeit geben, Images ohne Kernel zu verteilen

  • Kann der Linux-Kernel versehentlich in ein Container-Image aufgenommen werden?
    Gewöhnliche Base-Images enthalten keinen Kernel
  • Als zugehöriges Projekt lohnt sich ein Blick auf wolfi-dev