Che cosa è UEFI Secure Boot?

UEFI Secure boot è un meccanismo di verifica per garantire che il codice lanciato dal firmware sia attendibile.

L’uso corretto e sicuro di UEFI Secure Boot richiede che ogni binario caricato all’avvio sia convalidato contro chiavi note, situate nel firmware, che denotano fornitori e fonti attendibili per i binari, o binari specifici attendibili che possono essere identificati tramite hash crittografico.

La maggior parte dell’hardware x86 proviene dalla fabbrica pre-caricata con le chiavi Microsoft. Ciò significa che in genere possiamo fare affidamento sul firmware di questi sistemi per fidarci dei binari firmati da Microsoft e la comunità Linux si basa pesantemente su questa ipotesi per il funzionamento di Secure Boot. Questo è lo stesso processo utilizzato da Red Hat e SUSE, per esempio.

Molte architetture ARM e altre supportano anche UEFI Secure Boot, ma potrebbero non essere chiavi di pre-caricamento nel firmware. Su queste architetture, potrebbe essere necessario firmare nuovamente le immagini di avvio con un certificato caricato nel firmware dal proprietario dell’hardware.

Piano di attuazione iniziale: Piano di attuazione.

Architetture supportate

• amd64: un binario shim firmato da Microsoft e un binario grub firmato da Canonical sono forniti nell’archivio principale di Ubuntu come shim-signed o grub-efi-amd64-signed.

• arm64: A partire dal 20.04 (‘focal’), un binario shim firmato da Microsoft e un binario grub firmato da Canonical sono forniti nell’archivio principale di Ubuntu come shim-signed o grub-efi-arm64-signed. C’è un bug GRUB sotto inchiesta che deve essere risolto prima che questo funzioni end to end.

Test UEFI Secure Boot

Se siete interessati a testare Secure Boot sul vostro sistema, consultare il how-to qui: UEFI / SecureBoot / Testing.

Come funziona UEFI Secure Boot su Ubuntu

Su Ubuntu, tutti i binari pre-costruiti destinati ad essere caricati come parte del processo di avvio, ad eccezione dell’immagine initrd, sono firmati dal certificato UEFI di Canonical, che a sua volta è implicitamente attendibile essendo incorporato nel caricatore shim, a sua volta firmato da Microsoft.

Su architetture o sistemi in cui i certificati di firma precaricati di Microsoft non sono disponibili o caricati nel firmware, gli utenti possono sostituire le firme esistenti su shim o grub e caricarle come desiderano, verificando i propri certificati importati nel firmware del sistema.

All’avvio del sistema, il firmware carica il binario shim come specificato nelle variabili BootEntry del firmware. Ubuntu installa il proprio BootEntry al momento dell’installazione e può aggiornarlo in qualsiasi momento il bootloader GRUB viene aggiornato. Poiché il binario shim è firmato da Microsoft; viene convalidato e accettato dal firmware durante la verifica rispetto ai certificati già presenti nel firmware. Poiché il binario shim incorpora un certificato Canonical e il proprio database di fiducia, ulteriori elementi dell’ambiente di avvio possono, oltre ad essere firmati da uno dei certificati accettabili pre-caricati nel firmware, essere firmati dalla chiave UEFI di Canonical.

La prossima cosa caricata da shim è l’immagine del secondo stadio. Questa può essere una delle due cose: o GRUB, se il sistema si sta avviando normalmente; o MokManager, se è necessaria la gestione delle chiavi, come configurato dalle variabili del firmware (di solito cambiato quando il sistema era in esecuzione in precedenza).

Se si avvia normalmente; il binario GRUB (grub*.efi) viene caricato e la sua convalida viene tentata contro tutte le fonti attendibili precedentemente note. Il binario GRUB per Ubuntu è firmato dalla chiave UEFI canonica, quindi viene convalidato con successo e il processo di avvio continua.

