Sicurezza su ogni livello: le immagini sigillate estendono l'integrità del sistema operativo dall'avvio al runtime

Considera un dispositivo medico che esegue Linux in un ospedale. Elabora i dati dei pazienti, regola i dosaggi e invia report ai sistemi clinici. Oppure uno sportello automatico all'angolo di una strada, che elabora transazioni 24 ore su 24. O un dispositivo gateway all'edge di una rete manifatturiera, che trasmette i dati dei sensori provenienti dall'area di produzione. Il sistema operativo (OS) di ognuno di questi dispositivi è stato verificato al momento dell'installazione. Ma ogni file binario e ogni libreria corrispondono ancora esattamente a quanto creato in origine? Se pretendi questa garanzia per un dispositivo in una sala operatoria o in un'area di produzione, perché non aspettarti lo stesso dai server che gestiscono la tua azienda?

Il divario nella catena di avvio

In genere, l'installazione di un sistema operativo generico predefinito è "sbloccata", per consentirti di agire come root sul computer e di apportare modifiche persistenti. Quindi, sebbene un'installazione generica di Red Hat Enterprise Linux (RHEL) o Debian supporti il secure boot, solitamente viene firmato solo il kernel. La catena di fiducia crittografica del firmware non copre il file system root o le applicazioni. Tuttavia, se desideri creare delle "appliance", puoi aumentare la sicurezza estendendo la catena dal secure boot all'integrità del sistema operativo tramite firme personalizzate.

Dai flussi di lavoro dei container all'integrità del sistema operativo

La maggior parte delle organizzazioni crea, firma e distribuisce già immagini di container tramite pipeline CI/CD. Ogni operazione di pull del container verifica un digest crittografico. Ogni volta che si avvia un nuovo container, il runtime conferma che l'immagine corrisponde a quella firmata. Le organizzazioni si affidano già a questo modello per le proprie applicazioni.

La modalità immagine per RHEL estende lo stesso flusso di lavoro dei container al sistema operativo stesso. Invece di installare e configurare un sistema operativo manualmente o tramite script, lo definisci in un Containerfile (o in un altro sistema di compilazione OCI compatibile), lo crei come immagine container e lo distribuisci con bootc. Il sistema operativo diventa un artefatto riproducibile e dotato di versione, che segue la stessa pipeline delle applicazioni. Gli aggiornamenti sono atomici. Il rollback è integrato. Ogni sistema distribuito esegue l'immagine che hai creato; puoi risalire da tale immagine fino al sistema di compilazione che l'ha generata.

Grazie alla modalità immagine, le immagini sigillate compiono un ulteriore passo in avanti. Ora il sistema verifica crittograficamente l'immagine del sistema operativo che hai creato e firmato, dal firmware fino al runtime. Invece di adottare un nuovo processo, puoi estenderne uno di cui ti fidi già, dalle applicazioni al livello del sistema operativo.

Come funziona

Secure Boot e un'immagine del kernel unificata (UKl) firmata verificano la catena di avvio: bootloader, kernel, initramfs. Le immagini sigillate estendono la verifica alla stessa immagine immutabile del sistema operativo, con precisione a livello di file. Utilizzando composefs e fs-verity, il sistema incorpora un resoconto crittografico dell'immagine container del sistema operativo direttamente nell'UKI firmato in fase di compilazione. In fase di esecuzione, il sistema verifica individualmente ogni file aggiunto all'immagine da te o dal tuo team rispetto a tale resoconto. Il sistema rifiuta di caricare qualsiasi file del sistema operativo non corrispondente. Se un elemento viene modificato, danneggiato o sostituito dopo la creazione dell'immagine, il kernel restituisce un errore di I/O. Il file non viene reso disponibile. Nessuna registrazione e distribuzione, nessuna segnalazione e distribuzione. Risulta semplicemente illeggibile. Il contenuto manomesso scompare e, di conseguenza, il kernel non lo distribuisce ad alcun processo.

Cosa significa per la tua infrastruttura

La catena di firma è sotto il tuo controllo. Generi le chiavi, firmi le immagini e decidi di cosa devono fidarsi i tuoi sistemi. La catena di custodia non richiede il coinvolgimento di alcun fornitore.

Le organizzazioni che operano in settori che richiedono livelli di sicurezza elevati, come la pubblica amministrazione, la finanza e la sanità, da anni esigono questo livello di integrità del sistema operativo. Le immagini sigillate lo garantiscono e sono disponibili per qualsiasi organizzazione ne faccia richiesta. Non occorre operare in un settore regolamentato per trarre vantaggio dalla certezza che il sistema operativo corrisponda esattamente a quello creato.

È opportuno essere precisi su ciò che le immagini sigillate includono. Il sigillo protegge i file nell'immagine immutabile del sistema operativo: il sistema operativo di base e tutto il software installato, gli agenti di monitoraggio, gli strumenti di sicurezza, i file binari delle applicazioni e i pacchetti specifici aggiunti dal team all'immagine di base. Tutto questo è sigillato. Non include la configurazione scrivibile in /etc o lo stato di runtime in /var. Si tratta di una distinzione deliberata. Il sigillo protegge il sistema operativo che hai creato. Gli strumenti di gestione della configurazione e di sicurezza del runtime contribuiscono a proteggere il resto.

All'inizio di questo articolo ho menzionato un dispositivo medico e un bancomat, ma questo concetto va ben oltre questi esempi. Immagina un datacenter, un insieme di dispositivi edge o un reparto di produzione. Un solo Containerfile definisce il sistema operativo. Una singola pipeline crea, firma e sigilla l'immagine. Puoi distribuire la stessa immagine sigillata su bare metal, VM e istanze cloud. La stessa integrità la accompagna ovunque. Non si tratta di una funzionalità di nicchia per uno scenario di utilizzo ristretto. L'integrità del sistema operativo deve essere così.

Per iniziare

Le immagini sigillate sono disponibili come anteprima tecnica in RHEL 10.2. Si basa su tecnologie Linux upstream, inclusi componenti significativi del progetto systemd, strumenti esistenti per il secure boot e composefs, e offre un modo flessibile ed efficiente per ottenere un'integrità come quella fornita da dm-verity, ma con la flessibilità di un approccio basato su file system. La gestione del sistema operativo si muove in questa direzione. L'anteprima tecnica è aperta, gli strumenti sono già operativi e nelle prossime settimane pubblicheremo una serie di guide dettagliate sul Red Hat Developer Blog, per aiutarti a capire, nella pratica, come creare e verificare i sistemi.