Bisher galt der Linux-Kernel als verlässliche und stabile Software, die dank grosser Sorgfalt der Entwickler und ausführlicher Code-Reviews nur verhältnismässig wenige Schwachstellen aufwies. Doch dieses Bild scheint in den letzten Tagen und Wochen einige Schrammen abbekommen zu haben. Alle paar Tage tauchten Advisors über neu entdeckte Lücken im Linux-Kernel auf, die zwar schon länger bekannt waren, aber während Wochen nicht behoben wurden. Besonders negativ fällt dabei der Kernel 2.6 auf. In der Community schlagen die Wellen entsprechend hoch. Für viele User ist klar: Das neue Entwicklungsmodell ist schuld.
Mitte Juli des letzten Jahres verkündeten «Linux-Vater» Linus Torvalds und Kernel-Maintainer Andrew Morton, dass man die Entwicklung des Linux-Kernels neu gestalten wolle. Statt wie bisher kurz nach dem Erscheinen einer stabilen Version einen Entwickler-Zweig abzuspalten und die stabile Version nur noch mit Bugfixes zu pflegen, wolle man Patches direkt in den jeweils als stabil gekennzeichneten Kernel einfliessen lassen. Die Argumente, mit denen dieser Paradigmen-Wechsel begründet wurde, leuchten durchaus ein: So könne man den Patch-Druck von der Entwickler- zur stabilen Version verringern und zudem kurzzeitige Instabilitäten vermeiden. Ausserdem müssten dann die Distributoren wie Suse oder Fedora nicht wie bis anhin ihre Kernel selber um Patches aus den Entwickler-Zweigen erweitern, womit der Aufwand für diese sinken würde. Die Reifung und Pflege eines stabilen Kernels soll dafür direkt bei den Distributoren stattfinden.
Schon damals schlug den Kernel-Hütern heftiger Protest ins Gesicht. Viele Anwender fürchteten eine Verschlechterung der Qualität. Doch die Opponenten fanden wenig Gehör, so dass der Protest ziemlich schnell verebbte. Doch nun, nach gut einem Jahr Kernel 2.6, sind die Wunden wieder aufgebrochen und auch der Ton ist rauher geworden, insbesondere, da die Kritiker prominente Unterstützung erhalten haben. So hat sich in der zweiten Januarwoche Brad Spengler, Entwickler des grsecurity-Patches zur Härtung des Linux-Kernels, zu Wort gemeldet.
In einer E-Mail an die bekannten Security-Mailinglisten kritisierte Spengler vor allem den mangelhaften Umgang mit Sicherheitsproblemen. So rechnete er vor, dass auf mehrere von ihm gefundene Sicherheitslücken, die er direkt an Torvalds und Morton berichtet hat, sowie die von ihm eingesandten Patches auch nach drei Wochen nicht reagiert wurde. Zudem fand er bei der Suche nach der Funktion copy_from_user in mehreren Kernel-Modulen innerhalb von 15 Minuten 4 potentielle Buffer Overflows. Spengler: «Ich würde wirklich gerne wissen, was gegen diesen erbärmlichen Trend bezüglich der Sicherheit von Linux getan wird, wenn es zehnmal einfacher ist, eine Schwachstelle im Kernel als in irgendeiner anderen Applikation auf dem System zu finden, und wenn iSec Security Research über mindestens eine kritische Schwachstelle in jeder Kernel-Version berichtet. Ich sehe nicht, dass das Entwicklungsmodell des Kernel 2.6 irgend etwas an dieser Situation verbessert, wie das Spektrum dieser Schwächen zeigt, wenn man experimentellen Code in den Kernel einfliessen lässt und ihn als stabil kennzeichnet.»
Dass dieser virtuelle Tritt vors Schienbein der Kernel-Entwickler nicht ganz unbegründet ist, zeigt ein Local Root Exploit auf SMP-Systemen, der nur wenige Tage nach Spenglers E-Mail von Paul Starzetz, iSec Security Research, gefunden wurde. Denn relativ bald stellte sich heraus, dass der Distributor Red Hat den Bug bereits früher entdeckt und in den eigenen Kerneln behoben hat, allerdings ist das Advisory anscheinend nie zu den Kernel-Entwicklern durchgedrungen, womit auch die wenigsten anderen Distributionen den Fehler beheben konnten.
Dass dies die ersten Symptome eines grösseren Problems sind, schälte sich auch recht bald bei den nachfolgenden Diskussionen heraus. So wurde das Fehlen eines Security-Beauftragten für den Linux-Kernel festgestellt, nachdem Alan Cox diese Aufgabe bereits seit einiger Zeit nicht mehr ausfüllt und sowohl Torvalds als auch Morton anscheinend zu überlastet sind, um die Probleme mit der nötigen Aufmerksamkeit zu verfolgen. Zudem zeigte sich, dass die schnelle Entwicklung und der recht grosse Umbau des Kernels zwischen den einzelnen Releases vor allem für Hersteller von Third-Party-Modulen ein Problem darstellt. Die Entwickler des PaX-Patches beklagten sich zum Beispiel, dass es durch die starken Veränderungen zwischen den einzelnen Versionen sehr schwierig sei, neue Funktionen zu PaX hinzuzufügen, um beispielsweise den Kernel besser schützen zu können.
Wie und ob diese Probleme adressiert werden, dürfte sich bei den diversen Diskussionen in der Community und auf der Mailingliste von Linux-Kernel zeigen. Dass eine Verbesserung der Situation dringend nötig ist, ist jedenfalls nicht von der Hand zu weisen.