Se si avvia per procedere con le attività di gestione delle chiavi, il binario MokManager (mm*.efi) è caricato. Questo binario è esplicitamente attendibile da shim essendo firmato da una chiave effimera che esiste solo mentre il binario shim è in costruzione. Ciò significa che solo il binario MokManager costruito con un particolare binario shim sarà consentito di eseguire e limita la possibilità di compromesso dall’uso di strumenti compromessi. MokManager consente a qualsiasi utente presente nella console di sistema di registrare chiavi, rimuovere chiavi attendibili, registrare hash binari e attivare la convalida di avvio sicuro a livello di shim, ma la maggior parte delle attività richiede l’inserimento di una password impostata in precedenza per confermare che l’utente nella console è effettivamente la persona che ha richiesto le modifiche. Tali password sopravvivono solo in una singola esecuzione di shim / MokManager; e vengono cancellate non appena il processo viene completato o annullato. Una volta completata la gestione delle chiavi, il sistema viene riavviato e non continua semplicemente con l’avvio, poiché potrebbero essere necessarie modifiche alla gestione delle chiavi per completare correttamente l’avvio.

Una volta che il sistema continua l’avvio su GRUB, il processo GRUB carica qualsiasi configurazione richiesta (solitamente caricando la configurazione dall’ESP (partizione di sistema EFI), puntando a un altro file di configurazione sulla partizione root o di avvio), che la punterà all’immagine del kernel da caricare.

Applicazioni EFI fino a questo punto avendo pieno accesso al firmware di sistema, incluso l’accesso alla modifica delle variabili del firmware attendibile, il kernel da caricare deve anche essere convalidato rispetto al database di fiducia. I kernel ufficiali di Ubuntu sono firmati dalla chiave UEFI canonica, vengono convalidati con successo e il controllo viene consegnato al kernel. Le immagini Initrd non sono convalidate.

Nel caso di kernel non ufficiali, o kernel creati dagli utenti, è necessario eseguire ulteriori passaggi se gli utenti desiderano caricare tali kernel mantenendo tutte le funzionalità di UEFI Secure Boot. Tutti i kernel devono essere firmati per poter essere caricati da GRUB quando UEFI Secure Boot è abilitato, quindi l’utente richiederà di procedere con la propria firma. In alternativa, gli utenti potrebbero voler disabilitare la convalida in shim durante l’avvio con Secure Boot abilitato su un kernel ufficiale usando ‘sudo mokutil disable disable-validation’, fornendo una password quando richiesto e riavviando; o disabilitare del tutto Secure Boot nel firmware.

Fino a questo punto, qualsiasi errore di convalida di un’immagine da caricare viene riscontrato con un errore critico che interrompe il processo di avvio. Il sistema non continuerà l’avvio e potrebbe riavviarsi automaticamente dopo un periodo di tempo dato che altre variabili di BootEntry potrebbero contenere percorsi di avvio validi e attendibili.

Una volta caricati, i kernel convalidati disabiliteranno i Servizi di avvio del firmware, eliminando così i privilegi e passando in modo efficace alla modalità utente; dove l’accesso alle variabili attendibili è limitato alla sola lettura. Date le ampie autorizzazioni concesse ai moduli del kernel, qualsiasi modulo non incorporato nel kernel dovrà anche essere convalidato al momento del caricamento. I moduli costruiti e spediti da Canonical con i kernel ufficiali sono firmati dalla chiave Canonical UEFI e come tali sono attendibili. I moduli personalizzati richiederanno all’utente di prendere le misure necessarie per firmare i moduli prima che il loro caricamento sia consentito dal kernel. Questo può essere ottenuto usando il comando’ kmodsign’.

I moduli non firmati vengono semplicemente rifiutati dal kernel. Qualsiasi tentativo di inserirli con insmod o modprobe fallirà con un messaggio di errore.

Dato che molti utenti richiedono moduli di terze parti per i loro sistemi per funzionare correttamente o per alcuni dispositivi per funzionare; e che questi moduli di terze parti richiedono la costruzione localmente sul sistema da montare al kernel in esecuzione, Ubuntu fornisce strumenti per automatizzare e semplificare il processo di firma.

