© Maxim Evdokimov, 123RF

Der Linux-Kernel ist äußerst komplex, womit auch die Anzahl der Fehler und Verwundbarkeiten steigt. Entsprechend wichtig ist es, erkannte Fehler laufend zu bereinigen. KernelCare erledigt das schnell, sicher und im laufenden Betrieb.

Linux Magazin: Die großen Linux-Distributoren, also Red Hat, Ubuntu und Suse – bieten ja ihrerseits bereits Kernel-Live-Patching an. Warum sollte man das dann bei KernelCare einkaufen, wo liegen die Vorteile?

Igor Seletskiy: Während Suse beim Erzeugen und Anwenden der Patches einen eigenen Weg geht, verwenden Red Hat und Ubuntu die Live-Patching-Technologie, die zu den Bestandteilen des Kernels zählt. Diese Technologie verbessert sich mit jedem Tag, aber in älteren Kerneln wie etwa dem in RHEL 7 lassen sich längst nicht alle Bestandteile patchen. Selbst RHEL 8 und das aktuellste Ubuntu kann man nicht vollständig patchen. Zudem gibt es ein Problem mit der Konsistenz, wenn sich mehrere Patches zeitlich überlagern. Das ist einer der Gründe, weshalb Red Hat und Ubuntu empfehlen, das System spätestens alle drei Monate neu zu starten. Die Technik, die sie verwenden, macht es schwierig, den Kernel über lange Zeit immer wieder zu patchen.

KernelCare verwendet eine viel fortgeschrittenere Technologie. Daher konnten wir die Verwundbarkeiten im Zusammenhang mit den Meltdown- und Spectre-Schwachstellen patchen, was weder Red Hat noch Ubuntu gelang. Außerdem können wir Kernel über sehr lange Zeit fortlaufend patchen und Hunderte von Patches einspielen. Wir erreichen das durch ein atomares Patching: Wir kompilieren alle Patches zusammen, was die Konsistenz zur Kompilierzeit gewährleistet, statt sie einzeln anzuwenden und uns Sorgen um die Konsistenz zur Laufzeit machen zu müssen.

Wir haben Kunden, die bereits sechs Jahre ohne einen Neustart auskommen, und wir unterstützen sogar noch ältere Kernel. Wir patchen zehn Jahre alte Kernel, und es gibt dort keine Verwundbarkeit, für die wir keinen Patch im Fundus haben. Wir patchen so gut wie alles, sodass der Anwender jahrelang nicht zu rebooten braucht. Außerdem ist unser Service preisgünstiger als andere. Nicht zuletzt offerieren wir ein Live-Patching auch für Kernel, deren Hersteller das gar nicht anbieten, darunter für CentOS, Debian und EPEL-Kernel.

Linux Magazin: Kann ich mit KernelCare wirklich jeden Kernel jeder Distribution im laufenden Betrieb patchen, oder gibt es dann doch Einschränkungen hinsichtlich der Kernel-Versionen?

Igor Seletskiy: Wenn wir eine Distribution unterstützen, dann unterstützen wir typischerweise alle ihre Kernel. Wir haben den 32-Bit-Support mit RHEL 5 beendet, aber für RHEL 6 bis einschließlich 8 sowie Ubuntu 14.04 bis 20.04 sowie für CentOS patchen wir jeden Kernel dieser Distributionen. Insgesamt unterstützen wir mehrere Tausend Kernel.

Linux Magazin: Wie richte ich das Live-Patching praktisch ein? Können Sie uns ein Beispiel geben?

Igor Seletskiy: Der Deployment-Prozess ist sehr einfach; alles funktioniert mit nur zwei Kommandos (Listing 1) und, sehr wichtig, ohne Reboot. Diesen Install-and-forget-Prozess lassen die Kunden typischerweise direkt auf ihren Produktivsystemen laufen, ohne Downtime und ohne Nebenwirkungen auf andere Prozesse.

