Linux Kernel Live Patchen op Ubuntu 20.04 LTS

Wat is er gebeurd met de belofte van het live patchen van Linux kernels? Dit artikel bekijkt de geschiedenis ervan, de problemen, en de goedkoopste en gemakkelijkste manieren om het te doen op Ubuntu Focal Fossa (20.04 LTS).

Inleiding

‘Live patchen’ is het bijwerken van een programma zonder het systeem waarop het draait te stoppen. Het werd eerst gedaan met soldeer en draad, later met schaar en lijm – het is niets nieuws. Tegenwoordig is het live patchen van Linux kernels veel minder klef.

In dit artikel leg ik uit wat het is, hoe het werkt (in niet-technische termen), en waar het vandaan komt. Ik eindig met te laten zien hoe je kernel beveiligingsupdates kunt automatiseren op Ubuntu 20.04 LTS (Focal Fossa) met Canonical Livepatch Service en KernelCare.

Wat is Live Patchen?

In software is een patch een klein stukje rechtzettende code. Patchen is het repareren of verbeteren van een klein deel van een programma zonder de werking of de specificaties van het geheel te verstoren. Live (of hot) patchen betekent een lopend programma veranderen zonder het te stoppen.

Stel je voor dat je vast zit in een rijdende auto en je moet een lampje repareren. Niet zo erg, zou je zeggen, als het aan de binnenkant is, een beetje lastiger aan de buitenkant. Stel je nu voor dat je een nokkenas moet repareren, een zuigerstang moet vervangen, of een gebarsten blok moet dichten.

Dit is verwant aan wat live patchen probeert te doen aan de Linux kernel. Het probeert de onderdelen van iets in beweging te repareren, zonder het te veranderen of te breken, maar vooral, zonder het te stoppen. De kernel is het enige deel van een Linux systeem dat een shutdown en herstart nodig heeft om een update toe te passen. Wanneer een leverancier een kernel update uitbrengt, hebben systeembeheerders geen andere keus dan een reboot van een server te plannen.

Wat is er zo erg aan rebooten?

Een reboot betekent verschillende dingen voor verschillende mensen, afhankelijk van of ze op het systeem zitten of er de leiding over hebben. Veel sysadmins beschouwen regelmatige reboots als een teken van een goede gezondheid, zoals regelmatige darmen. Evenveel doen dat niet, en verzetten zich tegen elke verstoring van toepassingen waarin ze geïnvesteerd zijn en waar ze geld mee verdienen, toepassingen als deze, bijvoorbeeld.

  • webservers, met drukke, actieve gebruikers in vele tijdzones
  • online multiplayer spelletjes
  • pay-per-view live of opgenomen videostreaming
  • ontginnen van cryptocurrency
  • tele, 24/7 videobewaking en opnamediensten

Voor mij is de meest relateerbare reden de angst dat het systeem daarna niet meer hetzelfde zal zijn, en dat kritieke (geld verdienende) toepassingen niet meer zullen opstarten. Ik denk dat het dit is, en niet visioenen van woekerende gebruikers, dat veel systeembeheerders ertoe brengt kernel updates uit te stellen, zelfs de belangrijkste soort, beveiligingsupdates.

(Hier heb ik het alleen over updates. Kernel upgrades zijn iets anders. Upgrades zijn compleet nieuwe kernels. Patches zijn updates van delen van de kernel, meestal bug fixes die niet kunnen wachten omdat ze beveiligingsproblemen of andere verstrekkende gevolgen hebben).

Wanneer een Linux leverancier een kernel patch uitbrengt, is dat meestal om een beveiligingsprobleem op te lossen. De bijbehorende waarschuwing zegt iets als, ‘Installeer zo snel mogelijk,’ Op dezelfde pagina staat een versie van, ‘Als je dat niet doet, ben je kwetsbaar voor de exploits die we hebben gepatcht en die iedereen nu kent. Nog een prettige dag verder.’

Zulke gevoelloos geschreven briefjes benadrukken het dilemma dat de opkomst van live patching drijft: moet je gebruikers ‘pijnlijk maar veilig’ houden, of ‘samengesteld maar blootgesteld’? Live patching belooft het Paradijseiland te zijn tussen Rots en Harde Plaats. Live patching belooft je te helpen je servers veilig en op de nieuwste beveiligingsniveaus te houden, zonder dat de downtime eronder lijdt, en zonder dat de dienstverlening eronder lijdt.

Paradijselijk eiland? Wat is het addertje onder het gras?

Hoewel de broncode voor live patching software vrij beschikbaar is, zijn de patches dat niet. De zoete belofte van live patching verzuurt wanneer je je eigen patches moet schrijven. Je bloeddruk neemt af met minder administratie maar stijgt weer bij het hanteren van complexe kernel code.

