Ma è così probabile che un pasticcio come quello di CrowdStrike succeda anche sui sistemi Linux? Spoiler: no, ed anzi, è già successo!

Ora che la tempesta CrowdStrike pare essersi calmata (e risolta, basta riavviare fino a quindici volte) è bene cominciare ad interrogarsi con lucidità su quanto accaduto. OK, il problema ha riguardato solamente le macchine (reali o virtuali che fossero) Microsoft Windows, ma siamo sicuri che un disastro del genere non possa accadere anche con Linux?

I meme su Microsoft Windows sono stati bellissimi e ci siamo divertiti tutti, ma proviamo a scendere nel dettaglio.

In questo articolo ho provato a raggruppare alcune delle ragioni per cui non penso sarà mai possibile che una problematica di tale entità possa accadere sui sistemi Linux e no, non dipende dal fatto che Linux sia meno diffuso di Microsoft Windows. Non oggi, non nel 2024, non quando The New Stack scrive che Linux è il sistema operativo più utilizzato su Azure Cloud, tanto per dirne una.

La premessa a tutto questo ragionamento poi è doverosa: non si sta scrivendo che Linux sia immune da queste problematiche, tanto che la questione CrowdStrike (proprio lei) effettivamente aveva già colpito i sistemi Debian e Rocky Linux mesi fa. Leggete questo articolo di Neonwin per capire come il modello di sviluppo usato da CrowdStrike fosse già stato criticato dagli sviluppatori Debian e di come in realtà avesse avuto una rilevanza molto bassa.

Perché? Perché è successo in Linux, ed in Linux le cose sono diverse.

Quindi da dove nasce la certezza che Linux sia immune da apocalissi tipo CrowdStrike?

Fermo restando come non sia una certezza, poiché ovviamente le affermazioni assolute sono fatte per essere smentite, ecco quattro ragioni per cui la questione è, a mio giudizio, altamente improbabile.

Gli unattended upgrades

Il motivo principale del BSOD è stata l’installazione dell’aggiornamento del software Falcon Sensor di CrowdStrike, specificamente di un file .sys che ha bloccato l’avvio dei sistemi a causa di un errore.

L’approccio unattended upgrades (ossia gli aggiornamenti senza supervisione) può avere una valenza in contesti di sicurezza (ad esempio nell’ambito della recente problematica regreSSHion), ma in Linux questa prassi è poco seguita, a meno di non trattare le installazioni come istanze effimere, dove quindi il problema nemmeno si pone poiché l’aggiornamento è sostanzialmente l’avvio di un intero nuovo sistema.

Perché è quello che l’approccio cloud-native dovrebbe prevedere, giusto? In realtà no, ma rimane il fatto di come non sia pratica diffusa avere unattended upgrades abilitati di default sui sistemi Linux.

I reboot impliciti agli aggiornamenti

Per quanto sia globalmente accettato che un aggiornamento in autonomia riavvii il sistema non è, o almeno non dovrebbe essere la prassi. Di sicuro in ambito Linux questa non è indicata come best-practice.

In Linux solo il Kernel, e a volte nemmeno quello (più o meno dal 2015), impone il reboot del sistema e non è chiaramente mai una buona norma automatizzare un reboot.

Anche per questo aspetto l’approccio cloud-native dovrebbe tagliare la testa al toro, ma in ogni caso non mi risulta esistano distribuzioni desktop o server che siano che di default prevedano reboot automatici dopo gli aggiornamenti.

La frammentazione delle distribuzioni

Le distribuzioni Linux, anche solo considerando quelle di classe enterprise usate nei server e non quelle dei client, sono molte e variegate. I cicli di release delle stesse sono diversi e, per quanto ci sia il dominio di Linux sul cloud non è mai UN SOLO Linux di cui si sta parlando.

Un esempio pratico, dopo la problematica SSH che ha colpito tutte le distribuzioni (che ricordiamolo era un problema di sicurezza, non bloccante) ne è seguita un’altra, la CVE-2024-6409, di portata molto minore che è stata gestita in maniera estemporanea dalle varie distribuzioni e che nello specifico riguardava Fedora 36/37 e RHEL 9, ma non ad esempio Ubuntu.

Tanto per sottolineare poi le diverse modalità di gestione di questo tipo di problemi, AlmaLinux ha creato la patch addirittura prima di Red Hat.

Le community open-source

C’è poi l’aspetto open-source da tenere presente nella valutazione: Linux non è un’azienda. Sebbene la community che sviluppa il Kernel Linux funziona come tale rimane il fatto che il codice è pubblico. I contributi lo sono allo stesso tempo e, come recita la Linus law “given enough eyeballs, all bugs are shallow“.

Le distribuzioni certo, a volte sono aziende, ma il software che usano rimane open-source e pertanto il suo aggiornamento non dipende quasi mai da una singola entità, quanto piuttosto da una community, fermo restando l’antico adagio di Xkcd:

E qui finisce questa veloce disamina. È quindi impossibile che si verifichi un CrowdStrike anche in Linux? È quindi impossibile che otto milioni e mezzo di sistemi possano essere colpiti contemporaneamente da un problema come quello del Falcon Sesor?

Assolutamente no, perché impossibile in informatica non si dice, ma certamente improbabile.