Lennart Poettering ha pubblicato una proposta per modernizzare il processo di avvio per le distribuzioni Linux, volta a risolvere i problemi esistenti e semplificare l'organizzazione di un avvio completamente verificato che confermi l'affidabilità del kernel e dell'ambiente di sistema sottostante. Le modifiche necessarie per implementare la nuova architettura sono già incluse nella codebase di systemd e interessano componenti come systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase e systemd-creds.
Le modifiche proposte si riducono alla creazione di un'unica immagine universale UKI (Unified Kernel Image), che combina l'immagine del kernel Linux, un gestore per il caricamento del kernel da UEFI (UEFI boot stub) e l'ambiente di sistema initrd caricato in memoria, utilizzato per inizializzazione iniziale nella fase precedente al montaggio del root FS. Invece di un'immagine del disco RAM initrd, l'intero sistema può essere impacchettato in UKI, che consente di creare ambienti di sistema completamente verificati caricati nella RAM. L'immagine UKI è formattata come file eseguibile in formato PE, che può essere caricato non solo utilizzando i bootloader tradizionali, ma può essere richiamato direttamente dal firmware UEFI.
La possibilità di chiamare da UEFI consente di utilizzare un controllo di integrità della firma digitale che copre non solo il kernel, ma anche il contenuto di initrd. Allo stesso tempo, il supporto per le chiamate dai bootloader tradizionali consente di mantenere funzionalità come la consegna di diverse versioni del kernel e il rollback automatico su un kernel funzionante se vengono rilevati problemi con il nuovo kernel dopo l'installazione dell'aggiornamento.
Attualmente, nella maggior parte delle distribuzioni Linux, il processo di inizializzazione utilizza la catena "firmware → livello shim Microsoft con firma digitale → boot loader GRUB firmato digitalmente dalla distribuzione → kernel Linux con firma digitale → ambiente initrd non firmato → root FS." La mancanza di verifica initrd nelle distribuzioni tradizionali crea problemi di sicurezza, poiché, tra le altre cose, in questo ambiente vengono recuperate le chiavi per decrittografare il file system root.
La verifica dell'immagine initrd non è supportata poiché questo file viene generato sul sistema locale dell'utente e non può essere certificato con una firma digitale del kit di distribuzione, il che complica notevolmente l'organizzazione della verifica quando si utilizza la modalità SecureBoot (per verificare l'initrd, il l'utente deve generare le proprie chiavi e caricarle nel firmware UEFI). Inoltre, l'attuale organizzazione di boot non consente l'uso delle informazioni dei registri TPM PCR (Platform Configuration Register) per controllare l'integrità dei componenti dello spazio utente diversi da shim, grub e kernel. Tra i problemi esistenti vengono citati anche la complessità dell'aggiornamento del bootloader e l'impossibilità di limitare l'accesso alle chiavi nel TPM per le versioni precedenti del sistema operativo diventate irrilevanti dopo l'installazione dell'aggiornamento.
Gli obiettivi principali dell'introduzione della nuova architettura di caricamento sono:
- Fornisce un processo di avvio completamente verificato che si estende dal firmware allo spazio utente, confermando la validità e l'integrità dei componenti avviati.
- Collegamento delle risorse controllate ai registri PCR TPM, separati per proprietario.
- Possibilità di precalcolare i valori PCR in base al kernel, initrd, configurazione e ID di sistema locale utilizzato durante l'avvio.
- Protezione contro gli attacchi di rollback associati al ripristino di una precedente versione vulnerabile del sistema.
- Semplificare e aumentare l'affidabilità degli aggiornamenti.
- Supporto per aggiornamenti del sistema operativo che non richiedono la riapplicazione o il provisioning locale di risorse protette da TPM.
- Il sistema è pronto per la certificazione remota per confermare la correttezza del sistema operativo e delle impostazioni caricati.
- La possibilità di allegare dati sensibili a determinate fasi di avvio, ad esempio estraendo le chiavi di crittografia per il file system root dal TPM.
- Fornire un processo sicuro, automatico e senza utenti per sbloccare le chiavi per decrittografare un'unità della partizione root.
- Utilizzo di chip che supportano la specifica TPM 2.0, con la possibilità di eseguire il rollback su sistemi senza TPM.
Fonte: opennet.ru