Nach einem Gefühlsausbruch zum Thema Kernel-Security ruderte Kernel-Chef Linus Torvalds tatsächlich ein wenig zurück und versuchte mit einer nur minimalen Zahl an Flüchen zu erklären, was in seinen Augen das Problem mit Security-Hardening im Kernel-Bereich ist.

Am Anfang der Diskussion standen “usercopy”-Patches von Kees Cook für Kernel 4.15, der sich im Rahmen des Kernel-Self-Protection-Projekts mehr um die Security kümmern will. Das ist keine leichte Aufgabe, denn wie der Thread deutlich macht, hat sein Chef klare Auffassungen vom Umgang mit Security und Patches.

Zunächst beschwerte sich Torvalds, etwas voreilig, bei Cook über Security-Patches, die Prozesse killen, obwohl der beanstandete Code von Cook lediglich Warnungen ausspucke. Trotzdem: “Security-Probleme sind lediglich Bugs” gab der Kernelchef sein bekanntes Argument einmal mehr zu Protokoll, und er wolle nicht mit Entwicklern zusammenarbeiten, die ihre Arbeit nicht als Debugging verstehen.

Später ruderte er etwas zurück und entschuldigte er sich gar für seine “harten Worte”. Schuld sei nicht nur der Stress im aktuellen Entwicklungszyklus und vor seinem Urlaub, sondern auf die schlechten Erfahrungen mit den letzten Patches, die Nutzerzugriffe sicherer machen (härten) wollten.

Drei Perspektiven

Später erklärte er gegenüber Jason Dornenfeld, dem Autor von Wireguard, nochmal recht ausführlich seine Sicht auf die Security-Situation.

Für ihn haben Sicherheitsforscher, Entwickler und User recht unterschiedliche Perspektiven auf Sicherheitsbugs. Die ersten haben ihren Job erledigt, wenn sie eine Lücke, etwa bei den Zugriffsrechten, gefunden, ausgenutzt, gemeldet und entschärft haben.

Von ihnen hält der Kernel-Chef nicht besonders viel, denn für Entwickler und verantwortungsbewusste Security-Leute beginne die eigentliche Arbeit erst an diesem Punkt. Für sie sei der unsichere Zugriff lediglich ein Symptom, sie müssen nun den Code debuggen und das Problem beheben.

Schließlich bliebe als Dritter im Bunde der User: Ihn treffen und/oder interessieren Security Bugs in der Regel nicht, er bemerke laut Torvalds aber sehr wohl die Folgen, falls Lücken nur notdürftig geflickt sind und ihren Workflow (zer)stören. Die Regel Nummer 1 in der Kernelentwicklung laute aber: Zerstöre nicht Deine Nutzer, denn ohne sie sei die Software wertlos.

Spagat ist machbar

Was Torvalds ärgere nun, dass es durchaus möglich wäre, sowohl die Entwickler als auch die User glücklich zu machen. Dazu müssten die Security-Leute aber das Hardening als Endpunkt sehen, nicht als erstes Ziel. Sie müssten über ihren Tellerrand schauen. Durch das richtige Härten des Kernels könnten Entwickler früher von Bugs erfahren, User würden bei späteren Problemen von der Vorarbeit profitieren.

Der erste Schritt, so Torvalds, müsse für Security-Forscher ohnehin sein, Fehler zu melden, und nicht, sie sofort zu reparieren (“Do no harm!”) Erfolgreich sei Code zum Härten des Kernel erst dann, wenn er tatsächlich mehrere Monate irgendwo produktiv im Einsatz war, wenn User auf seiner Basis Facebook besucht und Candy Crush gespielt hätten. Oder wenn er ein Jahr produktiv in Distributionen wie Ubuntu, Red Hat und Suse im Einsatz gewesen sei, also mit den vielen unterschiedlichen Treibern und diversen Apps getestet wurde.

Für Entwickler im Bereich der Kernel-Security dürfte Torvalds Exkurs keine uninteressante Information sein, wenn auch sicher nicht alle Security-Forscher seinen Standpunkt teilen. Kees Cook jedenfalls blieb trotz des Anraunzers cool und will den Code leicht modifiziert für die nächste Kernelversion 4.16 vorschlagen.