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

45

Lors de l’installation de 16.04 , on m'a demandé de désactiver " Secure Boot " si je souhaitais installer modules / pilotes tiers .

Je ne me suis pas conformé.

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

L'utilisation de bcmwl-kernel-source était parfaitement adaptée à Secure Boot dans 15.10 . Cela ne semble pas être lié à un bug pour moi.

Cela ressemble donc à Ubuntu qui refuse de signer les pilotes / modules tiers pour le faire fonctionner (??) avec "Secure Boot". Ou semble-t-il considérer les modules tiers comme non sécurisés et briser le "Secure Boot" et donc le désactiver pour le rendre clair? Ai-je raison?

    
posée solsTiCe 08.04.2016 - 16:52
la source

4 réponses

37

Ce n’est pas un bogue, c’est une fonctionnalité.

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

Cependant, vous pouvez certainement utiliser Secure Boot, mais c'est exactement le cas d'utilisation où Secure Boot tente de vous protéger de vous-même, car il ne sait pas si vous faites confiance à un module ou pas.

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

GRUB, ou shim, ou d’autres mécanismes de démarrage peuvent être signés numériquement par une clé KEK approuvée par l’autorité de certification racine (PK) et, par conséquent, votre ordinateur peut sans configuration démarrer Ubuntu Live USB / DVD.

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

Certaines personnes protestent contre cela, mais il n’ya pas vraiment de meilleure solution (du point de vue de la sécurité) que d’enregistrer vous-même la nouvelle clé que vous souhaitez.

Si votre système d’amorçage utilise shim, vous pouvez utiliser une base de données de propriétaire de machine, et inscrire votre clé en tant que MOK (vous pouvez le faire avec mokutil). Si vous ne le faites pas, vous pouvez également inscrire votre clé dans la base de données UEFI en tant que clé de signature.

Après avoir inscrit votre clé, vous pouvez signer votre package DKMS avec votre MOK (il doit y avoir un script perl à /usr/src/kernels/$(uname -r)/scripts/sign-file ) et après sa signature, vous peut le charger dans le noyau .

Certes, quelqu'un devrait faire plus d'instructions visuelles à ce sujet, et probablement même faire un assistant ou un meilleur standard DKMS pour permettre la prise en compte des clés, mais c'est ce que nous avons maintenant.

    
réponse donnée ssice 11.07.2016 - 18:00
la source
20

En bref, ce n’est pas un bug mais un nouveau changement introduit en 16.04.

Parce que ce que vous installez est un package 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 est impossible de le vérifier numériquement. Si le démarrage sécurisé est activé, cela signifie que votre module ne peut pas être utilisé, et pour l'utiliser, vous devrez désactiver le démarrage sécurisé, ce qui explique pourquoi la question vous est posée.

Pour quelle raison cela ne se produit qu’en 16.04 mais pas dans les versions précédentes, Rod Smith a donné une bonne réponse. Dans Ubuntu 16.04, Ubuntu commence à appliquer un démarrage sécurisé au niveau du noyau. Avant 16.04, Ubuntu ne vous oblige pas vraiment à utiliser le noyau signé et les modules du noyau signés, même si le démarrage sécurisé est activé. Mais ce n'est plus le cas en 16.04.

Ceci est le bogue associé: lien

Ceci est le modèle associé: lien

    
réponse donnée Anthony Wong 21.04.2016 - 11:09
la source
6

Une autre façon de le faire est de créer votre propre clé, d’insérer la partie publique dans la base de données MOK et de signer les modules que vous compilez avec la partie privée. Regardez ici pour les informations détaillées: Impossible de charger 'vboxdrv' après la mise à niveau vers Ubuntu 16.04 (et je veux conserver un démarrage sécurisé)

    
réponse donnée user261814 21.06.2016 - 02:58
la source
0

La réponse acceptée est très complète, mais je voudrais ajouter cette information simple, prise ici:

lien

Un démarrage sécurisé peut vous empêcher de charger un pilote installé, ce qui peut être très frustrant. Je suis passé par là: le pilote a été installé correctement, tout semblait aller bien, mais ça ne fonctionnait pas. Il m'a fallu du temps pour trouver que boot sécurisé empêchait le système d'exploitation de le charger.

    
réponse donnée Dhiego Magalhães 05.08.2017 - 21:46
la source

Lire d'autres questions sur les étiquettes