Secure Boot

[JeanP]

Bonjour,

est-il possible de rassembler conseils et infos sur ce sujet ?
questions :
- utilité de secure boot pour une utilisation linux mode client (mode utilisateur lambda)
- tenter d'identifier si des régressions se présentent :
j'ai une clé MINT 21.2 qui permet d'installer un système avec SB actrivé, puis de passer à MINT 21.3 sans problème, mais des messages indiquent que l'installation MINT 21.3 n'est pas compatible SB
- comment installer les clés requises si elles ne sont pas présentes ? est-ce nécessaire ?
Il y a d'autres questions autour de ce sujet, sans doute.

Parmi les difficultés et points d'étonnement :
sur un portable DELL, MINT21.3 fonctionne avec SB actif, mais LMDE6 (version debian de MINT) ne fonctionne que si SB est désactivé.
sur un portable SONY, MINT21.3 fonctionne également, mais sans SB (le bios ne semble pas le proposer) et impossible d'installer debian ni LMDE6

Merci de réagir..

[Glenic]

Hello,
Je réponds sur le sujet très tardivement mais mes visites sur le forum sont rares actuellement.
En bref, j'ai un HP Probook 650 qui date de 2018 (environ)
Cette machine tourne avec Fedora 40.
Le Secure Boot (SB) activé dans l'UEFI empêchait l'utilisation normale de la carte WiFi.
Ayant désactivé le SB, tout fonctionne normalement, en particulier le WiFi.
Le problème vient d'une signature non approuvée par le SB pour le logiciel propriétaire qui fait fonctionner la carte WiFi Broadcom.
Ce problème n'existe pas sous Windows (évidemment !) mais apparaît avec un OS Linux.
Le défaut est parait-il surmontable par une manipulation faisant apparaître une quasi-signature approuvée par le SB.
ça reste assez mystérieux pour moi. C'est pourquoi j'ai désactivé le SB dans l'UEFI de l'ordinateur et depuis cet ordinateur fonctionne sans SB.
Ce n'est pas recommandé si un logiciel malveillant se présente discrètement à l'installation, mais c'est le seul moyen que j'ai trouvé pour éviter le recours à un Dongle WiFi (risque de perte de ce petit accessoire, neutralisation permanente d'une prise USB...)

[Stéphane Ascoët]

Dommage que Max ne participe plus, c'était lui le spécialiste sur ce genre de sujet

[maxoxo]

Coucou !

Dommage que Max ne participe plus, c'était lui le spécialiste sur ce genre de sujet

Je profite de quelques jours de congé pour repasser sur le forum. Désolé d'avoir disparu, un taf avec bcp de responsabilités, un petit de 2 ans et malheureusement quelques événements familiaux difficiles à traverser m'ont un peu éloigné du forum. J'ai quand même dépanné sur Signal

utilité de secure boot pour une utilisation linux mode client (mode utilisateur lambda)

Je dirais que ça dépend vraiment de ton modèle de menaces et d'exposition aux risques. Aujourd'hui, l'utilité du SB ne fait plus trop de débat même dans le monde Linux. Il y a même un consensus des principales distributions pour le faire fonctionner nativement et développer une prise en charge universelle. C'est le cas sur Fedora, Ubuntu et même Debian qui utilisent un préchargeur (shim) signé avec l'autorité de certification Microsoft (qui est reconnue nativement par toutes les machines car implantée dans l'UEFI en usine). Cela facilite grandement l'adoption du SB.

Sur ces distributions ça fonctionne normalement out of the box sans aucune manipulation. Dans ces conditions, si tout va bien, pourquoi s'en priver ? Ça apporte quand même une couche de sécurité supplémentaire non négligeable.

La difficulté, c'est effectivement si tu te retrouves dans une situation où certaines choses fonctionnent mal. Par exemple, le cas évoqué par Glenic qui est lié à la nécessité de devoir utiliser un pilote propriétaire de Broadcom pour le WiFi. Or ce pilote n'est pas signé, le secure boot empêche donc de le charger avec le noyau Linux puisque du coup il considère qu'on porte atteinte à l'intégrité du noyau et de la chaîne d'amorçage du système. Il faudrait donc pouvoir le signer à la main (à refaire après chaque màj du noyau) et la manip n'est pas évidente.

