Aus Linux-Magazin 01/2021

Aus dem Alltag eines Sysadmin: Live-Patching

Es gibt nur eines, was Charly noch weniger schätzt als Sicherheitslücken im Kernel: Downtimes seiner Maschinen. Seine Ubuntu-Systeme flickt er deswegen mit Canonicals Livepatch im laufenden Betrieb.

Sicherheitslücken im Kernel sind immer unschön, aber da es sich beim Linux-Kernel um eine sehr komplexe Software handelt, müssen sich Admins eine Strategie überlegen, damit umzugehen. Patches gibt es erfreulicherweise oft schon kurze Zeit nach der Entdeckung einer Schwachstelle, aber das Einspielen und der nachfolgende Neustart führen nun einmal zu einer – wenn auch meist kurzen – Nichtverfügbarkeit des Systems.

Für Ubuntu-Systeme hat der Distributor Canonical ein sehr einfach handhabbares Live-Patching-System entwickelt. Es flickt den Kernel, ohne einen Reboot zu erfordern. Das lässt den Admin ruhiger schlafen, und der Neustart des Systems kann ausfallen oder lässt sich auf einen günstigeren Zeitpunkt verschieben, etwa ein geplantes Wartungsfenster. Um das Live-Patching benutzen zu können, benötigen Sie einen Ubuntu-One-Account, den Sie unter https://auth.livepatch.canonical.com anlegen (Abbildung 1).

Abbildung 1: Canonicals Livepatch-Service erfordert eine Anmeldung.

Abbildung 1: Canonicals Livepatch-Service erfordert eine Anmeldung.

Wählen Sie Ubuntu user für einen kostenlosen Zugang. Damit können Sie maximal drei Ubuntu-Systeme mit dem Live-Patching ausrüsten. Es spielt dafür keinerlei Rolle, ob es sich um ein Notebook oder einen Server handelt. Benötigen Sie die Möglichkeit für mehr als drei Maschinen, wählen Sie die kostenpflichtige Option Canonical customer. Nach dem Sie Ihr Konto angelegt haben, präsentiert die Webseite Ihnen einen länglichen Schlüssel aus Hexadezimalzeichen, etwa »7b1fb58c00a64e1c9f9679304f066ef5«.

Das System, das Sie mit dem Live-Patching bestücken möchten, muss ein 64-Bit-Ubuntu mit der Kernel-Version 4.4 oder höher sein. Stellen Sie zunächst sicher, dass Snapd installiert ist (Listing 1, erste Zeile). Falls der Daemon fehlt, installieren Sie ihn nach (zweite Zeile). Danach benutzen Sie Snap, um das Live-Patching-System zu installieren (dritte Zeile). Jetzt können Sie das Live-Patching mit dem Schlüssel aktivieren, den Sie von der Canonical-Webseite erhalten haben (letzte Zeile).

Listing 1

$ dpkg -l | grep snapd
$ sudo apt install snapd
$ sudo snap install canonical-livepatch
$ sudo canonical-livepatch enable 7b1fb58c00a64e1c9f9679304f066ef5

Im Erfolgsfall meldet das System Successfully enabled device. Falls Sie unsicher sind, ob das Live-Patching auf einem bestimmten System aktiv ist oder nicht, können Sie das jederzeit mit »sudo canonical-livepatch status« herausfinden (Abbildung 2). Beachten Sie, dass das Live-Patching Ihnen keine neue Kernel-Version beschert. Es dient lediglich dazu, Sicherheitslücken im aktuell laufenden Betriebssystemkern ohne Reboot zu flicken. Eine Aktualisierung des Kernels erfordert nach wie vor den üblichen Installationsprozess samt Reboot. (jlu)

Abbildung 2: Der Livepatch-Status eines Systems lässt sich jederzeit prüfen.

Abbildung 2: Der Livepatch-Status eines Systems lässt sich jederzeit prüfen.

DIESEN ARTIKEL ALS PDF KAUFEN
EXPRESS-KAUF ALS PDFUmfang: 1 HeftseitePreis €0,99
(inkl. 19% MwSt.)
LINUX-MAGAZIN KAUFEN
EINZELNE AUSGABE Print-Ausgaben Digitale Ausgaben
ABONNEMENTS Print-Abos Digitales Abo
TABLET & SMARTPHONE APPS Readly Logo
E-Mail Benachrichtigung
Benachrichtige mich zu:
3 Kommentare
Älteste
Neuste Beste Bewertung
Maurice
4 Jahre her

Ich hab da bis jetzt noch keinen tieferen Sinn im Livepatching entdecken können. Es gibt ja nicht nur Kernelpatches, sondern idR mehr (Security)-Patches für irgendwelche Libraries. Und wenn ich eine Lib patche muss ich danach mindestens die Prozesse/Anwendungen neustarten die diese Libs nutzen, was bei libc oder openssl oder so nahezu alle sind, oder eben rebooten. Ich könnte also mit Livepatching des Kernels reboots verhindern, müsste dann aber nach jedem Patch einer Lib raussuchen welche Prozesse noch die ungepatchte Version im Speicher haben, und diese Anwendungen neustarten. D.h. für mich als Admin mehr Aufwand, eine höhere Fehleranfälligkeit und trotzdem eine… Mehr »

Kai Dupke
4 Jahre her
Reply to  Maurice

Gorße Server brauchen rel. lange, um neu zu starten. Daher ist jeder Neustart eines Servers etwas, was es zu vermeiden gilt.

Das gilt natürlich auch für vieles oberhalb des Kernels. Daher gibt es auch live patches für glibc und openSSL, weil das auch Systemteile sind, die fast ähnlich weit genutzt werden, wie der Kernel.

Disclosure: Ich arbeite für TuxCare, eine Division von CloudLinux, die sowohl Kernel, als auch Lib-Patches anbietet.

jon doe
3 Jahre her

canonical-livepatch status

Also Achtung.
“Free usage; This machine beta tests new patches.”

Nach oben