Das Linux-Universum hat sich für immer verändert. Seine Technologie ist nicht mehr nur ein „etwas Seltsames“ in Computergesprächen, sondern ist heute in Millionen von Smartphones, Tablets, Modems, Routern, Wearables und Fahrzeugen präsent, ganz zu schweigen von seiner Dominanz im Serverbereich. Mit dem Aufkommen des Internets der Dinge kann die Sicherheit des Linux-Kernels nicht bei ihrem aktuellen Modell bleiben, und viele Stimmen empfehlen die Umsetzung einer neuen Strategie, die es dem Kernel ermöglicht, „sich selbst zu schützen“ und den Schwachstellen einen Schritt voraus zu sein.
Zwei Meter von meinem Schreibtisch entfernt sammelt ein Smartphone mit Android 2.3 Staub, das heute als Taschenlampe dient. Obwohl ich nur einen Chip einsetzen müsste, damit es wieder seine ursprüngliche Rolle als Smartphone übernimmt, ist die Betriebssystemversion so alt, dass ich nicht weiß, ob es das Risiko wert ist. In derselben Situation befinden sich Millionen von Geräten mit einem Linux-Kernel im Hintergrund. Sie sind robust, flexibel und stabil, aber ohne Updates werden sie unsicher. Entwickler, Hersteller, Distributoren, Konnektivitätsanbieter und Nutzer – alle tragen eine Portion Schuld auf ihren Schultern, und wenn man das Potenzial des Internets der Dinge hinzunimmt, müssen wir über Millionen zusätzlicher Geräte sprechen, die komplett gefährdet sind. Man erwartet, dass einige dieser Geräte fünf oder zehn Jahre lang funktionieren, ohne ein einziges Update zu erhalten, und mit dieser Mechanik steckt der Linux-Kernel zwischen der sprichwörtlichen Scylla und Charybdis.
Das Kernproblem
Anders ausgedrückt: Der Linux-Kernel kann nicht weiterhin Bugs hinterherjagen. Laut Kees Cook, Entwickler bei Google und Leiter des Linux Kernel Self-Protection Project, liegt die „Lebensdauer“ eines Bugs im Kernel – also von seiner Einführung bis zum Patch – zwischen 3,3 und 6,4 Jahren. Diese Lücken sind zu einem inakzeptablen Parameter geworden, und Angreifer beobachten jeden neuen „Commit“ genau, um Bugs zu entdecken und auszunutzen. Das macht den erweiterten Schutz des Kernels zu einer grundlegenden Mission, aber es gibt noch ein weiteres Problem: 85 Prozent der Bugs im Kernel entstehen nicht in seinem Kern, sondern in den integrierten Treibern. Die geringe Qualitätskontrolle einiger Hersteller ist besorgniserregend und trägt zur Sicherheitsunsicherheit bei, die den Kernel durchdringt.
Nun sind die Herausforderungen nicht nur technischer Natur, sondern auch politisch. Geübte Augen werden bemerken, dass dieser „Konflikt“ viel mit der Debatte über „monolithischer Kernel vs. Microkernel“ gemeinsam hat, die Linux-Enthusiasten mehr als einmal aufgewühlt hat und weiterhin für bemerkenswerten Austausch sorgt. Dennoch, wie ich am Anfang sagte, hat sich das Linux-Universum für immer verändert. Neue Sicherheitsprobleme erfordern neue Lösungen, und eine Art „allgemeine Immunität des Kernels“ klingt gar nicht so schlecht. Die Treiber aus dem Kernel zu entfernen und ihre Funktion in den Userland-Bereich zu verlagern, ist weit davon entfernt, eine Zauberlösung zu sein, aber genau darum geht es: Es braucht keine Zauberlösungen, sondern robuste Lösungen, die den Kernel langfristig schützen. Der Vortrag von Kees Cook dauert etwas über 45 Minuten, und er erläutert darin einige Fortschritte des Self-Protection Projects sowie zusätzliche Vorschläge für die Zukunft. Wenn dich dieses Thema interessiert, ist es einen Blick wert.
