Il mondo Linux è cambiato per sempre. La sua tecnologia non è più «qualcosa di strano» nelle conversazioni informatiche, e oggi è presente in milioni di smartphone, tablet, modem, router, dispositivi indossabili e veicoli, senza dimenticare il suo dominio nello spazio dei server. Con la cosiddetta Internet delle Cose che bussa alla porta, la sicurezza del kernel Linux non può continuare con il suo modello attuale, e molte voci raccomandano l'implementazione di una nuova strategia che permetta al kernel di «proteggersi da solo», restando un passo avanti rispetto alle vulnerabilità.
A due metri dalla mia scrivania, uno smartphone con Android 2.3 raccoglie polvere, oggi usato come torcia. Anche se tutto ciò che mi serve per farlo tornare al suo ruolo originale di smartphone è inserire una SIM, la versione del sistema operativo è così antiquata che non so se valga la pena correre il rischio. Nella stessa situazione si trovano milioni di dispositivi con un kernel Linux in background. Sono robusti, flessibili e stabili, ma non ricevendo aggiornamenti, diventano insicuri. Sviluppatori, produttori, distributori, fornitori di connettività e utenti, tutti hanno una parte di colpa sulle spalle, e se aggiungiamo il potenziale dell'Internet delle Cose, siamo costretti a parlare di milioni di dispositivi aggiuntivi completamente a rischio. Ci si aspetta che alcuni di questi gadget funzionino per cinque o dieci anni senza ricevere un solo update, e con questa meccanica, il kernel Linux rimane intrappolato tra l'incudine e il martello.
In altre parole, il kernel Linux non può continuare a inseguire i bug. Secondo Kees Cook, sviluppatore Google e responsabile del Linux Kernel Self-Protection Project, il «tempo di vita» di un bug nel kernel (cioè dalla sua introduzione alla patch) varia tra 3,3 e 6,4 anni. Queste lacune sono diventate un parametro inaccettabile, e gli attaccanti osservano attentamente ogni nuovo «commit» per individuare e sfruttare i bug. Questo delinea la protezione avanzata del kernel come una missione fondamentale, ma c'è un altro problema: l'85 per cento dei bug nel kernel non nasce dal suo nucleo, ma dai driver integrati. La bassa qualità del controllo di alcuni produttori è preoccupante e contribuisce all'incertezza di sicurezza che attraversa il kernel.
Ora... le sfide non sono solo tecniche, ma anche politiche. L'occhio allenato noterà che questo «conflitto» ha molto in comune con il dibattito «kernel monolitico vs. microkernel» che ha agitato gli appassionati di Linux più di una volta, e che continua a essere fonte di notevoli scambi. Tuttavia, come ho detto all'inizio, il mondo Linux è cambiato per sempre. Nuovi problemi di sicurezza richiedono nuove soluzioni, e una sorta di «immunità generale nel kernel» non suona male. Rimuovere i driver dal kernel e spostare il loro funzionamento verso lo «userland» è ben lontano dall'essere una soluzione magica, ma è proprio questo il punto: non servono soluzioni magiche, ma soluzioni robuste che proteggano il kernel a lungo termine. Il discorso di Kees Cook dura poco più di 45 minuti e lì dettaglia alcuni dei progressi fatti dal Self-Protection Project, oltre a suggerimenti aggiuntivi per il futuro. Se questo argomento ti interessa, vale la pena guardarlo.
