Contents
- Qu'est-ce qu'UEFI ?
- Qu'est-ce que l'option SecureBoot d'UEFI ?
- Que n'est pas l'option SecureBoot d'UEFI ?
- Shim
-
MOK - Clé Propriétaire de la Machine
- Généralités
- Est-ce que le système a démarré via SecureBoot ?
- Générer une nouvelle clé
- Enregistrement de la clé
- Définir les variables d'information du noyau Linux
- Utiliser la clé dans le noyau Linux
- Utiliser la clé pour signer les modules
- Vérifier si un module est signé
- Désactiver/Ré-activer Secure Boot
- Architectures et paquets pris en charge
- Tester Secure Boot UEFI
- Limites de Secure Boot
- Infrastructure - Comment cela fonctionne dans Debian
- Tester Secure Boot dans une machine virtuelle
- Problèmes avec l'architecture arm64
Qu'est-ce qu'UEFI ?
Unified Extensible Firmware Interface qui se traduit en Francais par "Interface micrologicielle extensible unifiée". Lire la page UEFI pour avoir plus de détails.
Qu'est-ce que l'option SecureBoot d'UEFI ?
L'option Secure Boot d'UEFI est un mécanisme de vérification permettant de garantir la fiabilité du code exécuté par le micrologiciel UEFI de l'ordinateur. Il est conçu pour protéger le système contre du code malicieux qui serait chargé et exécuté précédemment dans le processus de démarrage, avant que le système d'exploitation ne soit lui-même chargé.
Secure Boot fonctionne en utilisant des signatures et des sommes de contrôles cryptographiques. Chaque programme qui est chargé par le micrologiciel inclut une signature et une somme de contrôle, puis avant de permettre l'exécution le micrologiciel vérifiera la fiabilité du programme selon la somme de contrôle et la signature. Lorsque l'option Secure Boot est active sur le système, tout essai d'exécuter un programme non fiable ne sera pas autorisé. Elle arrête tout code non attendu, non autorisé dans l'environnement UEFI.
La plupart des matériels x86 sont pré-chargés en usine des clés Microsoft. Cela signifie que le micrologiciel sur ces systèmes aura confiance dans les binaires fournis par Microsoft. La plupart des systèmes modernes seront livrés avec l'option Secure Boot activée ; ainsi, ils n'exécuteront aucun code non signé par défaut, mais il est possible de changer la configuration du micrologiciel, soit en désactiver l'option soit en chargeant des clés de signatures supplémentaires.
La plupart des programmes qui sont sensés s'exécuter dans l'environnement UEFI sont des chargeurs de démarrages, mais d'autres existent aussi. Il y a des programmes qui sont chargés de communiquer avec le micrologiciel pour charger les mises à jour avant le démarrage du système d'exploitation (tel que fwupdate et fwup), et d'autres utilitaires peuvent aussi fonctionner avec.
D'autres distributions Linux (telles Red Hat, Fedora, SUSE, Ubuntu, etc…) ont fonctionnées un temps avec l'option Secure Boot, mais Debian mis plus de temps pour fonctionner avec. Cela signifie que sur chaque nouvel ordinateur, les utilisateurs ont dû en premier désactivé Secure Boot afin de pouvoir installer et utiliser Debian. Les méthodes pour y parvenir varient énormément d'un système à l'autre, ce qui rend la tâche potentiellement assez difficile pour les utilisateurs.
Depuis la version 10 ("Buster") de Debian, l'équipe Debian a inclut un Secure Boot fonctionnel pour rendre les choses plus pratiques.
Que n'est pas l'option SecureBoot d'UEFI ?
UEFI n'est pas une tentative de Microsoft pour empêcher Linux de démarrer sur les PC du marché ; Secure Boot est une mesure de sécurité pour se protéger contre les malwares au moment du démarrage du système. Microsoft agissant comme une Autorité de Certification pour Secure Boot, ils signeront des programmes au nom d'autres organisations de confiance afin que leurs programmes soient également exécutés. Il y a des prérequis d'identification pour les organisations, et le code sera audité par sûreté. Mais ce n'est pas un processus trop difficile à accomplir.
Secure Boot ne signifie pas aussi d'empêcher les utilisateurs à contrôler leurs propres systèmes. Les utilisateurs peuvent ajouter des clés supplémentaires dans le système, leur permettant de signer les programmes pour leur propre système. Beaucoup de systèmes ayant Secure Boot actif permettent aux utilisateurs de supprimer complètement les clés fournies par la plateforme, forçant le firmware à ne faire confiance qu'aux binaires signés par l'utilisateur.
Shim
shim est un paquet logiciel conçu pour fonctionner en première étape du chargeur de démarrage sur les systèmes UEFI.
Il a été développé par un groupe de développeurs Linux pour de nombreuses distributions, travaillant ensemble pour rendre Secure Boot fonctionnel entant que Logiciel Libre. C'est une pièce commune de code sûre, bien comprise et auditée qui peut être fiable et signé par la plateforme de clés. Cela signifie que Microsoft (ou tout autre Autorité de Certification de micrologiciel potentiel) n'a à s'inquiéter que de de la signature de shim, et non de tous les autres programmes que les vendeurs de distributions pourraient vouloir prendre en charge.
shim devient alors la racine de confiance pour tous les autres programmes UEFI fournis par les distributions. Il incorpore une autre clé d'Autorité de Certification spécifique à la distribution qui est elle-même utilisée pour signer d'autres programmes (e.g. Linux, GRUB, fwupdate). Cela permet une délégation de confiance sûre - les distributions sont ensuite responsables de la signature du reste de leurs paquets. shim lui-même ne devrait idéalement pas avoir besoin d'être mis à jour très souvent, ce qui réduit la charge de travail des équipes centrales d'audit et d'AC.
Pour plus de confiance et de sécurité, à partir de la version 15, la construction du binaire shim est 100 % reproductible - vous pouvez reconstruire vous-même le binaire shim Debian pour vérifier qu'aucun changement inattendu n'a été intégré à cette pièce maîtresse du logiciel de sécurité.
MOK - Clé Propriétaire de la Machine
Généralités
Un élément clé de la conception de shim est de permettre aux utilisateurs de contrôler leurs propres systèmes. La clé de l'Autorité de Certification de la distribution est intégrée au binaire shim lui-même, mais il existe également une base de données supplémentaire de clés qui peut être gérée par l'utilisateur, ladite clé du propriétaire de la machine (MOK est l'acronyme de Machine Owner Key).
Les clés peuvent ajoutées et supprimées dans la liste MOK par l'utilisateur, séparée entièrement de la clé de l'Autorité de Certification de la distribution. L'utilitaire mokutil peut être utilisé pour la gestion des clés depuis l'espace utilisateur sous Linux, mais changer les clés MOK peut seulement être confirmé directement depuis la console au moment du démarrage. Cela enlève le risque qu'un potentiel malware, en espace utilisateur, charge de nouvelles clés et essaye de contourner le propos de Secure Boot.
De multiples documentations en ligne sur comment fonctionner avec MOK existent, par exemple :
Est-ce que le système a démarré via SecureBoot ?
$ sudo mokutil --sb-state SecureBoot enabled
Notez que vous pouvez seulement être sûr que la réponse ci-dessus est correcte si votre système n'a pas été trafiqué en premier lieu.
Générer une nouvelle clé
Ubuntu place sa clé MOK dans /var/lib/shim-signed/mok/ et certains logiciels, tels que le paquet virtualbox d'Oracle s'attendent à ce que la clé soit à cet endroit, nous faisons de même (voir le bogue 989463 en tant que référence) et la plaçons au même endroit.
En premier, assurez vous que la clé n'existe pas déjà :
$ ls /var/lib/shim-signed/mok/
Si vous voyez ici la clé (qui consiste à un ensemble de fichiers nommés MOK.der, MOK.pem et MOK.priv) alors vous ne devriez pas avoir besoin de régénérer de clé.
Autrement, s'il n'y a pas de clé :
# mkdir -p /var/lib/shim-signed/mok/ # cd /var/lib/shim-signed/mok/ # openssl req -new -x509 -newkey rsa:2048 -keyout MOK.priv -outform DER -out MOK.der -days 36500 -subj "/CN=My Name/" # openssl x509 -inform der -in MOK.der -out MOK.pem
Notez que cela dépend de comment Debian implémentera la génération automatique de la clé (voir le bogue 989463), vous pourriez entrer en conflit avec l'installation automatique.
Enregistrement de la clé
Si vous avez un noyau à signer aussi, vous pourriez souhaiter faire cette étape en premier, ce qui vous évitera un redémarrage.
$ sudo mokutil --import MOK.der # invite pour un mot de passe unique $ sudo mokutil --list-new # revérifie que votre clé sera affichée lors du prochain démarrage <redémarrage de la machine puis entrée dans l'utilitaire de gestion de MOK : enregistrement de la clé MOK, continuer, confirmer, entrer le mot de passe, redémarrer> $ sudo dmesg | grep cert # pour vérifier que votre clé soit chargée
Définir les variables d'information du noyau Linux
$ VERSION="$(uname -r)" $ SHORT_VERSION="$(uname -r | cut -d . -f 1-2)" $ MODULES_DIR=/lib/modules/$VERSION $ KBUILD_DIR=/usr/lib/linux-kbuild-$SHORT_VERSION
Utiliser la clé dans le noyau Linux
En premier, installez le paquet sbsigntool.
$ sbsign --key MOK.priv --cert MOK.pem "/boot/vmlinuz-$VERSION" --output "/boot/vmlinuz-$VERSION.tmp" $ sudo mv "/boot/vmlinuz-$VERSION.tmp" "/boot/vmlinuz-$VERSION"
Utiliser la clé pour signer les modules
Produire et signer des modules est indépendant de créer et signer votre propre noyau. Vous pouvez parfaitement construire de nouveau modules pour un noyau Linux fourni par Debian. Mais si vous voulez les utiliser dans le système démarré par Secure Boot, vous avez alors besoin d'enregistrer votre clé tel que vu précédemment et vous aurez besoin de signer vos modules tel que montré ci-dessous.
L'exemple suivant montre comment signer les modules. Le paquet dkms de Debian dépose cela dans le sous-répertoire updates/dkms du répertoire des modules bien que le paquet VirtualBox d'Oracle les dépose dans le sous-répertoire misc, donc dirigez-vous dans le répertoire des modules relatif :
$ cd "$MODULES_DIR/updates/dkms" # pour les paquets dkms $ cd "$MODULES_DIR/misc" # pour les paquets d'Oracle
Enregistrez de manière sécurisé la phrase de passes pour la clé privée :
$ echo -n "Passphrase pour la clé privée : " $ read -s KBUILD_SIGN_PIN $ export KBUILD_SIGN_PIN
Signez simplement le module VirtualBox :
$ sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der vboxdrv.ko
ou, signez tous les modules du répertoire courant :
$ for i in *.ko ; do sudo --preserve-env=KBUILD_SIGN_PIN "$KBUILD_DIR"/scripts/sign-file sha256 /var/lib/shim-signed/mok/MOK.priv /var/lib/shim-signed/mok/MOK.der "$i" ; done
Vérifier si un module est signé
# modinfo vboxdrv filename: /lib/modules/5.10.0-9-amd64/misc/vboxdrv.ko version: 6.1.28 r147628 (0x00320000) license: GPL description: Oracle VM VirtualBox Support Driver author: Oracle Corporation srcversion: 282AFDD3CE09DCCD935FAF2 depends: retpoline: Y name: vboxdrv vermagic: 5.10.0-9-amd64 SMP mod_unload modversions sig_id: PKCS#7 signer: My Name sig_key: 13:FE:C2:ED:A1:40:CE:70:1A:75:91:E5:4C:1F:5F:DA:BD:17:57:A9 sig_hashalgo: sha256 signature: 0B:72:37:DD:10:97:F2:4F:DF:DF:52:27:38:88:63:7B:CC:2F:98:59: 66:70:D1:22:94:05:62:77:E9:04:35:B4:2D:9F:6F:92:18:D5:98:C3: [etc.]
Désactiver/Ré-activer Secure Boot
Dans le cas où il est difficile de contrôler l'état de Secure Boot au-travers du programme de démarrage d'UEFI, mokutil peut aussi être utilisé pour désactiver ou ré-activer Secure Boot pour les systèmes d'exploitations chargés par shim et GRUB :
Exécuter : mokutil --disable-validation ou mokutil --enable-validation.
- Choisisser un mot de passe entre 8 et 16 caractères de long. Confirmer-le.
- Redémarrer.
- À l'invite, appuyer sur une touche pour gérer MOK.
- Sélectionner "Change Secure Boot state".
Entrez chacun des caractères requis relatif au mot de passe afin de confirmer le changement. Notez que vous devez appuyer la touche <kbd>Entrée</kbd> après chaque caractère.
- Sélectionner "Yes".
- Sélectionner "Reboot".
Architectures et paquets pris en charge
Sur chaque architecture, Debian inclus de nombreux paquets contenant des binaires signés :
Name |
amd64 |
i386 |
arm64 |
Signé par |
But |
fwupd |
fwupd-amd64-signed |
fwupd-i386-signed |
fwupd-arm64-signed |
Debian |
Outils pour gérer automatiquement les mises à jour du micrologiciel UEFI |
fwupdate |
fwupdate-amd64-signed |
fwupdate-i386-signed |
fwupdate-arm64-signed |
Debian |
Outils pour gérer manuellement les mises à jour du micrologiciel UEFI (supprimé en faveur de fwupd après Buster) |
grub |
grub-efi-amd64-signed |
grub-efi-ia32-signed |
grub-efi-arm64-signed |
Debian |
Chargeur de démarrage GRUB |
linux |
linux-image-*-amd64 (*) |
linux-image-*-686* (*) |
linux-image-*-arm64 (*) |
Debian |
Les différentes saveurs du noyau Linux |
shim |
shim-signed |
shim-signed |
shim-signed |
Microsoft |
Le binaire shim lui-même |
shim-helpers |
shim-helpers-amd64-signed |
shim-helpers-i386-signed |
shim-helpers-arm64-signed |
Debian |
(*) Les nombreux paquets linux-image dans Debian sont maintenant signés par défaut. Les paquets non signés sont appelés linux-image-*-unsigned.
Tester Secure Boot UEFI
Concentré sur Debian Buster, certains tests ont été assumés afin de s'assurer que tout était prêt. Vous pouvez aider en testant notre processus de démarrage sur du vrai matériel, incluant l'installateur et les images live. Si vous voulez aider à tester Secure Boot, vous pouvez trouver plus d'informations ici.
Limites de Secure Boot
De par sa conception, Secure Boot peut affecter ou limiter certaines actions que les utilisateurs souhaitent faire.
Si vous voulez construire et exécuter votre propre noyau (e.g. pour le développement ou le débogage), alors vous finirez évidemment par créer des binaires qui ne sont pas signés avec la clé Debian. Si vous souhaitez utiliser ces binaires, vous aurez soit besoin de les signer par vous-même et d'enregistrer la clé utilisé avec MOK, soit de désactiver Secure Boot.
Utiliser Secure Boot active le mode "lockdown" dans le noyau Linux. Cela désactive nombreuses fonctionnalités qui peuvent être utilisées pour modifier le noyau :
Charger des modules du noyau qui ne sont pas signés par une clé de confiance. Par défaut, cela verrouillera les modules hors de l'arborescence, incluant les pilotes gérés par DKMS. Toutefois, vous pouvez créer votre propre clé de signature pour les modules et ajouter son certificat à la liste de confiance utilisée par MOK.
- Utiliser kexec pour démarrer un image de noyau non signée.
- Hiberner et sortir de l'hibernation.
- L'accès à la mémoire physique et aux ports d'Entrées/Sorties dans l'espace utilisateur.
- Les paramètres de module qui permettent la configuration de la mémoire et des adresses des ports d'Entrées/Sorties.
L'écriture vers MSR au-travers du périphérique spécial /dev/cpu/*/msr.
- L'utilisation de méthodes et de tables ACPI personnalisées.
- L'injection d'erreur ACPI APEI.
Vous pouvez éviter cela en désactivant Secure Boot dans le programme de démarrage UEFI ou par MOK.
Exemples de documentation ailleurs (en anglais) :
Infrastructure - Comment cela fonctionne dans Debian
Si vous voulez savoir comment implémenter les détails et suivre les discussions actuelles sur les améliorations, lisez la page SecureBoot/Discussion.
Tester Secure Boot dans une machine virtuelle
Si vous voulez tester Secure Boot dans une machine virtuelle sans avoir à marchander avec la machine courante, lisez la page SecureBoot/VirtualMachine.
Problèmes avec l'architecture arm64
Debian ne prend plus à charge Secure Boot sur les systèmes arm64, depuis Mai 2021.
shim et les autres programmes EFI ont toujours eu des difficultés à se construire sur arm64, comparé aux plateformes x86. Binutils pour amd64 et i386 incluent la prise en charge explicite pour créer des programmes au format binaire PE/COFF qu'utilise EFI, mais qui n'a jamais été ajouté pour arm64.
Dans le passé, les développeurs de shim ont ajoutés certains hacks locaux dans le paquet de shim pour générer un binaire la plupart du temps conforme PE/COFF EFI sans la prise en charge de toolchain. Tout semblait fonctionner. Toutefois, durant le développement et la phase de test de shim 15.3 et 15.4, nous avons eu des problèmes significatifs avec cette approche. De nouvelles fonctionnalités de sécurité nécessaires dans shim (SBAT) ont rencontrées des problèmes sérieux avec la prise en charge imparfaite de toolchain. Lire https://github.com/rhboot/shim/issues/366 pour avoir plus de détails. Les vieux hacks autour de binutils ne sont plus viables.
Les statistiques nous ont montré que très peu de personnes ont essayé d'utiliser Secure Boot avec arm64. Dans l'intérêt de publier les mises à jour nécessaires de manière opportune, nous avons décidé pour le moment de désactiver le support des shim signés pour Debian arm64.
Nous espérons ré-introduire la prise en charge de Secure Boot sur arm64 aussi vite que possible dans le futur.
La version 2.38 de binutils introduit la prise en charge de la génération de binaires conforme PE/COFF sur arm64, ainsi il devrait être maintenant possible de résoudre cette situation.