Che fine ha fatto la promessa di applicare patch live ai kernel Linux? Questo articolo esamina la sua storia, i suoi problemi e i modi più economici e semplici per farlo su Ubuntu Focal Fossa (20.04 LTS).
Introduzione
'Live patching' è l'atto di aggiornare un programma senza arrestare il sistema su cui è in esecuzione. È stato fatto prima con saldatura e filo, poi con forbici e colla:non è una novità. Oggi, applicare patch in tempo reale ai kernel Linux è molto meno complicato.
In questo articolo spiegherò di cosa si tratta, come funziona (in termini non tecnici) e da dove viene. Concluderò mostrando come automatizzare gli aggiornamenti di sicurezza del kernel su Ubuntu 20.04 LTS (Focal Fossa) con Canonical Livepatch Service e KernelCare.
Cos'è Live Patching?
Nel software, una patch è un piccolo pezzo di codice di rettifica. L'applicazione di patch è la riparazione o il miglioramento di una piccola parte di un programma senza interrompere il funzionamento o le specifiche dell'intero. Applicare patch in tempo reale (o hot) significa modificare un programma in esecuzione senza interromperlo.
Immagina di essere intrappolato in un'auto in movimento e di dover riparare una lampadina. Non male, si potrebbe dire, se è all'interno, un po' più complicato all'esterno. Ora immagina di riparare un albero a camme, sostituire un'asta del pistone o sigillare un blocco rotto.
Questo è simile a ciò che il live patch sta cercando di fare sul kernel Linux. Sta cercando di riparare le parti di qualcosa in movimento, senza cambiarlo o romperlo, ma soprattutto, senza fermarlo. Il kernel è l'unica parte di un sistema Linux che necessita di uno spegnimento e riavvio per applicare un aggiornamento. Quando un fornitore rilascia un aggiornamento del kernel, gli amministratori di sistema non hanno altra scelta che pianificare il riavvio di un server.
Cosa c'è di male nel riavvio?
Un riavvio significa cose diverse per persone diverse, a seconda che si trovino sul sistema o ne siano responsabili. Molti amministratori di sistema considerano i riavvii regolari un segno di buona salute, come l'intestino regolare. Proprio come molti non lo fanno, resistendo a qualsiasi interruzione delle applicazioni in cui hanno investito e facendo soldi, applicazioni come queste, ad esempio.
- server web, con utenti attivi e occupati in molti fusi orari
- giochi multiplayer online
- streaming video in diretta o registrato pay-per-view
- mining di criptovalute
- servizi di videosorveglianza e registrazione remoti 24 ore su 24, 7 giorni su 7
Per me, il motivo più riconoscibile è la paura che il sistema non sarà più lo stesso in seguito e che le applicazioni critiche (per fare soldi) non si avviino. Penso che sia questo, e non le visioni di utenti furiosi, che fa sì che molti amministratori di sistema rinviino gli aggiornamenti del kernel, anche il tipo più importante, gli aggiornamenti di sicurezza.
(Qui parlo solo di aggiornamenti . Aggiornamenti del kernel sono qualcos'altro. Gli aggiornamenti sono kernel completamente nuovi. Le patch sono aggiornamenti di parti del kernel, di solito correzioni di bug che non possono aspettare perché hanno implicazioni di sicurezza o di altro tipo.)
Quando un fornitore Linux rilascia una patch del kernel, di solito è per risolvere un problema di sicurezza. La nota di avviso associata dirà qualcosa del tipo "Installa al più presto". Nella stessa pagina sarà presente una versione di "Se non lo fai, sarai vulnerabile agli exploit che abbiamo corretto e che tutti ora conoscono di. Buona giornata.'
Tali note scritte in modo insensibile evidenziano il dilemma che guida l'avvento del patching live:dovresti mantenere gli utenti "dolori ma al sicuro" o "composti ma esposti"? Il live patching promette di essere l'isola paradisiaca tra Rock e Hard Place. L'applicazione di patch in tempo reale promette di mantenere i tuoi server al sicuro e ai livelli di sicurezza più recenti, senza influire sui tempi di inattività e senza influire sui servizi.
Isola Paradiso? Qual è il trucco?
Sebbene il codice sorgente per il software di patching live sia disponibile gratuitamente, le patch non lo sono. La dolce promessa di patch dal vivo si inasprisce quando devi scrivere le tue patch. La pressione sanguigna diminuisce con una minore amministrazione, ma aumenta di nuovo gestendo il codice kernel complesso.
Sebbene sia tecnicamente possibile creare le proprie patch, richiede molto lavoro e molte conoscenze specialistiche. Ed è rischioso:una patch scritta male può mandare in crash un sistema. (Questo messaggio sulla pagina github di kpatch si legge come qualcosa dal manuale dell'operatore di un martello a vapore:"AVVERTENZA:utilizzare con cautela! Il kernel si arresta in modo anomalo, si possono verificare riavvii spontanei e perdita di dati!")
I fornitori di Linux sanno quanto sia difficile eseguire correttamente le patch live e hanno sviluppato offerte di servizi redditizi per trarre vantaggio da questo fatto. Ogni distribuzione Linux principale ha un approccio di patch live che è gratuito da installare, ma non da usare. Le patch, senza le quali l'intera idea è inutile, devono essere pagate.
Tuttavia, i vantaggi delle patch del kernel live sono così convincenti che questi modelli di business prosperano nell'ecosistema di software prevalentemente gratuito e open source di Linux. Per me, questo è un segno che la tecnologia ha un significato e un ruolo importante nel futuro dei sistemi basati su Linux.
Come funziona l'applicazione di patch in tempo reale
Ancora intrappolato in quell'auto immaginaria, che ora sfreccia in discesa verso un mucchio immaginario di scatole di cartone (si spera) vuote, come sistemereste i freni? Costruire un martinetto temporaneo su cui fare il lavoro? Appoggiarsi su tre ruote, aspettare che una si fermi, toglierla, ripetere fino al termine?
I programmatori del kernel Linux devono aver usato lo stesso tipo di pensiero nell'affrontare il problema delle patch live. Percepisco lo stesso tipo di apparato concettuale (sospensione, scambio, uso di strutture portanti temporanee) all'opera nelle loro soluzioni. La mia cruda analogia con il cambio di freno sopra illustra due strategie opposte implementate dai fornitori di software di patching live.
- Interrompi tutto ed esegui tutte le correzioni in una volta sola.
- Attendere che i singoli componenti si fermino, quindi sostituirli. Ripetere fino al termine.
Questa divisione spiega perché ogni fornitore ha escogitato approcci diversi per risolvere lo stesso problema. Ciò che condividono, tuttavia, è l'uso del framework del modulo del kernel caricabile di Linux. Il software che orchestra e implementa il processo di patch è un modulo del kernel Linux. Ciò significa che è facile aggiungere funzionalità di patch ai kernel compatibili e altrettanto facile rimuoverlo.
Prima di lasciarci trasportare, devo menzionare gli avvertimenti.
Esiste un limite all'ambito e alla scala delle patch software che è possibile applicare ai sistemi in esecuzione. Per prima cosa, i kernel personalizzati, ottimizzati o non standard rendono difficile o impossibile applicare una patch live a un kernel. Per un altro, il patching live non può rimappare i dati o la memoria tra le patch; può solo alterare le definizioni delle funzioni.
Queste carenze non hanno impedito a Ksplice di diventare il primo nel campo delle patch live di Linux. Funziona confrontando il vecchio e il nuovo codice sorgente da cui crea una patch binaria. Blocca il sistema, determina quali funzioni devono essere modificate e ne modifica le intestazioni. Quando vengono chiamate, le funzioni vengono trasferite alle nuove versioni. Se la patch è ben scritta, il controllo procede come se nulla fosse accaduto.
Un evento sismico (descritto nella prossima sezione) ha visto Kpatch di Red Hat e Kgraft di SUSE entrare in scena con le loro interpretazioni sui problemi principali del patching live.
Kpatch confronta il vecchio e il nuovo codice sorgente per creare patch. Come Ksplice, funziona reindirizzando le chiamate di funzione utilizzando il framework ftrace del kernel per cambiare le funzioni modificate in una volta sola.
Kggraft funziona in modo diverso. Utilizza due insiemi simultanei di funzioni, vecchio e nuovo, con un modulo di orchestrazione che decide quando reindirizzare le funzioni a seconda di dove è stata raggiunta l'esecuzione. È impossibile prevedere dove in una funzione si trova un puntatore di programma in qualsiasi momento, quindi la transizione è graduale, non istantanea.
Le origini del patching live
In che modo l'idea di riparare il software senza che nessuno se ne accorgesse è entrata in quel monolito in continua evoluzione dello sforzo umano, il kernel Linux?
Sebbene il concetto risalga ai primi giorni del calcolo programmabile, per i nostri scopi il percorso inizia nel 2001, quando Hewlett Packard brevetta un modo per aggiornare dinamicamente il software per compensare la funzionalità hardware mancante. Un anno dopo, Microsoft presenta un'idea per aggiornare un sistema (Windows) senza interruzioni.
Nessuno dei due menziona Linux, ma le applicazioni sono ampie, ognuna delle quali descrive come porre rimedio a problemi software o hardware su un computer senza interrompere i processi in esecuzione su di esso. (Se l'idea non ti sembra particolarmente utile, forse due parole ti faranno ricredere:Meltdown e Spectre.)
Nel 2008, Jeff Arnold annuncia Ksplice, un software per patchare i kernel Linux senza riavviarli. È il primo del suo genere per Linux. E dobbiamo ringraziare un hacker sconosciuto e senza nome per questo.
Per capire perché, lascia che ti riporti ai giorni da studente del MIT di Jeff. È un membro di un gruppo di volontari che gestisce i server per la comunità studentesca. Uno dei server necessita di una patch di sicurezza. Non vuole espellere i suoi utenti, quindi lascia perdere per alcuni giorni.
In quei pochi giorni, prima che possa aggiornarlo, qualcuno hackera il sistema. L'unico modo per riportarlo online è reinstallarlo completamente da zero. Supponiamo che i suoi colleghi se ne accorgano. Anche supponendo che non soffrano, immagino che Jeff trascorra il resto del semestre ad arrostire lentamente sulle ceneri della derisione degli studenti.
Se la storia è apocrifa, allora considerala una favola, un promemoria che il live patching è figlio della sicurezza, non della convenienza. E come tutte le belle favole, c'è un lieto fine.
L'incidente ispira Jeff a studiare come installare le patch del kernel Linux senza ritardi e senza interruzioni. Fa di questo problema l'argomento della sua tesi di laurea magistrale del 2006. La soluzione si presenta sotto forma di software chiamato Ksplice. Con un collega, scrive un articolo che lo descrive, intitolato "Ksplice:Aggiornamenti automatici del kernel senza riavvio".
Jeff e tre dei suoi colleghi studenti formano un'azienda e nel maggio 2009 vincono il premio MIT $ 100K Entrepreneurship Competition. Lanciano un servizio commerciale nel 2010. Un altro anno dopo, nel tipo di chiusura karmica che ogni sviluppatore di software sogna, Oracle acquista Ksplice Inc.
Karma è lontano dalle menti degli utenti e dei clienti di questa nuova utility straordinariamente utile. Per loro, è l'inizio di una lunga ed estenuante serie di incubi. Oracle assimila completamente Ksplice, rendendo lo strumento gratuito solo per i clienti delle proprie versioni di Linux finanziate con costi di supporto.
Questa scossa sismica spinge SUSE e Red Hat a sviluppare le proprie soluzioni, senza rivelare all'altro le proprie intenzioni o architetture di soluzioni. Lavorano in isolamento dal 2011 al 2014, rilasciando i propri approcci distinti a poche settimane l'uno dall'altro. E nel maggio 2014, CloudLinux, produttore di una variante Linux ben nota nell'ambito dell'hosting web, rilascia un servizio commerciale di patch live del kernel Linux sotto il nome di KernelCare.
Allo stesso tempo, un ABI di patch live si sta facendo strada nella linea principale del kernel, vedendo la luce nella versione 4.0 sotto il nome di Livepatch. Nell'ottobre 2016, Canonical, i creatori di Ubuntu, lo usano come base per un servizio commerciale sotto il nome spudoratamente appropriato di "Canonical Livepatch Service". Canonical lo rilascia prima per 16.04 LTS, quindi 14.04 LTS, entrambi richiedono l'installazione sulla riga di comando. In 18.04 LTS, è diventato più visibile, più facile da usare e meglio integrato nell'esperienza desktop di Ubuntu e ora è disponibile per 20.04 LTS.
Come fare:aggiornamenti automatici della sicurezza del kernel su Ubuntu 20.04 LTS
Ora è il momento di vederlo in azione. Esistono due soluzioni di patch live per Ubuntu, trattate nelle prossime due sezioni.
Installazione del servizio Canonical Livepatch (CLS)
CLS è gratuito per le persone non commerciali, per un massimo di tre macchine. Richiede la registrazione, ma puoi utilizzare un account Ubuntu One se ne hai uno. Se desideri installarlo su più di tre computer, dovrai acquistare un contratto di servizio di supporto in stile aziendale.
Prima di iniziare
- Assicurati che il tuo sistema sia aggiornato e sottoposto a backup.
- Registrati per un account Livepatch o Ubuntu One.
- Per 20.04 LTS Server, prendi una chiave e prendine nota. (Questo non è necessario nell'edizione Desktop.)
Installazione di Livepatch su Ubuntu 20.04 LTS Desktop
Ubuntu 20.04 LTS Desktop ha un'impostazione GUI per attivare il CLS. Puoi farlo durante la configurazione post-installazione o in un secondo momento aprendo Software e aggiornamenti e andando alla scheda Livepatch.
Su una nuova installazione di Ubuntu
Dopo il primo riavvio di una nuova installazione, fai attenzione alla seconda schermata della finestra di dialogo "Novità in Ubuntu". Ciò ti consente di impostare Livepatch.
- Fai clic su "Imposta patch live..."
- Nella schermata "Account Ubuntu Single Sign-On", accedi con il tuo account Livepatch o Ubuntu One.
- Se stai utilizzando la GUI di installazione basata su testo, in "Snap del server in primo piano", seleziona canonical-livepatch.
Su un'installazione Ubuntu esistente
- Apri "Software e aggiornamenti" e vai alla scheda "Livepatch".
- Accedi.
- Dopo aver effettuato l'accesso, fai clic su Continua quando viene visualizzato il popup a conferma dell'accesso.
- Ecco fatto. La livepatch è impostata sul desktop Ubuntu 20.04.
Errori in Ubuntu 20.04 con Livepatch
Potresti riscontrare il seguente errore durante l'abilitazione di Livepatch su Ubuntu 20.04 Focal Fossa:
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
Per correggere l'errore, digita i seguenti comandi nel terminale:
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
Installazione di Livepatch su Ubuntu 20.04 LTS Server
Questo è l'approccio della riga di comando per le versioni server standard senza un sistema a finestre installato. Funziona anche con le versioni 16.04 LTS, 14.04 LTS e 18.04 LTS.
Apri un terminale e inserisci questi due comandi:
sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>
Suggerimenti
- Il secondo comando restituisce un token macchina. Non serve a nulla e non è necessario registrarlo.
- Tieni traccia delle macchine che stai registrando. Se perdi le tracce o elimini una macchina o una VM prima di annullare la registrazione, stai effettivamente buttando via una delle tue tre licenze gratuite. (C'è aiuto qui.)
- Per annullare la registrazione di un server, utilizzare questo comando:
sudo canonical-livepatch disable <your key>
- Per controllare lo stato del servizio, usa questo comando:
sudo canonical-livepatch status --verbose
Installazione di KernelCare
KernelCare utilizza una configurazione da riga di comando; non c'è una GUI. Supporta una gamma più ampia di sistemi operativi, inclusi CentOS, RHEL, Oracle Linux, Debian, Ubuntu e altri. Supporta anche la vecchia linea del kernel 2.6.32.
A differenza di CLS, è completamente automatizzato e controllerà le versioni delle patch ogni quattro ore, installandole senza supervisione se disponibili. Se è necessario ignorare tale capacità o collegare i server a patch a data fissa, è disponibile un'utilità della riga di comando (kcarectl) che consente di fare questo e altre cose.
KernelCare è gratuito per le organizzazioni senza scopo di lucro oppure è disponibile una prova gratuita di 30 giorni per il resto di noi. (Se sei un utente di Ksplice, potresti provare lo script di migrazione da Ksplice a KernelCare in due passaggi.)
Prima di iniziare
- Assicurati che il tuo sistema sia aggiornato e sottoposto a backup.
- Ricevi una chiave di prova gratuita da qui.
Installazione di KernelCare su Ubuntu 20.04 LTS Desktop e Server
Apri un terminale e inserisci questi due comandi:
sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY
Questi comandi funzionano anche sulle versioni 16.04 LTS, 14.04 LTS e 18.04 LTS.
Suggerimenti
- Per annullare la registrazione di un server, utilizzare questo comando:
sudo kcarectl --unregister
- Per controllare lo stato del servizio, usa questo comando:
sudo kcarectl --info
Conclusione
Le patch live su Linux erano troppo utili per rimanere libere a lungo.
Con la versione 20.04 LTS di Ubuntu, è più facile godere dei vantaggi delle patch di sicurezza live dei kernel Linux ed è gratuito per un massimo di tre host. Successivamente, si applicano le tariffe annuali per server.
Se utilizzi molte versioni di Linux, ma non vuoi imparare prodotti diversi o abbonarti a contratti di supporto diversi, dai un'occhiata a KernelCare. È circa cinque volte più economico se si abbona annualmente e offrono abbonamenti mensili flessibili.