- 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 (
security@kernel.org) 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.“
Noch keine Kommentare.