Login
Login-Name Passwort


 
Newsletter
Werbung

Fr, 18. Juli 2008, 14:17

Software::Kernel

Diskussion um Handhabung von Sicherheitsupdates im Linux-Kernel

Trotz der prompten Behebung aller Sicherheitslücken sind die Linux-Kernelentwickler nicht gewillt, Sicherheitslücken in den Änderungslogs besonders hervorzuheben.

Als Greg Kroah-Hartman am 2. Juli Linux 2.6.25.10 ankündigte, fand sich darin kein Hinweis auf behobene Sicherheitslücken. Die Formulierung, dass allen Anwendern »dringend« empfohlen werde, das Update vorzunehmen, konnte aber durchaus aufhorchen lassen. Aus der Beschreibung der zehn behobenen Probleme geht nichts Genaues hervor. Im Anschluss wunderten sich einige Entwickler, was diese Formulierung zu bedeuten habe.

Der Entwickler »PaX Team« verwies auf weitere Fehler, die ohne explizite Hinweise behoben wurden, und stellte die Frage, nach welchen Richtlinien sicherheitsrelevante Fehler bekanntgegeben werden und wie diese mit der offiziellen Sichtweise zusammenhängen, die in der Datei SecurityBugs im Verzeichnis Documentation des Kernels publiziert wurde. In dieser heißt es, dass die Kernel-Entwickler grundsätzlich jede Sicherheitslücke publizieren, wobei dies aus verschiedenen Gründen nicht immer sofort geschehen kann. Eine Wartezeit von einigen Tagen bis Wochen ist möglich.

Erst knapp zwei Wochen später antwortete Greg Kroah-Hartman, der zwischenzeitlich in Urlaub war, auf die Frage. Er stellte sich hinter die Aussagen der Datei SecurityBugs, fügte aber an, dass er es vermeide, Hinweise zu schreiben, die leicht zu einer Ausnutzung der Sicherheitslücke führen könnten. Wenn aber die Beschreibung der Patches bereits entsprechende Hinweise enthalte, werden sie auch übernommen. Allerdings merkte er noch an, dass sich das Dokument nur auf das Melden von Sicherheitslücken beziehe. Die Stable-Kernelserie bezieht ihre Patches überwiegend aus der Hauptlinie des Kernels, daher sei das Dokument für diese Patches nicht relevant.

Ähnlich äußerte sich Linus Torvalds, der sicherheitsrelevante Fehler genau wie normale Fehler behandelt. Es sei keine gute Idee, solche Fehler als etwas Besonderes herauszustellen. Es gebe keine Geheimhaltung der Fehler, allerdings würde er Beschreibungen kürzen, die Skript-Kiddies zu viele Hinweise geben würden.

Diese Antwort stellte einige Entwickler nicht zufrieden, denn diese Praxis sei effektiv eine Verschleierung von Problemen. Ginge es nach ihrem Willen, sollten die Kernel-Entwickler die Sicherheitsrelevanz jedes einzelnen Fehlers bewerten und in den Änderungslogs dokumentieren. Für Torvalds hingegen ist die Korrektur des Fehlers im Quellcode die Bekanntgabe des Fehlers. Würden solche Fehler ausdrücklich als sicherheitsrelevant publiziert, würde das seiner Ansicht nach fast zwangsläufig zu Wartezeiten führen, die er ablehnt, weil er Fehler so schnell wie möglich korrigieren will.

Nebenbei sei er der Meinung, dass die Linux-Distributoren mit ihren Sicherheitskorrekturen ihre Sache sehr schlecht machen. Auch für den »Sicherheitszirkus« habe er nichts übrig, denn er glorifiziere falsches Verhalten. Die Forscher, die Sicherheitslücken entdecken, würden zu Helden hochstilisiert, während die Arbeit an sonstigen Fehlerkorrekturen unterbewertet werde. Leute, die nur Schwarz und Weiß kennen, könne er nicht ausstehen. Leute, die die Sicherheit als ihr nahezu einziges Ziel sehen, wie die OpenBSD-Entwickler, seien ein Haufen masturbierender Affen. Auch die Mailingliste »vendor-sec«, auf der Sicherheitslücken des Kernels diskutiert werden, die noch nicht öffentlich sind, lehne er ab.

Die darauf folgende heftige Diskussion dürfte wohl kaum Auswirkungen auf die künftige Praxis haben. Während einige Leute glauben, dass es nützlich wäre, Informationen über die Sicherheitsrelevanz von Korrekturen zu haben, lehnt Torvalds diesen Standpunkt komplett ab. Es sei vom praktischen Standpunkt unmöglich, solche Informationen zuverlässig bereitzustellen, beispielsweise weil die genauen Auswirkungen eines Fehlers nicht bekannt sind oder nicht richtig eingeschätzt werden. Wer sich trotzdem diese Arbeit machen wolle, könne das tun. Viele Linux-Distributoren verfahren auf diese Weise.

Der Entwickler »PaX Team« beharrte weiter auf seinem Standpunkt, aber nach Hinweisen von Ted Ts'o und Mike Galbraith, dass er besseres Benehmen lernen und auf anderen Listen weiterspammen sollte, scheint die Diskussion jetzt beendet.

Werbung
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung