
Das ist zumindest die Meinung von Kees Cook vom Google Open Source Security Team, der viel Zeit in die Verbesserung der Sicherheit des Linux-Kernels steckt. Er begründet sein Statement mit der Tatsache, dass die nötigen Bugfix-Releases für den Mainline Kernel annähernd 100 Fixes pro Woche umfassen.
Angst vor Regressionen
Dies übe Druck auf Linux-Anbieter aus – einschließlich derjenigen, die die zahllosen Produkte unterstützen, auf denen Linux läuft, denn sie müssten ständig entscheiden, welche Patches für sie wichtig seien und dies dann einpflegen. Die ständige Aktualisierung des Kernels stoße vielerorts auf Ablehnung, so Cook, da immer die Gefahr bestehe, gleichzeitig Regressionen einzuführen.
Um die Dringlichkeit der Lage zu verdeutlichen, bezieht sich Cook auf Googles Fuzzing-Tool Syzcaller. das derzeit rund 1.000 mögliche Probleme im Kernel erkennt. Davon werden laut Cook rund 400 im Jahr beseitigt. Die Zahl der erkannten möglichen Probleme erhöhe sich jährlich um rund 100, sodass die Zahl der potenziellen Risiken ständig ansteige.
Denkbare Lösungen
Cook beschreibt in seinem Artikel einige für ihn denkbare Lösungen. Neben einer größeren Zahl von Testern vor einem stabilen Release nennt er die Verbesserung des Linux-Entwicklungs-Workflows als von entscheidender Bedeutung für die Erweiterung der Möglichkeiten aller Beteiligten, einen Beitrag zu leisten. Der E-Mail Arbeitsablauf von Linux sei in die Jahre gekommen, die vorgelagerte Entwicklung von automatisiertem Patch-Tracking, kontinuierlicher Integration, Fuzzing und vermehrten Tests würde den Entwicklungsprozess laut Cook deutlich effizienter machen.
100 Entwickler fehlen
Maintainer müssen neue Reviewer ausgiebig an ihrem Wissen über die einzelnen Sub-Systeme teil haben lassen, denn die Tester von heute seien die Maintainer von morgen. Cook schätzt, dass dem Kernel selbst, den Compilern und den Toolchains derzeit mindestens 100 Entwickler fehlen. Dieses Minus aufzufüllen sei die einzige Lösung, die ein ausgewogenes Maß an Sicherheit zu vernünftigen langfristigen Kosten gewährleisten könne, so Cook. Zudem müsse in der weiteren Entwicklung eine speichersichere Sprache wie Rust im Kernel gefördert werden.
Schreibe einen Kommentar