Hoewel het technisch mogelijk is om je eigen patches te maken, kost het veel werk en veel gespecialiseerde kennis. En het is riskant-een slecht geschreven patch kan een systeem laten crashen. (Dit bericht op de kpatch github pagina leest als iets uit de handleiding van een stoomhameroperator: ‘WAARSCHUWING: Gebruik met voorzichtigheid! Kernel crashes, spontane reboots, en gegevensverlies kunnen optreden!’)

Linux verkopers weten hoe moeilijk het is om live patchen goed te doen, en hebben winstgevende diensten ontwikkeld om van dit feit te profiteren. Elke grote Linux distributie heeft een live patching aanpak die gratis is om te installeren, maar niet om te gebruiken. Voor de patches, zonder welke het hele idee zinloos is, moet betaald worden.

Toch zijn de voordelen van live kernel patching zo overtuigend dat deze bedrijfsmodellen goed gedijen in Linux’s overwegend vrije en open bron software ecosysteem. Voor mij is dit een teken dat de technologie betekenis heeft en een belangrijke rol speelt in de toekomst van op Linux gebaseerde systemen.

Hoe Live Patching werkt

Nog steeds gevangen in die denkbeeldige auto, die nu bergafwaarts dendert in de richting van een denkbeeldige stapel (hopelijk) lege kartonnen dozen, hoe zou je de remmen repareren? Een tijdelijke rollende krik bouwen waarop je het werk kunt doen? Voorover leunen op drie wielen, wachten tot er een tot stilstand komt, afzetten, herhalen tot je klaar bent?

Linux kernel programmeurs moeten eenzelfde soort denkwijze gebruikt hebben bij het aanpakken van het probleem van live patchen. Ik voel hetzelfde soort conceptueel apparaat (opschorten, verwisselen, het gebruik van tijdelijke ondersteunende structuren) aan het werk in hun oplossingen. Mijn ruwe rem-omwissel analogie hierboven illustreert twee tegengestelde strategieën die door live patching software verkopers worden toegepast.

  • Stop alles en doe alle fixes in één keer.
  • Wacht tot afzonderlijke componenten stoppen, verwissel ze dan. Herhaal tot je klaar bent.

Deze tweedeling verklaart waarom elke verkoper met verschillende benaderingen komt om hetzelfde probleem op te lossen. Wat ze echter wel delen is het gebruik van de Linux laadbare kernel module raamwerk. De software die het patchen orkestreert en uitvoert is een Linux kernel module. Dat betekent dat het gemakkelijk is om patching functionaliteit toe te voegen aan compatibele kernels, en even gemakkelijk om ze te verwijderen.

Voor we ons laten meeslepen, moet ik de voorbehouden noemen.

Er is een grens aan de omvang en reikwijdte van software patches die je op draaiende systemen kunt toepassen. Ten eerste maken aangepaste, geoptimaliseerde, of niet-standaard kernels het moeilijk of onmogelijk om een kernel live te patchen. Bovendien kan live patchen geen gegevens of geheugen over patches heen verplaatsen; het kan alleen functiedefinities veranderen.

Deze tekortkomingen weerhielden Ksplice ervan om de eerste te worden op het gebied van Linux live patching. Het werkt door oude en nieuwe broncode te vergelijken, waarvan het een binaire patch maakt. Het bevriest het systeem, zoekt uit welke functies veranderd moeten worden, en wijzigt hun headers. Wanneer ze aangeroepen worden, wijken functies uit naar de nieuwe versies. Als de patch goed geschreven is, gaat de besturing verder alsof er niets gebeurd is.

Een seismische gebeurtenis (beschreven in de volgende sectie) zag Red Hat’s Kpatch en SUSE’s Kgraft het toneel betreden met hun eigen interpretaties van de kernproblemen van live patchen.

Kpatch vergelijkt oude en nieuwe broncode om patches te maken. Net als Ksplice werkt het door functie-aanroepen om te leiden met behulp van de kernel ftrace kader om gewijzigde functies in één keer om te wisselen.

Kgraft werkt anders. Het gebruikt twee gelijktijdige sets van functies, oude en nieuwe, waarbij een orchestrator module beslist wanneer functies moeten worden omgeleid, afhankelijk van waar de uitvoering is aangekomen. Het is onmogelijk te voorspellen waar in een functie een programma-aanwijzer zich op een bepaald moment bevindt, dus de overgang verloopt geleidelijk, niet ogenblikkelijk.

De oorsprong van Live Patching

Hoe kwam het idee om software te repareren zonder dat iemand het merkt terecht in die steeds veranderende monoliet van menselijke inspanning, de Linux kernel?