$ curl -s -L https://kernelcare.com/installer | bash
$ /usr/bin/kcarectl --<I>Registrierschlüssel<I>

Linux Magazin: Was, wenn ich einen kundenspezifischen Kernel verwende?

Igor Seletskiy: Wir haben mehrere Kunden, die ihre eigenen Kernel einsetzen, und wir müssen jeden davon extra in unser Angebot aufnehmen. Dazu integrieren wir ihn in unsere Bau- und Testumgebung. Normalerweise verwenden Kunden angepasste Kernel oder solche mit ein paar kleinen, spezifischen Änderungen. Alle 6 bis 12 Monate wird eine Bitte an uns herangetragen, einen weiteren Kernel hinzuzufügen.

Linux Magazin: Können Sie garantieren, dass die Patches keine unerwünschten Nebenwirkungen auf andere Features haben? Testen Sie das ausgiebig?

Igor Seletskiy: Ja, wir garantieren das in der Tat. Die Testumgebung gehört zu den wichtigsten Bestandteilen unseres Diensts. Wie schon gesagt, unterstützen wir Tausende Kernel und testen jeden einzelnen davon. Die Tests laufen bis zu 24 Stunden pro Kernel. Dabei prüfen wir mehrere Konfigurationen und Workloads.

Jeder Patch, den wir erzeugen, durchläuft Tests mit eigens von uns entwickelten Tools, die sicherstellen, dass der Patch die Schwachstelle tatsächlich beseitigt und dass er mit nichts anderem im System wechselwirkt. Dabei ist es hilfreich, dass wir hauptsächlich Sicherheitsschwachstellen patchen. Diese Patches ändern vergleichsweise wenig Code und keine Kernel-APIs. Der Meltdown-Patch war eine Ausnahme und alles andere als eine kleine Änderung am Code. Ihn zu testen, war ein Kraftakt.

Linux Magazin: Wie viel Zeit vergeht normalerweise zwischen dem Bekanntwerden einer Verwundbarkeit und der Verfügbarkeit eines entsprechenden Patches?

Igor Seletskiy: Manchmal veröffentlichen wir einen Patch zeitgleich mit dem Bekanntwerden der Verwundbarkeit. Wir lesen eine Reihe zur Geheimhaltung verpflichtetender Mailing-Listen mit und erfahren so von Schwachstellen, ehe sie veröffentlicht werden. Normalerweise legen wir zwischen einem und drei Tagen nach Veröffentlichung der Schwachstelle einen Patch vor.

Linux Magazin: Wenn ich sehr viele Systeme habe, kann der Patch-Prozess auf ihnen dann parallel laufen?

Igor Seletskiy: Das überlassen wir ganz dem Kunden. In der Voreinstellung fragt der Agent auf den Systemen des Kunden alle vier Stunden nach neuen Patches und installiert sie, sobald sie vorliegen. Viele unserer Kunden nutzen aber Ansible oder Puppet, um die Patches zu bestimmten Zeiten zu installieren. In diesem Fall werden dann normalerweise alle Server gleichzeitig gepatcht.

Linux Magazin: Um den Reboot zu vermeiden, müssen Sie den Kernel im Speicher patchen. Was passiert, wenn ich nun trotzdem neu starte? Habe ich dann meine Patches verloren?

Igor Seletskiy: Ja, genau das passiert. Wir gehen davon aus, dass das System mit einem Reboot einen neuen Kernel lädt. Manche unserer Kunden zertifizieren allerdings einmal jährlich einen Kernel und wollen mit genau demselben Kernel booten. In diesem Fall lädt KernelCare den Patch im Speicher in den Kernel, bevor der Netzwerkdienst startet. Sobald das Netzwerk hochgefahren ist, ist auch der Kernel wieder gepatcht.

Linux Magazin: Haben Sie vielen Dank für diesen interessanten Einblick, Herr Seletskiy!