Si tu es dans une telle situation, une évaluation bénéfices/contraintes devient nécessaire. Pour un particulier et un usage classique, je serai assez d'accord de dire qu'ici, le bénéfice en sécurité du SB doit s'incliner face au désagrément de ne plus avoir de WiFi.

Pour faire cet arbitrage, il faut partir d'une explication sur comment fonctionne SB et de quoi il protège :

Le Secure Boot établit une chaîne de confiance qui va de l'UEFI (le nouveau BIOS) jusqu'au noyau linux qui va être amorcé:

1. L'UEFI vérifie la signature du "shim"
2. Le "shim" vérifie la signature de GRUB
3. GRUB vérifie la signature du noyau Linux
4. Le noyau vérifie la signature des modules chargés

Le SB va donc te protéger contre des attaques qui visent à modifier de façon non autorisée le chargeur d'amorçage, le noyau et plus largement le système d'exploitation à démarrer. Principalement, il garantit donc l'intégrité du système en évitant qu'on puisse modifier le noyau ou l'image de démarrage en exécutant du code et des pilotes malveillants. Le SB limite donc considérablement les risques qu'un programme malveillant garde une persistance sur ton système ou parvienne à charger un composant système malveillant. Sans le SB, la chaîne de démarrage n'est pas protégée, il n'y a aucun mécanisme de vérification de ce qui est démarré, donc un OS corrompu ou noyau modifié pour exécuter du code malveillant passera inaperçu et sera démarré quand même.

Maintenant la question c'est as-tu des risques dans ton utilisation d'être confronté à ce type d'attaque ?

Tout d'abord, le SB empêche surtout des attaques de type Evil Maid qui supposent donc un accès physique à la machine. Ça voudrait donc dire que tu es une cible à risque pour quelqu'un ait envie de voler ta machine et tenter d'accéder aux données. Pour les attaquants aussi il faut que le jeu en vaille la chandelle.

Ensuite, tu pourrais être la cible d'une attaque à distance parce que tu es tombé dans un piège sur Internet ou que tu as exécuté du code malveillant sans le savoir. Le SB limite les risques de ce type d'attaque mais ne les fait pas disparaître. En revanche, l'avantage que le SB soit activé c'est qu'au reboot : ça sera terminé car le code qui n'est pas d'origine sera bloqué en exécution. Pour un particulier sous Linux qui s'en tient à du web et aux paquets venant des sources officielles, le risque est donc plutôt limité.

On en revient donc au modèle de menaces et l'analyse du risques. Dans un contexte pro (c'est le cas dans mon boulot), je considère que le risque n'est pas acceptable surtout que l'effort pour l'amoindrir est gérable. Un collaborateur pourrait effectivement oublier son PC pro dans un train ou autre, un développeur pourrait se retrouver avec des librairies vérolées, une faille pourrait être exploitée sur un de nos serveurs pour tenter d'installer un programme permettant de gagner un accès distant dès le démarrage. Dans un contexte plus individuel et personnel, ces risques n'existent pas ou deviennent acceptables.

tenter d'identifier si des régressions se présentent :
j'ai une clé MINT 21.2 qui permet d'installer un système avec SB actrivé, puis de passer à MINT 21.3 sans problème, mais des messages indiquent que l'installation MINT 21.3 n'est pas compatible SB
- comment installer les clés requises si elles ne sont pas présentes ? est-ce nécessaire ?
Il y a d'autres questions autour de ce sujet, sans doute.

Parmi les difficultés et points d'étonnement :
sur un portable DELL, MINT21.3 fonctionne avec SB actif, mais LMDE6 (version debian de MINT) ne fonctionne que si SB est désactivé.
sur un portable SONY, MINT21.3 fonctionne également, mais sans SB (le bios ne semble pas le proposer) et impossible d'installer debian ni LMDE6

