Google sponsort zwei Entwickler, die sich um Schwachstellen im Linux-Kernel kümmern

Bei Google gibt es zwei Vollzeitstellen von Mitarbeitern, die sich ausschließlich um die Sicherheit des Linux-Kernels kümmern und diesen auf Schwachstellen analysieren. Zudem verlässt sich Google nicht auf externe Repositories für den Kernel, sondern baut sich diesen über interne Repositories.

Google sponsort 2 Stellen für Linux-Kernel-Sicherheit

Im Artikel Developers to Focus Exclusively on Security hat die Linux Foundation am 24. Februar 2021 die Kooperation mit Google bekannt gegeben. Google stellt vorrangig Mittel für zwei Vollzeit-Maintainer, Gustavo Silva und Nathan Chancellor, für die Linux-Kernel-Sicherheitsentwicklung bereit. Silva und Chancellor konzentrieren sich ausschließlich auf die Pflege und Verbesserung der Kernel-Sicherheit und damit verbundener Initiativen, um sicherzustellen, dass das weltweit am weitesten verbreitete Open-Source-Software-Projekt für die nächsten Jahrzehnte nachhaltig ist.

An Linux sin mehr als 20.000 Mitwirkenden beteiligt und mit Stand August 2020 gibt es mehr als eine Million Commits. Während es Tausende von Linux-Kernel-Entwicklern gibt, die alle die Sicherheit im Rahmen ihrer Arbeit berücksichtigen, signalisiert die Finanzierung von zwei Vollzeit-Linux-Sicherheitsbetreuer durch Google die Bedeutung der Sicherheit für die anhaltende Nachhaltigkeit von Open-Source-Software.

Aufgaben der beiden Entwickler

Nathan Chancellor konzentriert sich darauf, alle Fehler, die mit den Clang/LLVM-Compilern gefunden werden, zu beheben. Zudem arbeitet er daran, Systeme für die kontinuierliche Integration zu etablieren, um diese Arbeit kontinuierlich zu unterstützen. Sobald diese Ziele etabliert sind, plant Chancellor, den Linux-Kernel mit Hilfe dieser Compiler-Technologien zu verbessern und neue Funktionen hinzuzufügen. Chancellor arbeitet seit viereinhalb Jahren an dem Linux-Kernel. Vor zwei Jahren begann Chancellor, im Rahmen des ClangBuiltLinux-Projekts Beiträge zum Mainline-Linux zu leisten. Dabei handelt es sich um eine gemeinschaftliche Anstrengung, den Linux-Kernel mit den Compiler-Tools Clang und LLVM zu bauen.

Gustavo Silvas hauptberufliche Arbeit im Bereich Linux-Sicherheit widmet sich derzeit der Beseitigung mehrerer Klassen von Pufferüberläufen durch die Umwandlung aller Instanzen von Arrays mit Null-Länge und Ein-Element-Arrays in Flexible-Array-Mitglieder. Letzteres ist der bevorzugte und am wenigsten fehleranfällige Mechanismus zur Deklaration solcher Typen mit variabler Länge. Darüber hinaus konzentriert Silva sich aktiv darauf, Fehler zu beheben, bevor sie die Haupt-Entwicklungslinie erreichen. Parallel entwickelt er auch proaktiv Verteidigungsmechanismen, die ganze Klassen von Schwachstellen ausschalten. Silva speiste seinen ersten Kernel-Patch im Jahr 2010 in die Entwicklung ein und ist heute ein aktives Mitglied des Kernel Self Protection Project (KSPP). Mit mehr als 2.000 Commits in Mainline ist er seit 2017 konstant unter den Top fünf der aktivsten Kernel-Entwickler. Silvas Arbeit hat sich auf 27 verschiedene Stable-Trees ausgewirkt, bis hinunter zu Linux v3.16.

Google baut Linux-Kernel aus eigenem Repository

