Tutto ciò di cui hai bisogno è descritto qui
STRUTTURA DI FIRMA DEL MODULO KERNEL
CONTENUTI
- Panoramica.
- Configurazione della firma del modulo.
- Generazione di chiavi di firma.
- Chiavi pubbliche nel kernel.
- Firma manuale dei moduli.
- Moduli firmati e stripping.
- Caricamento dei moduli firmati.
- Firme non valide e moduli non firmati.
- Amministrazione / protezione della chiave privata.
PANORAMICA
La funzione di firma del modulo del kernel firma in modo crittografico i moduli durante l'installazione e quindi controlla la firma al momento del caricamento del modulo. Ciò consente una maggiore sicurezza del kernel impedendo il caricamento di moduli non firmati o di moduli firmati con una chiave non valida. La firma del modulo aumenta la sicurezza rendendo più difficile il caricamento di un modulo dannoso nel kernel. Il controllo della firma del modulo viene eseguito dal kernel in modo che non sia necessario disporre di bit di spazio utente attendibili.
Questa struttura utilizza certificati standard ITU-T X.509 per codificare le chiavi pubbliche coinvolte. Le firme non sono codificate esse stesse in nessun tipo di standard industriale. La struttura attualmente supporta solo lo standard di crittografia della chiave pubblica RSA (sebbene sia collegabile e consenta ad altri di essere utilizzati). I possibili algoritmi hash che possono essere utilizzati sono SHA-1, SHA-224, SHA-256, SHA-384 e SHA-512 (l'algoritmo è selezionato dai dati nella firma).
CONFIGURAZIONE DELLA FIRMA DEL MODULO
La funzione di firma del modulo è abilitata andando alla sezione "Abilita supporto modulo caricabile" della configurazione del kernel e accendendo
CONFIG_MODULE_SIG "Module signature verification"
Questo ha un numero di opzioni disponibili:
"Richiede che i moduli siano firmati validamente" (CONFIG_MODULE_SIG_FORCE)
Questo specifica come il kernel dovrebbe gestire un modulo che ha una firma per la quale la chiave non è nota o un modulo senza segno.
Se questa opzione è disattivata (ad es. "Permissivo"), i moduli per i quali la chiave non è disponibile e i moduli non firmati sono consentiti, ma il kernel sarà contrassegnato come contaminato e i moduli interessati saranno contrassegnati come contaminati, mostrato con il carattere 'E'.
Se questo è attivo (cioè "restrittivo"), verranno caricati solo i moduli che hanno una firma valida che può essere verificata da una chiave pubblica in possesso del kernel. Tutti gli altri moduli genereranno un errore.
Indipendentemente dall'impostazione qui, se il modulo ha un blocco di firma che non può essere analizzato, verrà rifiutato fuori mano.
"Firma automaticamente tutti i moduli" (CONFIG_MODULE_SIG_ALL)
Se questa opzione è attiva, i moduli verranno automaticamente firmati durante la fase modules_install di una build. Se questa opzione è disattivata, i moduli devono essere firmati manualmente utilizzando:
scripts/sign-file
"Con quale algoritmo hash devono essere firmati i moduli?"
Questo presenta una scelta di quale algoritmo hash la fase di installazione firmerà i moduli con:
CONFIG_MODULE_SIG_SHA1 "Sign modules with SHA-1"
CONFIG_MODULE_SIG_SHA224 "Sign modules with SHA-224"
CONFIG_MODULE_SIG_SHA256 "Sign modules with SHA-256"
CONFIG_MODULE_SIG_SHA384 "Sign modules with SHA-384"
CONFIG_MODULE_SIG_SHA512 "Sign modules with SHA-512"
Anche l'algoritmo selezionato qui verrà incorporato nel kernel (anziché essere un modulo) in modo che i moduli firmati con quell'algoritmo possano controllare le loro firme senza causare un ciclo di dipendenza.
"Nome file o UK PKCS # 11 della chiave di firma del modulo" (CONFIG_MODULE_SIG_KEY)
L'impostazione di questa opzione su qualcosa di diverso da "certs / signing_key.pem" disabilita la generazione automatica delle chiavi di firma e consente ai moduli del kernel di essere firmati con una chiave di propria scelta. La stringa fornita dovrebbe identificare un file contenente sia una chiave privata che il corrispondente certificato X.509 in forma PEM, oppure - su sistemi in cui OpenSSL ENGINE_pkcs11 è funzionante - un URI PKCS # 11 come definito da RFC7512. In quest'ultimo caso, l'URI PKCS # 11 dovrebbe fare riferimento sia a un certificato che a una chiave privata.
Se il file PEM contenente la chiave privata è crittografato o se il token PKCS # 11 richiede un PIN, questo può essere fornito in fase di compilazione mediante la variabile KBUILD_SIGN_PIN.
"Chiavi X.509 aggiuntive per il portachiavi di sistema predefinito" (CONFIG_SYSTEM_TRUSTED_KEYS)
Questa opzione può essere impostata sul nome file di un file con codifica PEM contenente certificati aggiuntivi che verranno inclusi nel keyring di sistema per impostazione predefinita.
Si noti che l'abilitazione della firma del modulo aggiunge una dipendenza dai pacchetti di sviluppo OpenSSL ai processi di compilazione del kernel per lo strumento che esegue la firma.
GENERAZIONE DI TASTI DI SEGNALAZIONE
Le chiavi crittografiche sono necessarie per generare e controllare le firme. Una chiave privata viene utilizzata per generare una firma e la chiave pubblica corrispondente viene utilizzata per controllarla. La chiave privata è necessaria solo durante la compilazione, dopo di che può essere eliminata o archiviata in modo sicuro. La chiave pubblica viene incorporata nel kernel in modo che possa essere utilizzata per controllare le firme mentre i moduli vengono caricati.
In condizioni normali, quando CONFIG_MODULE_SIG_KEY è invariato rispetto al suo valore predefinito, la generazione del kernel genererà automaticamente una nuova coppia di chiavi usando openssl se non ne esiste una nel file:
certs/signing_key.pem
durante la creazione di vmlinux (la parte pubblica della chiave deve essere integrata in vmlinux) usando i parametri in:
certs/x509.genkey
file (che viene generato anche se non esiste già).
Si consiglia vivamente di fornire il proprio file x509.genkey.
In particolare, nel file x509.genkey, la sezione req_distinguished_name dovrebbe essere modificata dal valore predefinito:
[ req_distinguished_name ]
#O = Unspecified company
CN = Build time autogenerated kernel key
#emailAddress = unspecified.user@unspecified.company
La dimensione della chiave RSA generata può anche essere impostata con:
[ req ]
default_bits = 4096
È anche possibile generare manualmente i file privati / pubblici della chiave usando il file di configurazione di generazione della chiave x509.genkey nel nodo radice dell'albero dei sorgenti del kernel Linux e il comando openssl. Di seguito è riportato un esempio per generare i file di chiave pubblica / privata:
openssl req -new -nodes -utf8 -sha256 -days 36500 -batch -x509 \
-config x509.genkey -outform PEM -out kernel_key.pem \
-keyout kernel_key.pem
Il percorso completo per il file kernel_key.pem risultante può quindi essere specificato nell'opzione CONFIG_MODULE_SIG_KEY e il certificato e la chiave ivi contenuti verranno utilizzati al posto di una coppia di chiavi generata automaticamente.
TASTI PUBBLICI NEL KERNEL
Il kernel contiene un anello di chiavi pubbliche che possono essere visualizzate da root. Sono in un portachiavi chiamato ".system_keyring" che può essere visto da:
[root@deneb ~]# cat /proc/keys
...
223c7853 I------ 1 perm 1f030000 0 0 keyring .system_keyring: 1
302d2d52 I------ 1 perm 1f010000 0 0 asymmetri Fedora kernel signing key: d69a84e6bce3d216b979e9505b3e3ef9a7118079: X509.RSA a7118079 []
...
Oltre alla chiave pubblica generata appositamente per la firma del modulo, è possibile fornire ulteriori certificati attendibili in un file codificato PEM a cui fa riferimento l'opzione di configurazione CONFIG_SYSTEM_TRUSTED_KEYS.
Inoltre, il codice dell'architettura può prendere le chiavi pubbliche da un negozio di ferramenta e aggiungere anche quelle (ad es. Dal database delle chiavi UEFI).
Infine, è possibile aggiungere ulteriori chiavi pubbliche facendo:
keyctl padd asymmetric "" [.system_keyring-ID] <[key-file]
per esempio:
keyctl padd asymmetric "" 0x223c7853 <my_public_key.x509
Si noti, tuttavia, che il kernel consentirà di aggiungere le chiavi a .system_keyring solo se il wrapper X.509 della nuova chiave è validamente firmato da una chiave che è già residente in .system_keyring al momento dell'aggiunta della chiave.
MODULI DI FIRMA MANUALE
Per firmare manualmente un modulo, usare lo strumento script / sign-file disponibile nella struttura dei sorgenti del kernel Linux. Lo script richiede 4 argomenti:
1. The hash algorithm (e.g., sha256)
2. The private key filename or PKCS#11 URI
3. The public key filename
4. The kernel module to be signed
Il seguente è un esempio per firmare un modulo del kernel:
scripts/sign-file sha512 kernel-signkey.priv \
kernel-signkey.x509 module.ko
L'algoritmo di hash utilizzato non deve corrispondere a quello configurato, ma in caso contrario, è necessario assicurarsi che l'algoritmo di hash sia incorporato nel kernel o possa essere caricato senza richiederlo.
Se la chiave privata richiede una passphrase o un PIN, può essere fornita nella variabile di ambiente $ KBUILD_SIGN_PIN.
MODULI E STRIPPING FIRMATI
Un modulo firmato ha una firma digitale semplicemente aggiunta alla fine. La stringa "~ Firma del modulo aggiunta ~." alla fine del file del modulo conferma la presenza di una firma ma non conferma la validità della firma!
I moduli firmati sono BRITTLE poiché la firma si trova all'esterno del contenitore ELF definito. Pertanto, NON POSSONO essere rimossi dopo che la firma è stata calcolata e allegata. Si noti che l'intero modulo è il payload firmato, incluse tutte le informazioni di debug presenti al momento della firma.
CARICAMENTO DEI MODULI FIRMATI
I moduli sono caricati con insmod, modprobe, init_module () o finit_module (), esattamente come per i moduli non firmati poiché nessuna elaborazione viene eseguita nello spazio utente. Il controllo della firma viene eseguito all'interno del kernel.
FIRME NON VALIDE E MODULI NON REGISTRATI
Se CONFIG_MODULE_SIG_FORCE è abilitato o enforcemodulesig = 1 è fornito nella riga di comando del kernel, il kernel caricherà solo moduli firmati validamente per i quali ha una chiave pubblica. Altrimenti, caricherà anche i moduli che non sono firmati. Qualsiasi modulo per il quale il kernel ha una chiave, ma che dimostra di avere una mancata corrispondenza della firma, non sarà autorizzato a caricare.
Qualsiasi modulo con una firma non analizzabile verrà rifiutato.
GESTIONE / PROTEZIONE DELLA CHIAVE PRIVATA
Poiché la chiave privata viene utilizzata per firmare i moduli, virus e malware potrebbero utilizzare la chiave privata per firmare i moduli e compromettere il sistema operativo. La chiave privata deve essere distrutta o spostata in una posizione sicura e non mantenuta nel nodo radice dell'albero dei sorgenti del kernel.