[RESOLU] Installation de Linux Mint 21 sous UEFI (avec un ordi HP)

[PerJean]

Je suis incapable de dire si Secure Boot est toujours actif ou pas ! par quel moyen peut-on vérifier son état (actif ou mort) ?

Tu vas dans le bios et tu regardes si secure boot est sur "enabled" ou "disabled"

pou le reste super que tu sois parvenu à tes fins.
bonne soirée

[maxoxo]

Hello !

Super que ça fonctionne enfin ! Bravo

Je suis incapable de dire si Secure Boot est toujours actif ou pas ! par quel moyen peut-on vérifier son état (actif ou mort) ?

Tu peux vérifier directement à partir de Linux Mint avec la commande suivante :

Code : Tout sélectionner

$ sudo mokutil --sb-state

Il te répondra "SecureBoot enabled" ou "Secureboot disabled" selon le cas.

J'en profite pour signaler que tu peux aussi vérifier que tu es bien en UEFI avec la commande

Code : Tout sélectionner

ls /sys/firmware/efi/

Si ça n'existe pas, alors tu as démarré ton système en mode BIOS à l'ancienne (de moins en moins possible, ça a disparu sur beaucoup de machines récentes).

[maxoxo]

J'ajoute un autre message pour apporter quelques compléments

À la place de Glenic, je retenterai l'installation en désactivant le secure boot.
Pas convaincu que le risque soit important sans cela, mais bon !

Je comprends tout à fait ton interrogation PerJean et aux débuts d'UEFI / Secure Boot (SB) en 2012/2013 j'enrageais moi aussi contre Microsoft et ce mécanisme de sécurité qui à l'époque rendait l'installation de Linux très très difficile pour ne pas dire impossible sur certains constructeurs qui ne jouaient pas le jeu. Mais la donne a changée et l'implémentation s'est améliorée. Aujourd'hui, toutes les distributions sérieuses le supportent nativement que ce soit Debian, Ubuntu, Fedora (et donc leurs dérivés). Tu pourras d'ailleurs voir que Debian tient un discours positif sur SB dans sa documentation : https://wiki.debian.org/SecureBoot#What ... oot_NOT.3F

Linus Torvalds lui-même, autrefois vent debout contre le SB a changé de position et accepté l'introduction de protections supplémentaires dans le noyau qui nécessitent SB comme "lockdown" : https://www.lemondeinformatique.fr/actu ... 76603.html

Maintenant sur le "risque" c'est difficile de répondre car dans un cas d'utilisation personnelle avec des utilisateurs avertis comme vous l'êtes avec Glenic, on peut effectivement estimer que le risque est moins important que sur des systèmes professionnels exposés ou avec une grande hétérogénéité d'utilisateurs. Le SB permet de se protéger d'une attaque sur la chaîne de démarrage. Le SB n'autorisera le démarrage que des OS qu'il considère comme "certifié" pour lui. Ça va même plus loin car il n'autorisera pas un OS dont l'intégrité a été compromise à démarrer