Come posso fare la firma non automatica dei driver?

Alcuni progetti possono richiedere l’uso di driver del kernel personalizzati che non sono impostati in modo tale da funzionare con DKMS. In questi casi, le persone dovrebbero fare uso degli strumenti inclusi nel pacchetto firmato da shim: lo script update-secureboot-policy è disponibile per generare un nuovo MOK (se nessun modulo DKMS ha già attivato la generazione di uno).

Utilizzare il seguente comando per registrare una chiave esistente in shim:

sudo update-secureboot-policy --enroll-key

Se non esiste MOK, lo script uscirà con un messaggio in tal senso. Se la chiave è già registrata, lo script uscirà, senza fare nulla. Se la chiave esiste ma non è stata registrata, all’utente verrà richiesta una password da utilizzare dopo il riavvio, in modo che la chiave possa essere registrata.

Si può generare un nuovo MOK usando il seguente comando:

sudo update-secureboot-policy --new-key

E quindi registrare la chiave appena generata in shim con il comando precedentemente menzionato per quell’attività.

I moduli del kernel possono quindi essere firmati con il comando kmodsign (vedi UEFI / SecureBoot / Signing) come parte del loro processo di compilazione.

Implicazioni di sicurezza nella gestione delle chiavi del proprietario della macchina

Il MOK generato al momento dell’installazione o all’aggiornamento è specifico della macchina, e consentito solo dal kernel o dallo shim di firmare i moduli del kernel, utilizzando uno specifico OID KeyUsage (1.3.6.1.4.1.2312.16.1.2) che denota le limitazioni del MOK.

Le versioni recenti di shim includono la logica per seguire le limitazioni delle chiavi di sola firma del modulo. Queste chiavi potranno essere registrate nel firmware nel database trust di shim, ma verranno ignorate quando shim o GRUB convalidano le immagini da caricare nel firmware. La funzione verify () di Shim convaliderà con successo solo le immagini firmate da chiavi che non includono” Solo firma modulo ” (1.3.6.1.4.1.2312.16.1.2) KeyUsage OID. I kernel di Ubuntu utilizzano il database global trust (che include sia shim che il firmware) e accetterà una qualsiasi delle chiavi incluse come chiavi di firma durante il caricamento dei moduli del kernel.

Date le limitazioni imposte al MOK generato automaticamente e il fatto che gli utenti con accesso superutente al sistema e accesso alla console di sistema per inserire la password richiesta al momento della registrazione delle chiavi hanno già accesso di alto livello al sistema; la chiave MOK generata viene mantenuta sul filesystem come file regolari di proprietà di root con autorizzazioni di sola lettura. Ciò è ritenuto sufficiente per limitare l’accesso al MOK per la firma da parte di utenti malintenzionati o script, soprattutto dato che non esiste MOK sul sistema a meno che non richieda driver di terze parti. Ciò limita la possibilità di compromesso dall’uso improprio di una chiave MOK generata alla firma di un modulo kernel dannoso. Ciò equivale al compromesso delle applicazioni userland che sarebbe già possibile con l’accesso superutente al sistema, e la protezione di questo è fuori dall’ambito di UEFI Secure Boot.

I sistemi precedenti potrebbero aver disabilitato la convalida di avvio sicuro in shim. Come parte del processo di aggiornamento, questi sistemi verranno migrati per riattivare la convalida di avvio sicuro in shim e registrare una nuova chiave MOK quando applicabile.

Processo di generazione e firma MOK

Il processo di generazione e firma delle chiavi è leggermente diverso in base al fatto che abbiamo a che fare con una nuova installazione o un aggiornamento del sistema che eseguiva precedentemente Ubuntu; questi due casi sono chiaramente indicati di seguito.

In tutti i casi, se il sistema non si avvia in modalità UEFI, non si verificheranno passaggi speciali di firma del modulo del kernel o generazione di chiavi.