Bei The Register liest man hier, dass Google den Linux-Kernel aus dem Code seinen eigenen Repositories baut, anstatt fremde Binaries herunterzuladen. Und dies, obwohl diese Aufgabe angesichts der Geschwindigkeit, mit der Code zu Linux hinzugefügt wird, nicht trivial ist. Der Leiter des Open-Source-Sicherheitsteams von Google, Dan Lorenc, sprach mit The Register über seinen Ansatz und warum er trotz der Bequemlichkeit keine vorgefertigten Binärdateien verwenden wird.

Lorenc erklärt gegenüber The Register einige der Schritte, die Google unternimmt, um die Sicherheit von Open-Source-Code zu gewährleisten, den es intern verwendet, einschließlich Linux.

Eines der Dinge, die wir für jeden Open-Source-Code, den wir verwenden, zu tun versuchen, und etwas, das wir jedem empfehlen, der es verwendet, ist, dass man es selbst bauen kann. Es ist nicht immer einfach oder trivial, es zu bauen, aber zu wissen, dass man es kann, ist die halbe Miete, falls man es jemals braucht.

Wir verlangen, dass alle offenen Quellen, die wir benutzen, von uns selbst gebaut werden, aus unseren internen Repositories, nur um zu beweisen, dass wir es können, falls wir jemals einen Patch machen müssen, und damit wir wir wissen, woher der Code kommt. Das sind technisch gesehen Forks, aber nur eine Kopie des [öffentlichen] Projektarchivs, das wir auf dem neuesten Stand halten. Wir führen selten Patches in einem der Projekte an denen wir arbeiten durch, denn es ist einfach ein Wartungs-Albtraum. Aber wir können es bei Bedarf, wenn wir es brauchen.

Zum größten Teil bauen wir unsere eigenen Linux-Kernel. Für Linux ist das normal [wird von vielen Nutzern gemacht]. Aber dieser Ansatz ist für eine Reihe anderer Projekte außergewöhnlich bzw. seltsam, aber wir tun es.

Google verzichtet also auf die Bequemlichkeit der meisten Linux-Nutzer, ein Binär-Image für eine Linux-Distribution herunterzuladen und das, was benötigt wird, über einen Paketmanager zu installieren. Aber das verhindert auch, dass auf diesem Weg Sicherheitslücken unbemerkt in Googles Projekte einfließen. Alle Software-Komponenten sind bei ihrer Verwendung durch Google geprüft und bei entdeckten Schwachstellen kann das Unternehmen reagieren.

Lorenc gibt gegenüber The Register an, dass der Linux-Kernel riesig ist, und es sei Software und jede Software habe Bug. Die andere Sache sei, dass man sehr gut darin geworden ist, Bugs zu finden. Die statische Analyse habe einen langen Weg hinter sich, Fuzzing habe einen langen Weg hinter sich. Und das Team finde Bugs viel schneller als die internen Entwickler sie beheben können. Die nächste Herausforderung sei es, Wege zu finden, sie zu beheben. Lorenc sieht es als unbefriedigend an, nur zwei Entwickler zu sponsern, die bereits an der Linux-Sicherheit arbeiten. Das sei nicht annähernd eine Lösung.

Wenn man Bugs findet, für die niemand Zeit hat, sie sich anzusehen, löst man nicht wirklich das ganze Problem, so der Google-Mann. Es lohne sich trotzdem, sagt Lorenc, da es nicht viele solcher Leute gibt. "Wir haben letzte Woche eine Ankündigung rund um den Python-Interpreter gemacht. Wir haben für das nächste Jahr eine Vollzeitkraft eingestellt, die an CPython arbeitet. Die beste Schätzung ist, dass das eine 50-prozentige Steigerung der Anzahl der Leute ist, die in Vollzeit am Python-Interpreter arbeiten." Die Situation mit Vollzeit-Entwicklern, die an der Linux-Sicherheit arbeiten, könnte ähnlich sein, meint Lorenc.