{"id":105384,"date":"2022-10-26T15:36:38","date_gmt":"2022-10-26T13:36:38","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux"},"modified":"2022-10-26T15:36:38","modified_gmt":"2022-10-26T13:36:38","slug":"lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/lennart-pottering-predlozhil-novuyu-arhitekturu-verificzirovannoj-zagruzki-linux","title":{"rendered":"Lennart Poettering ha proposto una nuova architettura per il boot verificato di Linux.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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 avvio completamente verificato, che confermi l'autenticit\u00e0 del kernel e dell'ambiente di sistema di base. Le modifiche necessarie per l'applicazione della nuova architettura sono gi\u00e0 incluse nel codice sorgente di systemd e riguardano componenti come systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase e systemd-creds. <\/p>\n
Le modifiche proposte si riducono alla creazione di un'unica immagine universale UKI (Unified Kernel Image), che combina l'immagine del kernel Linux, il gestore per il caricamento del kernel da UEFI (UEFI boot stub) e l'ambiente di sistema initrd, utilizzato per l'inizializzazione iniziale nella fase precedente al montaggio del File System radice. Invece dell'immagine RAM-disco initrd, nel UKI pu\u00f2 essere compreso l'intero sistema, consentendo di creare ambienti di sistema completamente verificati caricati in memoria. L'immagine UKI \u00e8 formattata come un file eseguibile nel formato PE, che pu\u00f2 essere caricato non solo tramite caricatori tradizionali, ma anche richiamato direttamente dal firmware UEFI. <\/p>\n
La possibilit\u00e0 di richiamare da UEFI consente di utilizzare la verifica dell'integrit\u00e0 e dell'autenticit\u00e0 tramite firma digitale, che copre non solo il kernel, ma anche il contenuto di initrd. Nel contempo, il supporto al richiamo dai caricatori tradizionali permette di mantenere funzioni come la fornitura di pi\u00f9 versioni del kernel e il ripristino automatico del kernel di lavoro in caso di problemi con il nuovo kernel dopo l'installazione di un aggiornamento. <\/p>\n
Attualmente, nella maggior parte delle distribuzioni Linux, viene utilizzata una catena di avvio durante l'inizializzazione: «firmware → shim firmato digitalmente da Microsoft → bootloader GRUB firmato digitalmente dalla distribuzione → kernel Linux firmato digitalmente dalla distribuzione → ambiente initrd non firmato → filesystem radice». L'assenza di verifica di initrd nelle distribuzioni tradizionali crea problemi di sicurezza, poich\u00e9 in questo ambiente si svolge anche l'estrazione delle chiavi per decrittografare il filesystem radice. <\/p>\n
La verifica dell'immagine initrd non \u00e8 supportata poich\u00e9 questo file viene creato sul sistema locale dell'utente e non pu\u00f2 essere firmato digitalmente dalla distribuzione, il che complica notevolmente l'organizzazione del controllo quando si utilizza la modalit\u00e0 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\u00e0 dei componenti dello spazio utente, a parte shim, grub e il kernel. Tra i problemi esistenti viene menzionata anche la complessit\u00e0 dell'aggiornamento del bootloader e l'assenza della possibilit\u00e0 di limitare l'accesso alle chiavi nel TPM per le versioni pi\u00f9 vecchie del sistema operativo, che sono diventate obsolete dopo l'installazione dell'aggiornamento. <\/p>\n
Obiettivi principali dell'implementazione della nuova architettura di avvio: <\/p>\n
\n
Fornire un processo di avvio completamente verificato, che copra tutte le fasi dalla firmware allo spazio utente, e che confermi l'autenticit\u00e0 e l'integrit\u00e0 dei componenti caricati.\n
Collegamento delle risorse controllate ai registri TPM PCR con divisione per proprietari.\n
Possibilit\u00e0 di calcolare in anticipo i valori PCR sulla base di kernel, initrd, configurazione e identificatore locale del sistema utilizzati durante l'avvio.\n
Protezione dagli attacchi di rollback, legati al ritorno a una versione vulnerabile precedente del sistema.\n
Semplificazione e aumento dell'affidabilit\u00e0 degli aggiornamenti.\n
Supporto per gli aggiornamenti del sistema operativo che non richiedono una riapplicazione o una preparazione locale delle risorse protette da TPM.\n
Prontezza del sistema per effettuare attestazioni remote per confermare la correttezza del sistema operativo caricato e delle impostazioni.\n
Possibilit\u00e0 di associare dati riservati a determinate fasi di caricamento, ad esempio il recupero da TPM delle chiavi di crittografia per il filesystem principale.\n
Fornire un processo sicuro, automatico e funzionante senza l'intervento dell'utente per lo sblocco delle chiavi per la decrittazione del disco con la partizione principale.\n
Utilizzo di chip che supportano la specifica TPM 2.0, con possibilit\u00e0 di tornare a sistemi privi di TPM. <\/ul>\n