Se Secure Boot è disabilitato, la generazione e la registrazione di MOK avvengono ancora, poiché l’utente potrebbe in seguito abilitare Secure Boot. Essi sistema dovrebbe funzionare correttamente se questo è il caso.

L’utente installa Ubuntu su un nuovo sistema

L’utente passa attraverso il programma di installazione. All’inizio, quando si prepara all’installazione e solo se il sistema richiede moduli di terze parti per funzionare, all’utente viene richiesta una password di sistema che viene chiaramente contrassegnata come richiesta al termine dell’installazione e, mentre il sistema viene installato, viene generato automaticamente un nuovo MOK senza ulteriori interazioni da parte dell’utente.

I driver di terze parti o i moduli del kernel richiesti dal sistema verranno compilati automaticamente quando il pacchetto è installato e il processo di compilazione include una fase di firma. La fase di firma utilizza automaticamente il MOK generato in precedenza per firmare il modulo, in modo tale che possa essere immediatamente caricato una volta riavviato il sistema e il MOK è incluso nel database di fiducia del sistema.

Una volta completata l’installazione e riavviato il sistema, al primo avvio all’utente viene presentato il programma MokManager (parte dello shim loader installato), come un insieme di pannelli in modalità testo che tutto l’utente deve registrare il MOK generato. L’utente seleziona “Enroll MOK”, viene mostrata un’impronta digitale del certificato da registrare e viene richiesto di confermare l’iscrizione. Una volta confermato, il nuovo MOK verrà inserito nel firmware e all’utente verrà chiesto di riavviare il sistema.

Quando il sistema si riavvia, i driver di terze parti firmati dal MOK appena registrato verranno caricati se necessario.

L’utente aggiorna un sistema Ubuntu abilitato per UEFI a una nuova versione in cui il sistema richiede driver di terze parti

All’aggiornamento, i pacchetti firmati shim e shim vengono aggiornati. Le attività post-installazione del pacchetto firmato dallo shim procedono a generare un nuovo MOK e richiedono all’utente una password chiaramente indicata come richiesta una volta completato il processo di aggiornamento e riavviato il sistema.

Durante l’aggiornamento, i pacchetti del kernel e i moduli di terze parti vengono aggiornati. I moduli di terze parti vengono ricostruiti per i nuovi kernel e il loro processo post-build procede per firmarli automaticamente con il MOK.

Dopo l’aggiornamento, si consiglia all’utente di riavviare il proprio sistema.

Al riavvio, l’utente viene presentato con il programma MokManager (parte del caricatore shim installato), come un insieme di pannelli in modalità testo che tutto l’utente di registrare il MOK generato. L’utente seleziona “Enroll MOK”, viene mostrata un’impronta digitale del certificato da registrare e viene richiesto di confermare l’iscrizione. All’utente viene anche presentato un prompt per riattivare la convalida di avvio sicuro (nel caso in cui sia stato trovato disabilitato); e MokManager richiede nuovamente la conferma da parte dell’utente. Una volta confermati tutti i passaggi, la convalida shim viene riattivata, il nuovo MOK verrà inserito nel firmware e all’utente verrà chiesto di riavviare il sistema.

Quando il sistema si riavvia, i driver di terze parti firmati dal MOK appena registrato verranno caricati se necessario.

In tutti i casi, una volta che il sistema è in esecuzione con UEFI Secure Boot abilitato e una versione recente di shim; l’installazione di qualsiasi nuovo modulo DKMS (driver di terze parti) procederà a firmare il modulo costruito con il MOK. Ciò avverrà senza l’interazione dell’utente se esiste una chiave MOK valida sul sistema e sembra già essere registrata.

Se non esiste alcun MOK o il MOK esistente non è registrato, una nuova chiave verrà creata automaticamente poco prima della firma e all’utente verrà richiesto di registrare la chiave fornendo una password che verrà richiesta al riavvio.