Exemples (non exhaustifs) :
- Ton Linux Mint bien installé avec Secure Boot est compromis en cours d'utilisation, le pirate cherche à rendre persistantes les modifications pour garder le contrôle et bien au prochain reboot, Secure Boot interdira le démarrage des modules infectés car ils ne sont pas signés correctement. Il empêche donc une menace de rester persistante. Avec lockdown que j'évoquais au-dessus on peut même empêcher cette attaque en live (sans SB c'est impossible).
- Tu oublies ta machine quelque part, tu te dis "c'est bon je suis protégé car ma partition est chiffrée", oui mais si on peut démarrer n'importe quel OS modifié, si on peut modifier ton grub, si on peut lancer un firmware EFI non signé/autorisé on peut faire une attaque cold boot et tenter de casser le chiffrement LUKS. SB va limiter ce risque fortement.

C'est la raison pour laquelle, je recommanderai toujours d'installer les distributions avec SB activé d'autant que maintenant c'est très bien supporté. Sauf vraies difficultés de fonctionnement, la balance bénéfices/problèmes penche clairement en faveur du SB à mon sens.

Traduction en français : "le changement suivant de configuration est requis sur le TPM (Trusted Platform Modul) de cet ordinateur : effacer le TPM.
Un seul choix est possible : accepter en pressant la touche F1.
Il semble que le TPM soit le module qui garantit la fiabilité de l'OS qui va être lancé sur l'ordi (que ce soit Windows ou une autre, s'il est qualifié correct par Microsoft et par HP) ??? S'agirait-il du mécanisme qui actionne le Secure Boot ?? Le TPM a-t-il un rapport avec l'UEFI ? Mystère !
Aucune autre touche que F 1 n'est active. Donc, en avant pour F 1 et la remise à zéro du TPM !

Le TPM est une puce de sécurité embarquée sur ta carte mère (voire dans le processeur lui-même) qui a vocation à gérer de façon sécurisée le stockage des "secrets" (mots de passe, clés de chiffrement, empreintes etc). En gros, elle facilite la mise en oeuvre de mesures de sécurité pour l'utilisateur, car elle lui permet de ne jamais connaître les véritables clés de chiffrement ou de déchiffrement. Elle permet en revanche une dérivation via un secret connu par l'utilisateur (mot de passe de session, empreinte digitale) etc. Ainsi en de hors de la machine, chaque élément secret va pouvoir sa propre clé de chiffrement très longue. Le TPM assurera le chiffrement et le déchiffrement à la volée.

Par exemple sur smartphone, depuis Android 10, on a un chiffrement de niveau fichier (chaque fichier à sa propre clé) et c'est donc le TPM qui assure à la volée chiffrement/déchiffrement. Quand tu tapes ton code de verrouillage ou que tu mets ton empreinte (selon ce que tu as mis). Le TPM reçoit l'ordre de libérer la clé de chiffrement qui va bien. Mais si quelqu'un vole ton téléphone et démonte physiquement le stockage, il devra pour déchiffrer les fichiers essayer de casser une clé super longue. Chaque fichier ayant sa propre clé stockée dans le TPM, c'est pas loin d'être mission impossible.

Exactement la même chose sur PC avec le chiffrement du disque dur. Pas encore sous Linux, mais avec Bitlocker sous Windows, l'utilisateur connaît uniquement son mdp de session ou son empreinte digitale, mais pas la clé réelle de déchiffrement du disque dur. Sur une machine avec Secure Boot activé, il sera donc quasiment impossible d'accéder aux données sans l'accord du propriétaire légitime (sauf à ce qu'il ait un mdp ridicule). Extraire le disque dur n'aidera pas non plus...

Il y a de multiples usages du TPM, mais voilà les grands principes. Le lien avec Secure Boot et UEFI c'est que les puces TPM en version 2.0 permettent de stocker les clés de sécurité de Secure Boot. Ce qui permet donc d'assurer une protection sans faille dès le boot. Et donc oui, TPM 2.0 sans UEFI c'est impossible. C'est ce que Microsoft impose désormais pour Windows 11 et je trouve ça plutôt bien personnellement.

Quand tu as vidé le TPM, tu l'as donc vidé de toutes les informations de sécurité qu'ils contenaient de l'ancien utilisateur (clés, empreintes etc.). Cela te permet d'installer sereinement un nouvel OS et de stocker tes secrets à toi dans ce fameux TPM.

Tu l'auras compris, une puce TPM performante permet d'avoir un niveau de sécurité plus élevé sans dégrader les performances ni l'ergonomie pour l'utilisateur. Si le processeur central devait assurer le chiffrement/déchiffrement à la volée en + de faire tourner le système, ça serait très lent. De la même façon, si l'utilisateur devait taper la vraie clé de chiffrement pour déverrouiller chaque élément chiffré, le système serait inutilisable.

J'ai essayé de vulgariser le plus possible mais c'est pas simple Dis-moi, si quelque chose est incompréhensible.

[Glenic]

Bonjour Maxoxo,
Comme toujours j'ai lu avec intérêt ton post long mais clair.
Merci de cette intervention qui précise les contours de cet être immatériel donc mystérieux qu'est le Secure Boot.
On y reviendra un peu plus tard car je dois d'abord faire sur mon nouvel ordi les tests que tu présentes dans ton post du 21 janvier.

[Glenic1]

Je suis incapable de dire si Secure Boot est toujours actif ou pas ! par quel moyen peut-on vérifier son état (actif ou mort) ?

Tu vas dans le bios et tu regardes si secure boot est sur "enabled" ou "disabled"

Hello,
Du fait de mes ennuis de rallumages intempestifs de l'ordi (voir le sujet viewtopic.php?t=195), j'ai été fouiller dans le BIOS.
Et bien le Secure Boot est désactivé.
Je m'en vais le réactiver sur les conseils de Maxoxo

[Glenic1]

Très bizarre.....
Quand l'option Secure Boot est enclenchée, l'ordinateur démarre normalement
SAUF que la carte WiFi est désactivée : aucune connexion WiFi possible.
J'ai donc provisoirement désactivé le Secure Boot
Cette option SB qui désactive la réception du WiFI, ça mérite un sujet spécial !

[maxoxo]

Salut,

par Glenic1 » 17 févr. 2023 20:07
Très bizarre.....
Quand l'option Secure Boot est enclenchée, l'ordinateur démarre normalement
SAUF que la carte WiFi est désactivée : aucune connexion WiFi possible.
J'ai donc provisoirement désactivé le Secure Boot
Cette option SB qui désactive la réception du WiFI, ça mérite un sujet spécial !

Ce n'est pas bizarre, mais sans doute logique. HP est spécialiste des cartes WiFi à la c***. Typiquement du Broadcom avec le pilote BCM43 qui est mal conçu.

Le Secure-Boot (SB) a vocation à protéger ton système et à garantir l'intégrité du noyau au démarrage. Il n'autorise donc que les pilotes signés et bien intégrés au noyau à démarrer. Ceux pour lesquels il existe bien un certificat de signature valide dans sa base. Ça paraît contraignant comme ça, mais c'est une sécurité vitale. Imaginons qu'un pirate parvienne à distribuer un pilote malveillant pour une distribution Linux. Tu l'installes, tu vas donc créer une porte dérobée dans ton noyau et ce que l'on appelle donc dans le milieu de la cybersécurité : une menace persistante avancée (APT) = https://fr.wikipedia.org/wiki/Advanced_ ... ent_Threat

Dans un système sans SB, le noyau démarre tel que modifié par l'utilisateur peu importe que les modules (pilotes) soient signés ou que leur authenticité soit vérifiée. Par conséquent, le système démarrera toujours avec cette porte dérobée qui compromet son intégrité. Avoir un accès au noyau c'est l'équivalent d'être Dieu sur un système...

Le SB permet d'éviter ça car il garantit que le noyau reste intègre, du moins que le noyau en fonctionnement est bien le noyau légitime installé avec le système. Là si tu veux que ça fonctionne, il faut que donc que tu certifies (signe) toi-même le pilote et que la clé de signature soit déclarée dans la base du SB. Normalement, à l'installation de Mint ou Ubuntu il y a une procédure automatisée pour faire ça. C'est la raison pour laquelle je recommande d'installer Mint/Ubuntu avec le SB activé quand c'est possible car passer de BIOS à SB c'est jamais simple.

J'attends le sujet dédié pour te dépanner

Gagnons un peu de temps quand même, peux tu m'indiquer ce que sors la commande

Code : Tout sélectionner

$ lspci | grep Network 

Elle va nous indiquer précisément la carte WiFi de ton PC.

[Glenic1]

Et voici la réponse à la commande indiquée :

02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 802.11a/b/g/n

Je ne sais pas si le 02:00.0 est intéressant. J'ai recopié toute la ligne qui est apparue sur le terminal.

[maxoxo]

Et voici la réponse à la commande indiquée :

02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM43228 802.11a/b/g/n

Ce n'est pas bizarre, mais sans doute logique. HP est spécialiste des cartes WiFi à la c***. Typiquement du Broadcom avec le pilote BCM43 qui est mal conçu.

J'aurais dû parier des sous !

Je ne sais pas si le 02:00.0 est intéressant

C'est l'adresse physique de la carte sur le bus PCI, effectivement pas d'intérêt dans ce contexte.