Hoewel het concept teruggaat tot de vroegste dagen van programmeerbaar rekenen, begint voor ons doel het spoor in 2001 toen Hewlett Packard een patent indiende op een manier om software dynamisch bij te werken ter compensatie van ontbrekende hardwarefunctionaliteit. Een jaar later, Microsoft een idee voor het bijwerken van een systeem (Windows) zonder onderbreking.

Geen van beide noemt Linux, maar de toepassingen zijn breed, elk beschrijft hoe software of hardware problemen op een computer verholpen kunnen worden zonder onderbreking van de processen die er op draaien. (Als het idee je niet bijzonder nuttig lijkt, zullen misschien twee woorden je nog eens aan het denken zetten: Meltdown en Spectre.)

In 2008, kondigt Jeff Arnold Ksplice aan, software om Linux kernels te patchen zonder ze opnieuw op te starten. Het is de eerste in zijn soort voor Linux. En we hebben er een onbekende, naamloze hacker voor te danken.

Om te zien waarom, neem ik je mee terug naar Jeff’s MIT studententijd. Hij is lid van een vrijwilligersgroep die servers beheert voor de studentengemeenschap. Een van de servers heeft een beveiligingspatch nodig. Hij wil zijn gebruikers niet wegsturen, dus laat hij het een paar dagen glippen.

In die paar dagen, voordat hij het kan bijwerken, hackt iemand het systeem. De enige manier om het weer online te krijgen is door het helemaal opnieuw te installeren. Laten we aannemen dat zijn collega’s dat merken. Zelfs als ze er geen last van hebben, stel ik me voor dat Jeff de rest van het semester langzaam zal roosteren op de sintels van de spot van de studenten.

Als het verhaal apocrief is, beschouw het dan als een fabel, een herinnering dat live patchen het kind van de veiligheid is, niet van het gemak. En zoals alle goede fabels is er een happy end.

Het incident inspireert Jeff om te bestuderen hoe je Linux kernel patches zonder vertraging en zonder onderbreking kunt installeren. Hij maakt van dit probleem het onderwerp van zijn masterscriptie uit 2006. De oplossing komt in de vorm van software die Ksplice heet. Met een collega schrijft hij een artikel waarin hij het beschrijft, getiteld ‘Ksplice: Automatic Rebootless Kernel Updates.’

Jeff en drie van zijn student-collega’s vormen een bedrijf, en in mei 2009 winnen ze de MIT $100K prijs voor de Ondernemingswedstrijd. In 2010 lanceren ze een commerciële dienst. Nog een jaar later, in het soort karmische afsluiting waar elke software ontwikkelaar van droomt, koopt Oracle Ksplice Inc.

Karma is ver uit de gedachten van de gebruikers en klanten van dit verbazend nuttige nieuwe hulpprogramma. Voor hen is het het begin van een lange en vermoeiende reeks nachtmerries. Oracle assimileert Ksplice volledig, en maakt het gereedschap alleen gratis voor klanten van hun eigen, met ondersteuningsgeld gefinancierde versies van Linux.

Deze aardschok spoort SUSE en Red Hat aan om hun eigen oplossingen te ontwikkelen, terwijl geen van beiden de ander over hun bedoelingen of oplossingsarchitectuur vertellen. Ze werken geïsoleerd van 2011 tot 2014, en brengen hun eigen verschillende benaderingen binnen enkele weken na elkaar uit. En in mei 2014, CloudLinux, makers van een Linux variant die bekend is in webhosting sferen, brengt een commerciële Linux kernel live patching dienst uit onder de naam KernelCare.

Tegelijk wordt een live patching ABI zijn weg naar de hoofdlijn van de kernel, die het licht ziet in de 4.0 uitgave onder de naam Livepatch. In oktober 2016 gebruiken Canonical, de makers van Ubuntu, het als basis voor een commerciële dienst onder de ongegeneerd toegeëigende naam ‘Canonical Livepatch Service’. Canonical brengt het eerst uit voor 16.04 LTS, daarna voor 14.04 LTS, beide vereisen instelling op de opdrachtregel. In 18.04 LTS is het zichtbaarder geworden, gemakkelijker te gebruiken, en beter geïntegreerd in de Ubuntu desktop ervaring, en nu is het ook beschikbaar voor 20.04 LTS.

Hoe doe je het: Geautomatiseerde kernel beveiligingsupdates op Ubuntu 20.04 LTS

Nu is het tijd om het in actie te zien. Er zijn twee live patching oplossingen voor Ubuntu, die in de volgende twee delen aan bod komen.

Installeren van Canonical Livepatch Service (CLS)

CLS is gratis voor niet-commerciële personen, voor maximaal drie machines. Het vereist registratie, maar je kunt een Ubuntu One account gebruiken als je er een hebt. Als je het op meer dan drie machines wilt installeren, moet je een bedrijfs-achtige ondersteuningsovereenkomst kopen.

