Was ist aus dem Versprechen geworden, Linux-Kernel live zu patchen? Dieser Artikel befasst sich mit seiner Geschichte, seinen Problemen und den billigsten und einfachsten Möglichkeiten, dies unter Ubuntu Focal Fossa (20.04 LTS) zu tun.
Einführung
„Live-Patching“ ist die Aktualisierung eines Programms, ohne das System, auf dem es ausgeführt wird, anzuhalten. Erst mit Lötzinn und Draht, später mit Schere und Kleber – nichts Neues. Heutzutage ist das Live-Patching von Linux-Kernels viel weniger schwierig.
In diesem Artikel werde ich erklären, was es ist, wie es funktioniert (in nicht-technischer Hinsicht) und woher es kommt. Abschließend zeige ich, wie Kernel-Sicherheitsupdates auf Ubuntu 20.04 LTS (Focal Fossa) mit Canonical Livepatch Service und KernelCare automatisiert werden.
Was ist Live-Patching?
In der Software ist ein Patch ein kleines Stück Code zur Korrektur. Patchen ist das Reparieren oder Verbessern eines kleinen Teils eines Programms, ohne die Funktionsweise oder Spezifikationen des Ganzen zu stören. Live- (oder Hot-)Patching bedeutet, ein laufendes Programm zu ändern, ohne es anzuhalten.
Stellen Sie sich vor, Sie sind in einem fahrenden Auto gefangen und müssen eine Glühbirne reparieren. Nicht schlecht, könnte man sagen, wenn es innen ist, außen etwas kniffliger. Stellen Sie sich jetzt vor, eine Nockenwelle zu reparieren, eine Kolbenstange auszutauschen oder einen gerissenen Block abzudichten.
Dies ähnelt dem, was Live-Patching auf dem Linux-Kernel versucht. Es versucht, die Teile von etwas in Bewegung zu reparieren, ohne es zu verändern oder zu beschädigen, aber vor allem, ohne es anzuhalten. Der Kernel ist der einzige Teil eines Linux-Systems, das heruntergefahren und neu gestartet werden muss, um ein Update anzuwenden. Wenn ein Anbieter ein Kernel-Update veröffentlicht, haben Systemadministratoren keine andere Wahl, als einen Neustart eines Servers zu planen.
Was ist so schlimm am Neustart?
Ein Neustart bedeutet für verschiedene Personen unterschiedliche Dinge, je nachdem, ob sie sich auf dem System befinden oder dafür verantwortlich sind. Viele Systemadministratoren betrachten regelmäßige Neustarts als Zeichen guter Gesundheit, wie regelmäßige Stuhlgänge. Genauso viele tun dies nicht, weil sie sich jeder Unterbrechung von Anwendungen widersetzen, in die sie investiert haben, und mit Anwendungen wie diesen Geld verdienen, zum Beispiel.
- Webserver mit beschäftigten, aktiven Benutzern in vielen Zeitzonen
- Online-Multiplayer-Spiele
- Pay-per-View Live- oder aufgezeichnetes Video-Streaming
- Mining von Kryptowährungen
- Remote-, 24/7-Videoüberwachungs- und Aufzeichnungsdienste
Der für mich am besten nachvollziehbare Grund ist die Angst, dass das System danach nicht mehr dasselbe ist und dass kritische (geldverdienende) Anwendungen nicht gestartet werden. Ich denke, es ist das, und nicht Visionen von randalierenden Benutzern, das viele Systemadministratoren dazu bringt, Kernel-Updates aufzuschieben, selbst die wichtigsten Sicherheitsupdates.
(Hier spreche ich nur von Updates . Kernel-Upgrades sind etwas anderes. Upgrades sind komplett neue Kernel. Patches sind Updates für Teile des Kernels, normalerweise Fehlerbehebungen, die nicht warten können, weil sie Sicherheits- oder andere weitreichende Auswirkungen haben.)
Wenn ein Linux-Anbieter einen Kernel-Patch veröffentlicht, dient dies normalerweise dazu, ein Sicherheitsproblem zu beheben. Der zugehörige Hinweis wird so etwas wie „Installieren Sie so bald wie möglich.“ Auf der gleichen Seite wird eine Version von „Wenn Sie dies nicht tun, werden Sie anfällig für die Exploits sein, die wir gepatcht haben und die jetzt jeder kennt Über. Ich wünsche Ihnen einen schönen Tag.“
Solche gefühllos geschriebenen Notizen verdeutlichen das Dilemma, das das Aufkommen von Live-Patching antreibt:Sollen Sie die Benutzer „wund, aber sicher“ oder „gelassen, aber exponiert“ halten? Live-Patching verspricht, die Paradiesinsel zwischen Rock und Hard Place zu werden. Live-Patching verspricht, Ihre Server sicher und auf dem neuesten Sicherheitsniveau zu halten, ohne Ausfallzeiten und ohne Beeinträchtigung von Diensten.
Paradiesinsel? Was ist der Haken?
Während der Quellcode für Live-Patching-Software frei verfügbar ist, sind es die Patches nicht. Das süße Versprechen des Live-Patchings wird sauer, wenn Sie Ihre eigenen Patches schreiben müssen. Ihr Blutdruck sinkt mit weniger Verwaltung, steigt aber wieder mit dem Umgang mit komplexem Kernel-Code.
Obwohl es technisch möglich ist, eigene Patches zu erstellen, erfordert dies viel Arbeit und viel Fachwissen. Und es ist riskant – ein schlecht geschriebener Patch kann ein System zum Absturz bringen. (Diese Meldung auf der kpatch-Github-Seite liest sich wie etwas aus der Bedienungsanleitung eines Dampfhammers:„WARNUNG:Mit Vorsicht verwenden! Kernel-Abstürze, spontane Neustarts und Datenverlust können auftreten!“)
Linux-Anbieter wissen, wie schwierig es ist, Live-Patching richtig durchzuführen, und haben profitable Serviceangebote entwickelt, um diese Tatsache zu nutzen. Jede größere Linux-Distribution hat einen Live-Patch-Ansatz, der kostenlos installiert, aber nicht verwendet werden kann. Die Patches, ohne die die ganze Idee nutzlos ist, müssen bezahlt werden.
Dennoch sind die Vorteile des Live-Kernel-Patchings so überzeugend, dass diese Geschäftsmodelle im überwiegend freien und Open-Source-Software-Ökosystem von Linux gedeihen. Für mich ist dies ein Zeichen dafür, dass die Technologie eine Bedeutung und eine wichtige Rolle in der Zukunft von Linux-basierten Systemen hat.
Wie Live-Patching funktioniert
Immer noch in diesem imaginären Auto gefangen, das jetzt bergab zu einem imaginären Stapel (hoffentlich) leerer Kartons donnert, wie würden Sie die Bremsen reparieren? Bauen Sie einen provisorischen Wagenheber, an dem Sie die Arbeit erledigen können? Auf drei Rädern nach vorne lehnen, warten, bis eines anhält, abnehmen, wiederholen, bis fertig?
Linux-Kernel-Programmierer müssen die gleiche Denkweise verwendet haben, als sie das Problem des Live-Patchings angegangen sind. Bei ihren Lösungen spüre ich den gleichen konzeptionellen Apparat (Aufhängung, Vertauschung, Einsatz temporärer Stützstrukturen). Meine grobe Bremswechsel-Analogie oben veranschaulicht zwei gegensätzliche Strategien, die von Anbietern von Live-Patching-Software implementiert werden.
- Alles stoppen und alle Korrekturen auf einmal durchführen.
- Warten Sie, bis einzelne Komponenten angehalten haben, und tauschen Sie sie dann aus. Wiederholen bis fertig.
Diese Unterteilung erklärt, warum jeder Anbieter unterschiedliche Lösungsansätze für dasselbe Problem entwickelt hat. Was sie jedoch gemeinsam haben, ist die Verwendung des ladbaren Kernelmodul-Frameworks von Linux. Die Software, die den Patch-Prozess orchestriert und implementiert, ist ein Linux-Kernel-Modul. Das bedeutet, dass es einfach ist, Patching-Funktionalität zu kompatiblen Kerneln hinzuzufügen und genauso einfach zu entfernen.
Bevor wir uns hinreißen lassen, muss ich die Vorbehalte erwähnen.
Umfang und Umfang der Software-Patches, die Sie auf laufende Systeme anwenden können, sind begrenzt. Zum einen machen angepasste, optimierte oder nicht standardmäßige Kernel es schwierig oder unmöglich, einen Kernel live zu patchen. Zum anderen kann Live-Patching keine Daten oder Speicher über Patches hinweg neu zuordnen; es kann nur Funktionsdefinitionen ändern.
Diese Mängel hinderten Ksplice nicht daran, das erste Unternehmen im Bereich Linux-Live-Patching zu werden. Es funktioniert, indem es alten und neuen Quellcode vergleicht, aus dem es einen binären Patch erstellt. Es friert das System ein, findet heraus, welche Funktionen geändert werden müssen, und bearbeitet ihre Kopfzeilen. Beim Aufruf leiten Funktionen zu den neuen Versionen um. Wenn der Patch gut geschrieben ist, wird die Steuerung fortgesetzt, als ob nichts passiert wäre.
Bei einem seismischen Ereignis (das im nächsten Abschnitt beschrieben wird) kamen Kpatch von Red Hat und Kgraft von SUSE mit ihren eigenen Interpretationen der Kernprobleme des Live-Patchings auf die Bühne.
Kpatch vergleicht alten und neuen Quellcode, um Patches zu erstellen. Wie Ksplice funktioniert es, indem es Funktionsaufrufe mithilfe des Kernel-FTrace-Frameworks umleitet, um geänderte Funktionen auf einmal umzuschalten.
Kgraft funktioniert anders. Es verwendet zwei parallele Sätze von Funktionen, alte und neue, wobei ein Orchestratormodul entscheidet, wann Funktionen umgeleitet werden, je nachdem, wo die Ausführung angekommen ist. Es ist unmöglich vorherzusagen, wo sich in einer Funktion ein Programmzeiger zu einem bestimmten Zeitpunkt befindet, daher erfolgt der Übergang allmählich und nicht sofort.
Die Ursprünge des Live-Patchings
Wie kam die Idee, Software unbemerkt zu reparieren, in diesen sich ständig verändernden Monolithen menschlicher Bemühungen, den Linux-Kernel?
Obwohl das Konzept bis in die frühesten Tage programmierbarer Berechnungen zurückreicht, beginnt der Weg für unsere Zwecke im Jahr 2001, als Hewlett Packard eine Möglichkeit patentiert, Software dynamisch zu aktualisieren, um fehlende Hardwarefunktionen zu kompensieren. Ein Jahr später präsentiert Microsoft eine Idee zur Aktualisierung eines Systems (Windows) ohne Unterbrechung.
Keiner erwähnt Linux, aber die Anwendungen sind breit gefächert und beschreiben jeweils, wie Software- oder Hardwareprobleme auf einem Computer behoben werden können, ohne die darauf laufenden Prozesse zu unterbrechen. (Wenn Ihnen die Idee nicht besonders nützlich erscheint, werden Sie vielleicht zwei Wörter zum Nachdenken anregen:Meltdown und Spectre.)
2008 kündigt Jeff Arnold Ksplice an, eine Software zum Patchen von Linux-Kerneln, ohne sie neu zu starten. Es ist das erste seiner Art für Linux. Und wir haben es einem unbekannten, namenlosen Hacker zu verdanken.
Um zu sehen, warum, lassen Sie mich Sie zurück in Jeffs MIT-Studentenzeit bringen. Er ist Mitglied einer Freiwilligengruppe, die Server für die Studentengemeinschaft verwaltet. Einer der Server benötigt einen Sicherheitspatch. Er möchte seine Nutzer nicht abschrecken, also lässt er es für ein paar Tage schleifen.
In diesen wenigen Tagen, bevor er es aktualisieren kann, hackt jemand das System. Die einzige Möglichkeit, es wieder online zu bekommen, besteht darin, es komplett von Grund auf neu zu installieren. Nehmen wir an, seine Kollegen bemerken es. Selbst wenn sie nicht leiden, stelle ich mir vor, dass Jeff den Rest des Semesters damit verbringt, langsam auf der Asche des Studentenspotts zu rösten.
Wenn die Geschichte apokryph ist, dann betrachten Sie sie als Fabel, eine Erinnerung daran, dass Live-Patching das Kind der Sicherheit ist, nicht der Bequemlichkeit. Und wie alle guten Fabeln gibt es ein Happy End.
Der Vorfall inspiriert Jeff dazu, zu untersuchen, wie Linux-Kernel-Patches ohne Verzögerung und ohne Unterbrechung installiert werden können. Diese Problematik macht er zum Thema seiner Masterarbeit 2006. Die Lösung kommt in Form einer Software namens Ksplice. Zusammen mit einem Kollegen schreibt er eine Abhandlung mit dem Titel „Ksplice:Automatic Rebootless Kernel Updates.“
Jeff und drei seiner Studentenkollegen gründen ein Unternehmen und gewinnen im Mai 2009 den Preis des MIT $100.000 Entrepreneurship Competition. Sie starten 2010 einen kommerziellen Dienst. Ein weiteres Jahr später, in der Art von karmischer Schließung, von der jeder Softwareentwickler träumt, kauft Oracle Ksplice Inc.
Karma ist weit entfernt von den Köpfen der Benutzer und Kunden dieses erstaunlich nützlichen neuen Dienstprogramms. Für sie ist es der Beginn einer langen und anstrengenden Reihe von Alpträumen. Oracle integriert Ksplice vollständig und macht das Tool nur für Kunden ihrer eigenen, gegen eine Supportgebühr finanzierten Linux-Versionen werkzeugfrei.
Dieser seismische Schock spornt SUSE und Red Hat dazu an, ihre eigenen Lösungen zu entwickeln, ohne sich gegenseitig über ihre Absichten oder Lösungsarchitekturen zu informieren. Sie arbeiteten isoliert von 2011 bis 2014 und veröffentlichten ihre eigenen unterschiedlichen Ansätze innerhalb weniger Wochen. Und im Mai 2014 veröffentlicht CloudLinux, Hersteller einer in Webhosting-Sphären bekannten Linux-Variante, einen kommerziellen Linux-Kernel-Live-Patching-Service unter dem Namen KernelCare.
Gleichzeitig arbeitet sich eine Live-Patching-ABI in die Kernel-Mainline ein und erblickt im Release 4.0 unter dem Namen Livepatch das Licht der Welt. Im Oktober 2016 verwenden Canonical, die Schöpfer von Ubuntu, es als Grundlage für kommerzielle Dienste unter dem unverschämt angeeigneten Namen „Canonical Livepatch Service“. Canonical veröffentlicht es zuerst für 16.04 LTS, dann 14.04 LTS, beide erfordern eine Einrichtung auf der Befehlszeile. In 18.04 LTS wurde es sichtbarer, einfacher zu verwenden und besser in das Ubuntu-Desktop-Erlebnis integriert und ist jetzt für 20.04 LTS verfügbar.
Vorgehensweise:Automatisierte Kernel-Sicherheitsupdates auf Ubuntu 20.04 LTS
Jetzt ist es an der Zeit, es in Aktion zu sehen. Es gibt zwei Live-Patch-Lösungen für Ubuntu, die in den nächsten beiden Abschnitten behandelt werden.
Installieren des Canonical Livepatch Service (CLS)
CLS ist für nicht-gewerbliche Personen für bis zu drei Maschinen kostenlos. Es erfordert eine Registrierung, aber Sie können ein Ubuntu One-Konto verwenden, wenn Sie eines haben. Wenn Sie es auf mehr als drei Computern installieren möchten, müssen Sie einen Enterprise-Support-Servicevertrag erwerben.
Bevor Sie beginnen
- Stellen Sie sicher, dass Ihr System auf dem neuesten Stand und gesichert ist.
- Registrieren Sie sich für ein Livepatch- oder Ubuntu One-Konto.
- Besorgen Sie sich für 20.04 LTS Server einen Schlüssel und notieren Sie ihn. (Dies wird in der Desktop-Edition nicht benötigt.)
Installieren von Livepatch auf Ubuntu 20.04 LTS Desktop
Ubuntu 20.04 LTS Desktop verfügt über eine GUI-Einstellung zum Aktivieren des CLS. Sie können dies entweder während der Einrichtung nach der Installation oder später tun, indem Sie "Software &Updates" öffnen und zur Registerkarte "Livepatch" gehen.
Auf einer neuen Ubuntu-Installation
Achten Sie nach dem ersten Neustart einer Neuinstallation auf den zweiten Bildschirm des Dialogfensters „Was ist neu in Ubuntu“. Damit können Sie Livepatch einrichten.
- Klicken Sie auf „Livepatch einrichten…“
- Melden Sie sich auf dem Bildschirm „Ubuntu Single Sign-On Account“ mit Ihrem Livepatch- oder Ubuntu One-Konto an.
- Wenn Sie die textbasierte Installations-GUI verwenden, wählen Sie unter „Featured Server Snaps“ canonical-livepatch.
Auf einer bestehenden Ubuntu-Installation
- Öffnen Sie „Software &Updates“ und gehen Sie zur Registerkarte „Livepatch“.
- Melden Sie sich an.
- Klicken Sie nach der Anmeldung auf "Fortfahren", wenn das Popup-Fenster erscheint, das bestätigt, dass Sie angemeldet sind.
- Das war's. Der Livepatch wird auf Ihrem Ubuntu 20.04 Desktop eingerichtet.
Fehler in Ubuntu 20.04 mit Livepatch
Beim Aktivieren von Livepatch auf Ubuntu 20.04 Focal Fossa kann der folgende Fehler auftreten:
Failed to enable Livepatch: cannot enable machine: this machine ID is already enabled with a different key or is non-unique. Either "sudo canonical-livepatch disable" on the other machine, or regenerate a unique /etc/machine-id on this machine with "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup" server response: Conflicting machine-id
Um den Fehler zu beheben, geben Sie die folgenden Befehle im Terminal ein:
cp /etc/machine-id /etc/machine-id.original
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original
nano /etc/machine-id (to remove the existing value)
systemd-machine-id-setup
> Initializing machine ID from D-Bus machine ID.
cat /etc/machine-id
Installieren von Livepatch auf Ubuntu 20.04 LTS Server
Dies ist der Befehlszeilenansatz für Standardserverversionen ohne installiertes Fenstersystem. Es funktioniert auch mit den Versionen 16.04 LTS, 14.04 LTS und 18.04 LTS.
Öffnen Sie ein Terminal und geben Sie diese beiden Befehle ein:
sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>
Tipps
- Der zweite Befehl gibt ein Maschinentoken zurück. Es dient keinem Zweck und muss nicht aufgezeichnet werden.
- Behalten Sie den Überblick über die Maschinen, die Sie registrieren. Wenn Sie den Überblick verlieren oder eine Maschine oder VM vor der Deregistrierung entsorgen, werfen Sie effektiv eine Ihrer drei kostenlosen Lizenzen weg. (Hier gibt es Hilfe.)
- Um einen Server abzumelden, verwenden Sie diesen Befehl:
sudo canonical-livepatch disable <your key>
- Um den Status des Dienstes zu überprüfen, verwenden Sie diesen Befehl:
sudo canonical-livepatch status --verbose
Installation von KernelCare
KernelCare verwendet ein Befehlszeilen-Setup; es gibt keine GUI. Es unterstützt eine breitere Palette von Betriebssystemen, darunter CentOS, RHEL, Oracle Linux, Debian, Ubuntu und andere. Es unterstützt auch die ältere 2.6.32-Kernellinie.
Im Gegensatz zu CLS ist es voll automatisiert und prüft alle vier Stunden auf Patch-Releases und installiert diese ohne Aufsicht, falls vorhanden. Wenn Sie diese Fähigkeit außer Kraft setzen oder Server an Patches mit festem Datum binden müssen, gibt es ein Befehlszeilenprogramm (kcarectl), mit dem Sie dies und andere Dinge tun können.
KernelCare ist für gemeinnützige Organisationen kostenlos, oder für den Rest von uns gibt es eine kostenlose 30-Tage-Testversion. (Wenn Sie ein Ksplice-Benutzer sind, möchten Sie vielleicht das zweistufige Ksplice-zu-KernelCare-Migrationsskript ausprobieren.)
Bevor Sie beginnen
- Stellen Sie sicher, dass Ihr System auf dem neuesten Stand und gesichert ist.
- Holen Sie sich hier einen kostenlosen Testschlüssel.
Installieren von KernelCare auf Ubuntu 20.04 LTS Desktop und Server
Öffnen Sie ein Terminal und geben Sie diese beiden Befehle ein:
sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY
Diese Befehle funktionieren auch in den Versionen 16.04 LTS, 14.04 LTS und 18.04 LTS.
Tipps
- Um einen Server abzumelden, verwenden Sie diesen Befehl:
sudo kcarectl --unregister
- Um den Status des Dienstes zu überprüfen, verwenden Sie diesen Befehl:
sudo kcarectl --info
Schlussfolgerung
Live-Patching unter Linux war viel zu nützlich, um lange kostenlos zu bleiben.
Mit der Version 20.04 LTS von Ubuntu ist es einfacher, die Vorteile des Live-Sicherheitspatches von Linux-Kernels zu nutzen, und es ist kostenlos für bis zu drei Hosts. Danach fallen jährliche Gebühren pro Server an.
Wenn Sie viele Linux-Varianten verwenden, aber nicht verschiedene Produkte lernen oder verschiedene Supportverträge abonnieren möchten, werfen Sie einen Blick auf KernelCare. Es ist etwa fünfmal günstiger, wenn Sie es jährlich abonnieren, und sie bieten flexible monatliche Abonnements an.