Lennart Poettering ha pubblicato una proposta per modernizzare il processo di avvio. Linux-distribuzioni, volte a risolvere i problemi esistenti e a semplificare l'organizzazione di un processo di avvio completamente verificato che confermi la validità del kernel e dell'ambiente di sistema sottostante. Le modifiche necessarie per implementare la nuova architettura sono già state incorporate nel codice sorgente 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 LinuxUn gestore per il caricamento del kernel da UEFI (stub di avvio UEFI) e un ambiente di sistema initrd caricato in memoria, utilizzato per l'inizializzazione prima del montaggio del filesystem root. Invece di un'immagine disco RAM initrd, l'intero sistema può essere impacchettato in un UKI, consentendo la creazione di ambienti di sistema completamente verificati caricati in RAM. L'immagine UKI è impacchettata come file eseguibile in formato PE, che può essere caricato non solo dai bootloader tradizionali ma anche direttamente dal firmware UEFI.
La possibilità di invocare da UEFI consente la verifica dell'integrità e della validità della firma digitale, coprendo non solo il kernel ma anche il contenuto dell'initrd. Il supporto per l'invocazione da bootloader tradizionali preserva inoltre funzionalità come il provisioning di più versioni del kernel e il rollback automatico a un kernel funzionante se vengono rilevati problemi con il nuovo kernel dopo l'installazione di un aggiornamento.
Attualmente, la maggior parte delle distribuzioni Linux Il processo di inizializzazione utilizza la seguente catena: firmware → strato shim certificato con firma digitale Microsoft → bootloader GRUB certificato con firma digitale della distribuzione → kernel certificato con firma digitale della distribuzione Linux → ambiente initrd non verificato → file system root." La mancanza di verifica dell'initrd nelle distribuzioni tradizionali crea problemi di sicurezza, poiché, tra le altre cose, questo ambiente viene utilizzato per estrarre le chiavi per decrittografare il file system root.
La verifica dell'immagine initrd non è supportata perché questo file viene generato sul sistema locale dell'utente e non può essere firmato digitalmente dalla distribuzione. Ciò complica notevolmente la verifica quando si utilizza la modalità SecureBoot (per verificare l'initrd, l'utente deve generare le proprie chiavi e caricarle nel firmware UEFI). Inoltre, l'attuale organizzazione di avvio non consente l'utilizzo delle informazioni del TPM PCR (Platform Configuration Register) per monitorare l'integrità dei componenti dello spazio utente diversi da shim, grub e kernel. Altri problemi citati includono la difficoltà di aggiornare il bootloader e l'impossibilità di limitare l'accesso alle chiavi TPM per le versioni precedenti del sistema operativo che sono diventate obsolete dopo l'installazione dell'aggiornamento.
Gli obiettivi principali dell'implementazione della nuova architettura di avvio sono:
- Fornire un processo di avvio completamente verificato, che copra tutte le fasi dal firmware allo spazio utente e confermi la validità e l'integrità dei componenti avviati.
- Associazione delle risorse controllate ai registri PCR TPM con divisione per proprietari.
- Possibilità di precalcolare i valori PCR in base al kernel, all'initrd, alla configurazione e all'identificatore del sistema locale utilizzati durante l'avvio.
- Protezione contro gli attacchi di rollback, che comportano il ripristino di una versione precedente vulnerabile del sistema.
- Semplificare e migliorare l'affidabilità degli aggiornamenti.
- Supporto per gli aggiornamenti del sistema operativo che non richiedono la riapplicazione o il provisioning locale delle risorse protette da TPM.
- Il sistema è pronto per la certificazione remota per confermare la correttezza del sistema operativo avviabile e delle impostazioni.
- Possibilità di allegare dati sensibili a fasi di avvio specifiche, ad esempio estraendo le chiavi di crittografia per il file system root dal TPM.
- Fornisce un processo sicuro, automatico e senza intervento dell'utente per sbloccare le chiavi per decrittografare un'unità con una partizione root.
- Utilizzo di chip che supportano la specifica TPM 2.0, con la possibilità di tornare ai sistemi senza TPM.
Fonte: opennet.ru