Là tu pointes un problème spécifique à Mint que je n'ai jamais su trop comprendre alors que Debian/Ubuntu qui servent de base à Mint supportaient très bien le SB de leur côté. En effet chez Mint, il y a une sorte d'inconsistance dans la prise en charge du SB.

Ça ne fonctionnait pas pendant des années. Puis à un moment ça fonctionnait impeccable en 20.3, mais ça ne fonctionnait plus en 21. Normalement depuis la 21.3 et LMDE 6 c'est censé fonctionner nativement sans problèmes. J'ai fait une installation en 22 hier sur le PC d'un ami et ça fonctionne très bien. Il y a même un outil bien intégré pour gérer la signature des pilotes tiers c'est propre

[Glenic1]

@Maxoxo : on dirait que les limitations dans les posts qui t'étaient tombées dessus il y a quelques mois ont disparu.

Et c'est tant mieux car ton post d'hier apporte des réponses aux questions posées.
Et de plus grâce à toi la culture micro-informatique est augmentée pour les utilisateurs du forum qui débutent dans ce domaine (c'est mon cas).

Merci pour cette intervention. Elle reste consultable facilement grâce à notre forum.

[Glenic1]

..............J'ai fait une installation en [LinuxMint] 22 hier sur le PC d'un ami et ça fonctionne très bien. Il y a même un outil bien intégré pour gérer la signature des pilotes tiers c'est propre

Diable ! Cet outil de signature des pilotes tiers existe sur LM 22 et pas sur Fedora 40 ?
C'est un coup à me faire abandonner Fedora pour passer à LM 22 !

[maxoxo]

Diable ! Cet outil de signature des pilotes tiers existe sur LM 22 et pas sur Fedora 40 ?
C'est un coup à me faire abandonner Fedora pour passer à LM 22 !

L'outil vient d'Ubuntu je pense et n'est pas propre à Mint et sous Fedora il existe aussi !

Dans les deux cas, il faudra resigner à la main après chaque mise à jour du noyau en enrôlant une MOK (Machine Owner Key).

Comme ton module Broadcom est installé sous la forme "akmod" sur ta Fedora ça devrait rester simple. Il y a un tuto bien fait ici : https://www.linuxtricks.fr/wiki/fedora- ... ecure-boot

[JeanP]

Merci Glenic pour ta réponse détaillée et très complète. Je ne suis pas passé par ici depuis un moment, mais ces questions restent d'actualité, et peuvent concerner tout ceux qui installent des distributions linux.

[JeanP]

Une question additionnelle me taraude brutalement les méninges. Comment SB est-il compatible avec du multiboot ? Est-ce possible ? Si la protection doit s'étendre au noyau, et si des distributions différentes utilisent des noyaux linux différents, est-ce que les signatures peuvent être compatibles ????

[maxoxo]

Une question additionnelle me taraude brutalement les méninges. Comment SB est-il compatible avec du multiboot ? Est-ce possible ? Si la protection doit s'étendre au noyau, et si des distributions différentes utilisent des noyaux linux différents, est-ce que les signatures peuvent être compatibles ????

Bonjour,

J'espère que je vais pouvoir stopper autant de brutalité alors

Il est tout à fait possible d'avoir le SB activé et plusieurs distributions installées sur la même machine. Il y a plusieurs pistes pour faire ça plus ou moins facilement. Je vais essayer de vulgariser en prenant des gros raccourcis.

Comment ça marche en fait ?

Le SB repose sur une infrastructure à clé publique (PKI) directement intégrée dans l'UEFI de la machine. Comme toute opération de chiffrement asymétrique, il faut donc une clé publique et une clé privée qui vont ensemble. Évidemment si tout le monde pouvait enregistrer sa clé publique dans l'UEFI et utiliser sa clé privée pour signer les bootloader et les noyaux, le système n'aurait aucune plus-value de sécurité.

Il faut donc un tiers de confiance, une autorité certification (CA). Un truc classique dans toute PKI qui se respecte. C'est exactement comme quand tu navigues sur le web avec les certificats TLS pour le HTTPS. Si n'importe qui peut utiliser un certificat de n'importe où : on ne peut pas avoir confiance. La confiance repose donc sur le fait qu'une CA reconnue par le système valide le certificat en question.

En l'occurrence ici, il faut que cette CA soit implantée dans l'UEFI de la machine. La seule dont on dispose à l'heure actuelle c'est celle de Microsoft qui permet gracieusement aux distributions Linux de l'utiliser afin de pouvoir supporter nativement le SB. Sans ça, il faudrait que l'utilisateur génère lui-même des clés, les implémente dans l'UEFI puis signe lui-même chaque composant de la chaîne de démarrage de la distribution (GRUB, noyau + modules qui doivent être signés à chaque màj ou lors de la compilation).

Du coup la solution pour le multiboot

Du coup, pour que pouvoir lancer un chargeur d'amorçage comme GRUB avec le SB activé, il faut utiliser une version modifiée qui sera reconnue par la CA de Microsoft. C'est ce que l'on appelle un Shim. Ici, ça sera donc le fichier shimx64.efi situé sur la partition EFI (esp).

Ce shim est propre à chaque distribution, il est signé avec la clé publique de la distribution qu'il va donc pouvoir charger dans la liste autorisée par l'UEFI. Cela permet de démarrer GRUB puis le noyau linux signé avec la clé privée de la distribution.

Du coup, là où c'est compliqué, c'est qu'à partir du shim signé pour Ubuntu, tu ne peux pas démarrer une autre distribution puisque tu n'auras pas les bonnes signatures.

Le shim est installé au chemin suivant /boot/efi/EFI/ubuntu/shimx64.efi. Si tu installes Fedora tu auras à côté un /boot/efi/EFI/fedora/shimx64.efi. De la même façon qu'on trouve "Windows Boot Manager" au chemin /boot/efi/EFI/Microsoft/

La solution repose donc sur la technique du "chainloading" qu'on pourrait appeler l'amorçage en chaîne : https://www.gnu.org/software/grub/manua ... ading.html

Concrètement ? Contrairement à une installation classique en multiboot où tu as le même GRUB pour toutes les distributions installées et tu peux booter direct n'importe quelle distribution. Là tu auras plusieurs GRUB avec chacun la bonne signature propre à chaque distribution. En gros, depuis le premier shim signé pour ta distribution, tu dois chainloadé le second shim qui correspond à l'autre distribution afin d'avoir un GRUB qui amorcera le noyau signé avec la bonne clé.

Du coup il faut souvent éditer la configuration du premier GRUB pour qu'il fasse bien le chainloading vers le bon shim si on veut démarrer une autre distribution. C'est pas toujours bien automatisé (le réflexe naturel de GRUB c'est de démarrer un noyau s'il le trouve, pas un shim).

On se retrouve finalement avec une installation multiboot semblable au partage entre Windows et Linux. Quand on démarre Windows depuis GRUB on fait du chainloading vers "Windows Boot Manager". Le chargeur d'amorçage de Windows car GRUB est incapable en soit de lancer directement Windows. C'est du chacun chez soi

Le schéma c'est donc l'UEFI SB fait confiance au shim signé avec une clé Microsoft, ce shim charge la clé publique de la distribution et permet donc de lancer GRUB et le noyau qui sont signés avec la clé privée de la distribution concernée. On a un mécanisme signature cohérent d'un bout à l'autre de la chaîne d'amorçage.

L'autre technique

Si tu veux pas jouer avec la conf de GRUB. Tu installes toutes tes distributions et tu appuies sur F12 ou F8 à l'allumage du PC, selon la touche définie pour avoir le "boot menu" de ton UEFI et là tu peux choisir directement le bon shim à démarrer.

Ça fonctionne très bien comme ça c'est moins pratique surtout si l'entrée est mal nommée tu peux avoir deux fois "Linux Boot Manager" par exemple.

Ubuntu et Fedora font l'effort de bien nommer la leur qui s'appellent sobrement "ubuntu" ou "Fedora". Une fois l'OS démarré, tu peux voir tout ça avec la commande efibootmgr.

https://www.malekal.com/efibootmgr-ajou ... _demarrage

-----

Je ne sais pas si j'ai bien expliqué, n'hésite pas si ce n'est pas clair