Voor je begint

  • Zorg dat je systeem up-to-date is en een back-up heeft.
  • Registreer je voor een Livepatch of Ubuntu One account.
  • Voor 20.04 LTS Server, haal een sleutel en maak er een notitie van. (Dit is niet nodig op de Desktop editie.)

Livepatch installeren op Ubuntu 20.04 LTS Desktop

Ubuntu 20.04 LTS Desktop heeft een GUI instelling om de CLS te activeren. Je kunt het doen tijdens de post-install installatie, of later, door de Software & Updates te openen en naar de Livepatch tab te gaan.

Op een verse Ubuntu installatie

Let na de eerste herstart van een verse installatie op het tweede scherm van het dialoogvenster ‘What’s new in Ubuntu’. Hiermee kun je Livepatch instellen.

  1. Klik op ‘Set Up Livepatch…’
  2. Bij het ‘Ubuntu Single Sign-On Account’ scherm log je in met je Livepatch of Ubuntu One account.
  3. Als je de tekstgebaseerde installatie-GUI gebruikt, selecteer dan onder ‘Featured Server Snaps’, canonical-livepatch.
Op een bestaande Ubuntu installatie
  1. Open ‘Software & Updates’ en ga naar de tab ‘Livepatch’.
  2. Meld je aan.
  3. Klik, nadat je ingelogd bent, op Continue als de popup verschijnt die bevestigt dat je ingelogd bent.
  4. Dat is het. De livepatch is ingesteld op je Ubuntu 20.04 Bureaublad.


Fouten in Ubuntu 20.04 met Livepatch

Je kunt de volgende fout tegenkomen bij het inschakelen van Livepatch op Ubuntu 20.04 FocalFossa:

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

Om de fout te verhelpen typ je de volgende commando’s in de terminal:

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

Livepatch installeren op Ubuntu 20.04 LTS Server

Dit is de commandoregel aanpak voor standaard server versies zonder geïnstalleerd venstersysteem. Het werkt ook op 16.04 LTS, 14.04 LTS en 18.04 LTS versies.

Open een terminal en voer deze twee commando’s in:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>
Tips
  • Het tweede commando geeft een machine token terug. Het dient geen doel en je hoeft het niet op te nemen.
  • Houd bij welke machines je registreert. Als je het overzicht verliest, of een machine of VM weggooit voordat je ze uitschrijft, gooi je effectief een van je drie gratis licenties weg. (Er is hulp hier.)
  • Om een server te deregistreren, gebruik je dit commando:
sudo canonical-livepatch disable <your key>
  • Om de status van de dienst te controleren, gebruik je dit commando:
sudo canonical-livepatch status --verbose

KernelCare installeren

KernelCare gebruikt een command-line opzet; er is geen GUI. Het ondersteunt een breder scala van besturingssystemen, waaronder CentOS, RHEL, Oracle Linux, Debian, Ubuntu en andere. Het ondersteunt ook de oudere 2.6.32 kernellijn.

In tegenstelling tot CLS is het volledig geautomatiseerd en controleert het elke vier uur op patch releases, en installeert ze zonder toezicht als ze beschikbaar zijn. Als je die mogelijkheid wilt opheffen of servers wilt binden aan patches met een vaste datum, is er een commandoregel hulpprogramma (kcarectl) waarmee je dit en andere dingen kunt doen.

KernelCare is gratis voor non-profit organisaties, of er is een gratis, 30 dagen proefversie voor de rest van ons. (Als je een Ksplice gebruiker bent, kun je het twee-staps Ksplice-naar-KernelCare migratie script.)

Voor je begint

  • Zorg dat je systeem bij de tijd is en een back-up heeft.
  • Haal een gratis proefsleutel op bij hier.

KernelCare installeren op Ubuntu 20.04 LTS Desktop en Server

Open een terminal en voer deze twee commando’s in:

sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY

Deze commando’s werken ook op 16.04 LTS, 14.04 LTS en 18.04 LTS versies.

Tips

  • Om een server uit te schrijven, gebruik je dit commando:
sudo kcarectl --unregister
  • Om de status van de dienst te controleren, gebruik je dit commando:
sudo kcarectl --info

Conclusie

Live patchen op Linux was veel te nuttig om lang gratis te blijven.

Met Ubuntu’s 20.04 LTS uitgave is het gemakkelijker om te genieten van de voordelen van live beveiligingspatching van Linux kernels, en het is gratis voor maximaal drie hosts. Daarna worden jaarlijkse, per-server vergoedingen van toepassing.

Als je veel verschillende smaken van Linux draait, maar geen zin hebt om verschillende producten te leren kennen of je te abonneren op verschillende ondersteuningscontracten, kijk dan eens naar KernelCare. Het is ongeveer vijf keer goedkoper bij een jaarabonnement, en ze bieden flexibele maandabonnementen.