Show Table of Contents
26.8. Signer des modules de noyau pour le démarrage sécurisé « Secure Boot »
Red Hat Enterprise Linux 7 inclut la prise en charge de la fonctionnalité de démarrage sécurisé « UEFI Secure Boot », ce qui signifie que Red Hat Enterprise Linux 7 peut être installé et exécuté sur des systèmes où le démarrage sécurisé « UEFI Secure Boot » est activé. Notez que Red Hat Enterprise Linux 7 ne requiert pas l'utilisation de « UEFI Secure Boot » sur les systèems UEFI.
Lorsque Secure Boot est activé, les chargeurs de démarrage des systèmes d'exploitation EFI, le noyau Red Hat Enterprise Linux, et tous les modules de noyau doivent être signés avec une clé privée et authentifiés avec la clé publique correspondante. La distribution Red Hat Enterprise Linux 7 inclut des chargeurs de démarrage signés et des modules de noyau signés. En outre, le chargeur de démarrage signé de la première étape et le noyau signé incluent des clés publiques Red Hat intégrées. Ces binaires exécutables signés et clés intégrées permettent à Red Hat Enterprise Linux 7 d'installer, de démarrer, et d'exécuter avec les clés de l'autorité de certification Microsoft UEFI Secure Boot fournies par le microprogramme UEFI sur les systèmes qui prennent en charge les démarrages UEFI Secure Boot. Notez que tous les systèmes basés UEFI n'incluent pas la prise en charge de Secure Boot.
Les informations fournies dans les sections suivantes décrivent les étapes nécessaires vous permettant d'auto-signer des modules de noyau créés de manière privée pour une utilisation avec Red Hat Enterprise Linux 7 sur des systèmes basés UEFI où Secure Boot est activé. Ces sections fournissent également un aperçu des options disponibles pour obtenir votre clé publique sur le système cible sur lequel vous souhaitez déployer le module de noyau.
26.8.1. Conditions préalables
Pour permettre la signature de modules créés à l'externe, il est requis d'installer les outils répertoriés ci-dessous sur le système.
Tableau 26.1. Outils requis
| Outil | Fourni par le paquet | Utilisé sur | But |
|---|---|---|---|
openssl | openssl | Système de génération | Génère une paire de clés X.509 publique et privée |
sign-file | kernel-devel | Système de génération | Script Perl utilisé pour signer les modules de noyau |
perl | perl | Système de génération | Interprète Perl utilisé pour exécuter le script de signature |
mokutil | mokutil | Système cible | Outil optionnel utilisé pour inscrire la clé publique manuellement |
keyctl | keyutils | Système cible | Outil optionnel utilisé pour afficher des clés publiques dans l'anneau de clés du système |
Note
Remarquez que le système de génération avec lequel vous créez et signez votre module de noyau ne nécessite pas qu'UEFI Secure Boot soit activé et ne nécessite même pas d'être un système basé UEFI.
26.8.2. Authentification du module de noyau
Dans Red Hat Enterprise Linux 7, lorsqu'un module de noyau est chargé, la signature du module est vérifiée à l'aide de clés X.509 publiques sur l'anneau de clés du système du noyau, à l'exception des clé se trouvant sur l'anneau des clés sur liste noire du système du noyau.
26.8.2.1. Sources de clés publiques utilisées pour authentifier des modules de noyau
Pendant le démarrage, le noyau charge les clés X.509 dans l'anneau de clés du système dans l'anneau des clés sur liste noire du système à partir d'un ensemble de magasins de clés persistantes, comme décrit dans la Tableau 26.2, « Sources pour les anneaux de clés système »
Tableau 26.2. Sources pour les anneaux de clés système
| Source des clés X.509 | Capacité de l'utilisateur à ajouter des clés | État UEFI Secure Boot | Clés chargées pendant le démarrage |
|---|---|---|---|
| Intégré au noyau | Non | - | .system_keyring |
| UEFI Secure Boot "db" | Limité | Non activé | Non |
| Activé | .system_keyring | ||
| UEFI Secure Boot "dbx" | Limité | Non activé | Non |
| Activé | .system_keyring | ||
Intégré au chargeur de démarrage shim.efi | Non | Non activé | Non |
| Activé | .system_keyring | ||
| Liste MOK (« Machine Owner Key ») | Oui | Non activé | Non |
| Activé | .system_keyring |
Remarquez que si le système n'est pas basé UEFI ou si UEFI Secure Boot n'est pas activé, alors seules les clés intégrées au noyau seront chargées dans l'anneau des clés du système et vous n'aurez pas la capacité d'augmenter cet ensemble de clés sans regénérer le noyau. L'anneau des clés sur liste noire du système est une liste de clés X.509 qui ont été révoquées. Si votre module est signé par une clé sur la liste noire, alors son authentification échouera même si votre clé publique se trouve dans l'anneau des clés du système.
Vous pouvez afficher des informations concernant les clés sur les anneaux des clés du système en utilisant l'utilitaire
keyctl. Ci-dessous figure un exemple abbrévié d'un système Red Hat Enterprise Linux 7 sur lequel UEFI Secure Boot n'est pas activé.
~]# keyctl list %:.system_keyring
3 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...
Ci-dessous figure un exemple de sortie abbréviée d'un système Red Hat Enterprise Linux 7 sur lequel UEFI Secure Boot est activé.
~]# keyctl list %:.system_keyring
6 keys in keyring:
...asymmetric: Red Hat Enterprise Linux Driver Update Program (key 3): bf57f3e87...
...asymmetric: Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29...
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed...
...asymmetric: Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e...
...asymmetric: Red Hat Enterprise Linux kernel signing key: 4249689eefc77e95880b...
...asymmetric: Red Hat Enterprise Linux kpatch signing key: 4d38fd864ebe18c5f0b7...
La sortie ci-dessus montre l'ajout de deux clés provenant des clés UEFI Secure Boot "db" plus
Red Hat Secure Boot (CA key 1), qui est intégrée au chargeur de démarrage shim.efi. Vous pouvez également chercher les messages de la console du noyau qui identifient les clés avec une source liée à UEFI Secure Boot, c'est-à-dire UEFI Secure Boot db, un shim intégré, et une liste MOK.
~]# dmesg | grep 'EFI: Loaded cert'
[5.160660] EFI: Loaded cert 'Microsoft Windows Production PCA 2011: a9290239...
[5.160674] EFI: Loaded cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309b...
[5.165794] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a8...26.8.2.2. Conditions préalables à l'authentification de modules de noyau
Si UEFI Secure Boot est activé ou si le paramètre de noyau
module.sig_enforce a été spécifié, alors seuls les modules de noyau signés qui sont authentifiés à l'aide d'une clé sur l'anneau des clés du système pourront être chargés, à condition que la clé publique ne se trouve pas sur l'anneau des clés sur liste noire du système. Si UEFI Secure Boot est désactivé et si le paramètre de noyau module.sig_enforce n'a pas été spécifié, alors les modules de noyau non-signés et les modules de noyau signés sans clé publique pourront être chargés. Ceci est résumé dans la Tableau 26.3, « Conditions préalables à l'authentification de modules de noyau pour effectuer un chargement ».
Tableau 26.3. Conditions préalables à l'authentification de modules de noyau pour effectuer un chargement
| Module signé | Clé publique trouvée et signature valide | État UEFI Secure Boot | module.sig_enforce | Charge du module | Noyau avarié |
|---|---|---|---|---|---|
| Non signé | - | Non activé | Non activé | Réussi | Oui |
| Non activé | Activé | Échoué | |||
| Activé | - | Échoué | - | ||
| Signé | Non | Non activé | Non activé | Réussi | Oui |
| Non activé | Activé | Échoué | - | ||
| Activé | - | Échoué | - | ||
| Signé | Oui | Non activé | Non activé | Réussi | Non |
| Non activé | Activé | Réussi | Non | ||
| Activé | - | Réussi | Non |
Les sections suivantes décrivent comment générer une paire de clés X.509 publique et privée, comment utiliser la clé privée pour signer un module de noyau, et comment inscrire la clé publique dans une source pour l' anneau des clés du système.
26.8.3. Générer une paire de clés X.509 publique et privée
Vous devez générer une paire de clés X.509 publique et privée qui sera utilisée pour signer un module de noyau une fois qu'il aura été créé. La clé publique correspondante sera utilisée pour authentifier le module du noyau après son chargement.
- L'outil
opensslpeut être utilisé pour générer une paire de clés qui satisfait les conditions préalables à la signature d'un module de noyau sur Red Hat Enterprise Linux 7. Certains des paramètres de cette requêtre de génération de clé sont mieux spécifiés à l'aide d'un fichier de configuration ; veuillez suivre l'exemple ci-dessous pour créer votre propre fichier de configuration.~]#
cat << EOF > configuration_file.config[ req ] default_bits = 4096 distinguished_name = req_distinguished_name prompt = no string_mask = utf8only x509_extensions = myexts [ req_distinguished_name ] O = Organization CN = Organization signing key emailAddress = E-mail address [ myexts ] basicConstraints=critical,CA:FALSE keyUsage=digitalSignature subjectKeyIdentifier=hash authorityKeyIdentifier=keyid EOF - Après avoir créé le fichier de configuration, vous pouvez créer une paire de clés X.509 publique et privée. La clé publique sera écrite sur le fichier
public_key.deret la clé privée sera écrite sur le fichierprivate_key.priv.~]#
openssl req -x509 -new -nodes -utf8 -sha256 -days 36500 \ -batch -config configuration_file.config -outform DER \ -out public_key.der \ -keyout private_key.priv - Veuillez inscrire votre clé publique sur tous les systèmes sur lesquels vous souhaitez authentifier et charger votre module de noyau.
Avertissement
Prenez soin de bien garder privé le contenu de votre clé privée. Dans de mauvaises mains, cette clé pourrait être utilisée pour compromettre tout système qui possède votre clé publique.
26.8.4. Inscrire une clé publique sur un système cible
Lorsque Red Hat Enterprise Linux 7 démarre sur un système bas UEFI avec Secure Boot activé, toutes les clés se trouvant dans la base de données de clés Secure Boot db, mais pas dans la base de données dbx des clés révoquées, sont chargées dans l'anneau des clés du système par le noyau. L'anneau des clés du système est utilisé pour authentifier des modules de noyau.
26.8.4.1. Image du microprogramme d'usine, y compris la clé publique
Pour faciliter l'authentification de modules de noyau sur vos systèmes, envisagez de demander à votre fournisseur de systèmes d'incorporer votre clé publique dans la base de données de clés UEFI Secure Boot sous leur image du microprogramme d'usine.
26.8.4.2. Image d'inscription de clé exécutable ajoutant une clé publique
Il est possible d'ajouter une clé à une base de données Secure Boot remplie et active. Ceci peut être effectué en écrivant et en fournissant une image d'inscription exécutable EFI. Une telle image d'inscription contient une requête correctement formée d'ajout d'une clé à la base de données de clés Secure Boot. Cette requête doit inclure des données correctement signées par la clé privée qui correspond à une clé publique se trouvant déjà dans la base de données KEK (« Key Exchange Key ») de Secure Boot. En outre, cette image EFI doit être signée par une clé privée qui correspond à une clé publique se trouvant déjà dans la base de données des clés.
Il est également possible d'écrire une image d'inscription exécutée sous Red Hat Enterprise Linux 7. Cependant, l'image Red Hat Enterprise Linux 7 doit être correctement signée par une clé privée correspondant à une clé publique se trouvant déjà dans la base de données KEK.
La construction de chaque type d'image d'inscription de clé requiert de l'aide de la part du fournisseur de plateforme.
26.8.4.3. Administrateur systèmes ajoutant manuellement la clé publique à la liste MOK
La fonctionnalité MOK (« Machine Owner Key ») est prise en charge par Red Hat Enterprise Linux 7 et peut être utilisée pour élargir la base de données de clés UEFI Secure Boot. Lorsque Red Hat Enterprise Linux 7 démarre sur un système activé UEFI avec Secure Boot activé, les clés de la liste MOK sont également ajoutées à l'anneau des clés du système en plus d'être ajoutées aux clés de la base de données des clés. Les clés de la liste MOK sont également stockées de manière persistante et sécurisée de la même manière que les clés de la base de données de clés Secure Boot, mais il s'agit de deux installations différentes. L'installation MOK est prise en charge par shim.efi, MokManager.efi, grubx64.efi, et par l'utilitaire Red Hat Enterprise Linux 7
mokutil.
La capacité principale fournie par l'installation MOK consiste à ajouter des clés publiques à la liste MOK sans avoir besoin de récupérer la chaîne de la clé sur une autre clé déjà présente dans la base de données KEK. Cependant, l'inscription d'une clé MOK requiert une interaction manuelle de la part d'un utilisateur présent physiquement sur la console système UEFI sur chaque système cible. Néanmoins, l'installation MOK offre une excellente méthode pour tester les nouvelles paires de clés générées et pour tester les modules de noyau signés avec celles-ci.
Veuillez suivre ces étapes pour ajouter votre clé publique à la liste MOK :
- Demandez l'ajout de votre clé publique à la liste MOK en utilisant un utilitaire d'espace utilisateur Red Hat Enterprise Linux 7 :
~]#
mokutil--importmy_signing_key_pub.derIl vous sera demandé de saisir et de confirmer un mot de passe pour cette requête d'inscription MOK. - Redémarrez la machine.
- La requête d'inscription de clé MOK en attente sera remarquée par
shim.efiet lanceraMokManager.efiafin de vous permettre de terminer l'inscription à partir de la console UEFI. Vous devrez saisir le mot de passe précédemment associé à cette requête et confirmer l'inscription. Votre clé publique est ajoutée à la liste MOK, qui est persistante.
Une fois qu'une clé est sur la liste MOK, elle sera automatiquement propagée sur l'anneau des clés du système et pendant les démarrages suivants, lorsqu'UEFI Secure Boot est activé.
26.8.5. Signer un module de noyau avec la clé privée
Il n'y a pas d'étape supplémentaire requise pour préparer votre module de noyau à une signature. Vous pouvez générer votre module de noyau normalement. En supposant qu'un Makefile approprié et ses sources correspondantes soient effectivement présents, veuillez suivre ces étapes pour générer votre module et le signer :
- Générez votre module
my_module.kode manière standard :~]#
make -C /usr/src/kernels/$(uname -r) M=$PWD modules - Signez votre module de noyau avec votre clé privée. Ceci peut être fait avec un script Perl. Remarquez que le script requiert que les fichiers contenant la clé privée et la clé publique soient fournis, ainsi que le fichier du module de noyau que vous souhaitez signer.
~]#
perl /usr/src/kernels/$(uname -r)/scripts/sign-file \ sha256 \ my_signing_key.priv \ my_signing_key_pub.der \ my_module.ko
Votre module se trouve sous le format d'image ELF et ce script calcule et ajoute la signature directement sur l'image ELF dans votre fichier
my_module.ko. L'utilitaire modinfo peut être utilisé pour afficher des informations sur la signature du module du noyau, si elle est présente. Pour obtenir des informations sur l'utilisation de l'utilitaire, veuillez consulter la Section 26.2, « Afficher des informations sur un module ».
Remarquez que cette signature ajoutée n'est pas contenue dans une section d'image ELF et n'est pas une partie formelle de l'image ELF. Ainsi, des outils tels que
readelf ne seront pas en mesure d'afficher la signature sur votre module de noyau.
Votre module de noyau est désormais prêt à être chargé. Remarquez que votre module de noyau signé est également chargeable sur des systèmes où UEFI Secure Boot est désactivé ou sur un système non-UEFI. Cela signifie que vous ne devrez pas fournir une version signée et une version non-signée à la fois de votre module de noyau.
26.8.6. Charger un module de noyau signé
Une fois que votre clé publique est inscrite et se trouve dans l'anneau de clés du système, les mécanismes normaux de chargement de modules de noyau fonctionneront de manière transparente. Dans l'exemple suivant, vous utiliserez
mokutil pour ajouter votre clé publique à la liste MOK et vous chargerez votre module de noyau manuellement avec modprobe.
- Optionnellement, vous pouvez vérifier que votre module de noyau ne se charge pas avant d'avoir inscrit la clé publique. Premièrement, veuillez vérifier quelles clés ont été ajoutées à l'anneau des clés du système lors du démarrage actuel en exécutant la commande
keyctl list %:.system_keyringen tant qu'utilisateur root. Comme votre clé publique n'a pas encore été inscrite, elle ne sera pas affichée dans la sortie de la commande. - Demander l'inscription de votre clé publique.
~]#
mokutil --import my_signing_key_pub.der - Redémarrez et terminez l'inscription sur la console UEFI.
~]#
reboot - Après les redémarrages système, veuillez vérifier à nouveau les clés sur l'anneau des clés du système.
~]#
keyctl list %:.system_keyring - Vous devriez désormais être en mesure de charger votre module de noyau.
~]#
modprobe -v my_moduleinsmod /lib/modules/3.10.0-123.el7.x86_64/extra/my_module.ko ~]#lsmod | grep my_modulemy_module 12425 0