48 votes

Pourquoi la désactivation de "Secure Boot" est une politique appliquée lors de l'installation de modules tiers ?

Lors de l'installation 16.04 On m'a demandé d'éteindre " Amorçage sécurisé "si je voulais installer Modules/pilotes tiers .

Je n'ai pas obtempéré.

Et lorsque j'ai installé manuellement les seuls pilotes tiers que j'utilise ( bcmwl-kernel-source ), on m'a de nouveau demandé (pendant l'installation du paquet) de désactiver le "Secure Boot".

Utilisation bcmwl-kernel-source était parfaitement d'accord avec Amorçage sécurisé en 15.10 . Cela ne me semble pas lié à un bogue.

Il semble donc qu'Ubuntu refuse de signer les pilotes/modules de tierces parties pour que cela fonctionne ( ??) avec le "Secure Boot". Ou semble considérer les modules tiers comme non sécurisés et cassant le "Secure Boot" d'où l'obligation de les désactiver pour que ce soit clair ( ?). Ai-je raison ?

43voto

IronWaffleMan Points 645

Il ne s'agit pas d'un bogue, mais d'une fonctionnalité.

Comme le dit Anthony Wong, lorsque vous installez un paquet DKMS, vous compilez le paquet vous-même, Canonical ne peut donc pas signer le module pour vous.

Cependant, vous pouvez tout à fait utiliser Secure Boot, mais c'est exactement le cas d'utilisation où Secure Boot essaie de vous protéger de vous-même parce qu'il ne peut pas savoir si vous faites confiance à un module ou non.

Par défaut Il existe une clé de plate-forme (PK) sur votre machine UEFI, qui est l'autorité de certification de confiance ultime pour le chargement du code dans votre processeur.

Grub, ou shim, ou autre les mécanismes de démarrage peuvent être signés numériquement par un KEK auquel l'autorité de certification racine (PK) fait confiance, et votre ordinateur peut ainsi, sans aucune configuration, démarrer des logiciels tels que les USB/DVD Ubuntu Live.

Sur Ubuntu 16.04, le noyau est construit avec CONFIG_MODULE_SIG_FORCE=1, ce qui signifie que le noyau imposera que les modules soient signés par une clé de confiance dans la plate-forme. Tenez compte du fait que la plateforme UEFI contient par défaut une clé PK sur laquelle vous n'avez aucun contrôle, et que vous ne pouvez donc pas signer les binaires avec une clé reconnue par votre propre machine.

Certaines personnes s'en plaignent, mais il n'y a pas de meilleur moyen (du point de vue de la sécurité) que d'enregistrer soi-même la nouvelle clé que l'on veut.

Si votre système de démarrage utilise shim, vous pouvez utiliser une base de données appelée Machine Owner's Key (clé du propriétaire de la machine), et inscrire votre clé en tant que MOK (Vous pouvez le faire avec mokutil). Si ce n'est pas le cas, vous pouvez également enregistrer votre clé dans la base de données UEFI comme clé de signature.

Après avoir enregistré votre clé, vous pouvez signer votre paquet construit par DKMS avec votre MOK (il devrait y avoir un script perl à /usr/src/kernels/$(uname -r)/scripts/sign-file ), y une fois qu'il est signé, vous pouvez le charger dans le noyau .

Il est vrai que quelqu'un devrait fournir des instructions plus visuelles à ce sujet, et probablement même créer un assistant ou une meilleure norme DKMS pour permettre la prise en compte des clés, mais c'est ce que nous avons pour l'instant.

Vous pouvez vous référer à cette explication sur la façon de signer vos propres modules de noyau : https://askubuntu.com/a/768310/12049

20voto

Anthony Wong Points 815

En résumé, il ne s'agit pas d'un bogue mais d'une nouvelle modification introduite dans la version 16.04.

Parce que ce que vous installez est un paquet dkms. Les modules DKMS sont compilés sur votre propre machine et Canonical ne peut donc pas signer le module pour vous. Si Canonical ne peut pas le signer, il n'y a aucun moyen de le vérifier numériquement. Si le boot sécurisé est activé, votre module ne pourra pas être utilisé, et pour l'utiliser, vous devrez désactiver le boot sécurisé, c'est pourquoi la question vous est posée.

Rod Smith a donné une bonne réponse à la question de savoir pourquoi cela ne se produit qu'avec la version 16.04 et pas avec les versions précédentes. Dans Ubuntu 16.04, Ubuntu commence à appliquer le démarrage sécurisé au niveau du noyau. Avant la version 16.04, Ubuntu ne vous obligeait pas vraiment à utiliser un noyau et des modules de noyau signés, même si le démarrage sécurisé était activé. Mais ce n'est plus le cas en 16.04.

Il s'agit du bogue en question : https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1401532

Il s'agit du schéma directeur correspondant : https://blueprints.launchpad.net/ubuntu/+spec/foundations-x-installing-unsigned-secureboot

6voto

user261814 Points 1

Une autre façon de procéder consiste à créer votre propre clé, à insérer la partie publique dans la base de données MOK et à signer les modules que vous compilez avec la partie privée. Vous trouverez ici des informations détaillées à ce sujet : Impossible de charger 'vboxdrv' après la mise à jour vers Ubuntu 16.04 (et je veux conserver le démarrage sécurisé)

1voto

La réponse acceptée est très complète, mais j'aimerais ajouter cette simple information, tirée d'ici :

https://askubuntu.com/a/843678/664391

En fait, le démarrage sécurisé peut vous empêcher de charger un pilote que vous avez installé, ce qui peut être assez frustrant. Je suis moi-même passé par là : le pilote s'est installé correctement, tout semblait en ordre de marche, mais cela n'a pas fonctionné. Il m'a fallu un certain temps pour découvrir que c'était démarrage sécurisé empêche le système d'exploitation de le charger.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X