Lennart Poettering ha proposto una nuova architettura per il boot verificato di Linux

Lennart Poettering ha pubblicato una proposta per modernizzare il processo di avvio delle distribuzioni Linux, mirata a risolvere i problemi esistenti e semplificare l'organizzazione di un boot verificato completo, che attesti l'autenticità del kernel e dell'ambiente di sistema di base. Le modifiche necessarie per implementare la nuova architettura sono già incluse nel codice di systemd e riguardano componenti come systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase e systemd-creds.

Le modifiche proposte consistono nella creazione di un'unica immagine universale UKI (Unified Kernel Image), che unisce l'immagine del kernel Linux, il gestore per il caricamento del kernel da UEFI (UEFI boot stub) e l'ambiente di sistema in memoria initrd, utilizzato per l'inizializzazione iniziale nella fase prima del montaggio del filesystem radice. Invece dell'immagine del RAM disk initrd, nel UKI può essere confezionato l'intero sistema, consentendo la creazione di ambienti di sistema completamente verificati, caricabili in memoria. L'immagine UKI è presentata come un file eseguibile nel formato PE, che può essere caricato non solo tramite i tradizionali bootloader, ma anche chiamato direttamente dal firmware UEFI.

La possibilità di chiamata da UEFI consente di utilizzare il controllo dell'integrità e della validità tramite una firma digitale, che comprende non solo il kernel, ma anche il contenuto di initrd. Inoltre, il supporto per la chiamata dai tradizionali bootloader consente di mantenere funzionalità come la fornitura di più versioni del kernel e il ripristino automatico al kernel funzionante nel caso vengano riscontrati problemi con il nuovo kernel dopo l'installazione di un aggiornamento.

Attualmente, nella maggior parte delle distribuzioni Linux, il processo di inizializzazione segue la catena "firmware → shim Microsoft con firma digitale verificata → bootloader GRUB con firma digitale del distributore verificata → kernel Linux con firma digitale del distributore verificata → ambiente initrd non firmato → filesystem radice". L'assenza di verifica di initrd nelle tradizionali distribuzioni crea problemi di sicurezza, poiché, tra le altre cose, in questo ambiente vengono estratti i codici di crittografia per decifrare il filesystem radice.

La verifica dell'immagine initrd non è supportata poiché questo file è generato sul sistema locale dell'utente e non può essere firmato digitalmente dal distributore, il che complica notevolmente l'organizzazione del controllo in modalità SecureBoot (per firmare initrd, l'utente deve generare le proprie chiavi e caricarle nel firmware UEFI). Inoltre, l'attuale organizzazione di avvio non consente di utilizzare le informazioni dai registri TPM PCR (Platform Configuration Register) per controllare l'integrità dei componenti dello spazio utente, al di fuori di shim, grub e del kernel. Tra i problemi noti si menzionano inoltre le difficoltà nell'aggiornamento del bootloader e l'assenza della possibilità di limitare l'accesso alle chiavi nel TPM per le versioni obsolete del sistema operativo, diventate non più rilevanti dopo l'installazione dell'aggiornamento.

Obiettivi principali dell'introduzione della nuova architettura di avvio:

  • 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 caricati.
  • Collegare le risorse controllate ai registri TPM PCR con divisione tra proprietari.
  • Possibilità di calcolo anticipato dei valori PCR basati sul kernel, initrd, configurazione e identificatore locale del sistema utilizzati durante il caricamento.
  • Protezione contro attacchi di rollback che comportano un ritorno a una versione vulnerabile precedente del sistema.
  • Semplificazione e aumento dell'affidabilità degli aggiornamenti.
  • Supporto per aggiornamenti del sistema operativo che non richiedono un'applicazione ripetuta o la preparazione locale di risorse protette da TPM.
  • Prontezza del sistema per eseguire un'attestazione remota per confermare l'accuratezza del sistema operativo e delle impostazioni caricate.
  • Possibilità di allegare dati riservati a determinati stadi di avvio, ad esempio l'estrazione di chiavi di crittografia da TPM per il filesystem radice.
  • Fornitura di un processo di sblocco chiavi sicuro, automatico e privo di intervento dell'utente per la decrittazione del disco con la partizione radice.
  • Utilizzo di chip che supportano la specifica TPM 2.0, con la possibilità di ripristino su sistemi senza TPM.

Fonte: opennet.ru

Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS 🔥 Acquista hosting affidabile per siti web con protezione DDoS, server VPS VDS | ProHoster