Debian-facile

Lunix64

Membre

Distrib. : Debian Buster

Noyau : Linux 5.8.4

(G)UI : Mate

Inscription : 28-08-2020

Secure boot et noyaux obligatoirement signés.

Bonjour à tous,

J'utilise Debian Buster, dont le grub exige un noyau signé.

Et je me pose des questions sur l'utilité de cette nouvelle sécurité supplémentaire qui oblige à introduire des clés dans l'UEFI pour utiliser des noyaux perso, à moins de désactiver le sécure boot.

Par exemple, quelqu'un qui n'a pas mis de mot de passe pour accéder à l'UEFI, le pirate qui a un accès physique à la machine peut aisément introduire dans le UEFI sa clé personelle et installer un noyau piraté et signé avec sa clé. Donc toute la sécurité repose sur le mot de passe UEFI.

De plus, quand on a les privilèges suffisants pour installer un noyau sur un système, on doit pouvoir installer des programmes de piratage autre part que dans le noyau.

Donc je me demande si exiger des noyaux signés est une sécurité vraiment utile, ou alors une sécurité superflue mais qui rassure certains utilisateurs ?

Dernière modification par Lunix64 (28-08-2020 05:53:06)

raleur

Membre

Inscription : 03-10-2014

Re : Secure boot et noyaux obligatoirement signés.

Debian Buster, dont le grub exige un noyau signé.

Seulement lorsqu'on utilise l'amorçage EFI avec le secure boot activé.
Avec l'amorçage BIOS/legacy ou avec le secure boot désactivé, pas besoin de noyau ni de modules signés.

le pirate qui a un accès physique à la machine peut aisément introduire dans le UEFI sa clé personelle

Ou simplement désactiver le secure boot.

Donc toute la sécurité repose sur le mot de passe UEFI.

Pas seulement, comme l'a illustré la récente faille de GRUB.
La solidité d'une chaîne est toujours celle de son maillon le plus faible.

on doit pouvoir installer des programmes de piratage autre part que dans le noyau.

Oui, mais le noyau n'est pas compromis donc c'est plus difficile à cacher.
D'autre part il existe des moyens de protéger (chiffrement) ou vérifier (métriques) les fichiers importants du système.

Dernière modification par raleur (07-09-2020 09:11:57)

---

Il vaut mieux montrer que raconter.

Lunix64

Membre

Distrib. : Debian Buster

Noyau : Linux 5.8.4

(G)UI : Mate

Inscription : 28-08-2020

Re : Secure boot et noyaux obligatoirement signés.

Ok.

Mais tout ça m'inquiète quand même un peu, bientôt les programmes que l'on lance devront'ils tous être signés par Microsoft ou par une clé présente dans l'UEFI ?

Et dans le futur un peu plus lointain les clés personelles insérées dans l'UEFI devront'elles, elles aussi, être signées par Microsoft ou par une Très Haute Autorité Suprème Au Développement Logiciel qui sera chargée d'autoriser ou non un être humain à developer des logiciels ?

J'ai aussi entendu dire que GNOME interdisait de lancer deux terminaux en même temps, donc la philosophie du logiciel libre qui veut autoriser l'utilisateur à exploiter sa machine comme bon lui semble, me semble quelque peu compromise par les multinationales qui ont mis la main sur linux et les programmes permettant d'exploiter ce noyau.

Et je me pose la question, qui a décidé qu'à partir de maintenant, les noyaux linux aussi devaient être signés ? Est-ce Microsoft qui a décidé ça tout seul ?

raleur

Membre

Inscription : 03-10-2014

Re : Secure boot et noyaux obligatoirement signés.

les programmes que l'on lance devront'ils tous être signés par Microsoft ou par une clé présente dans l'UEFI ?

Seulement si le noyau l'exige. Et je ne vois pas pourquoi il l'exigerait.

les clés personelles insérées dans l'UEFI devront'elles, elles aussi, être signées par Microsoft

Ça n'aurait aucun sens. Si les clés sont signées, par Microsoft, c'est pour être acceptées par le firmware UEFI sans avoir besoin d'être insérées.

J'ai aussi entendu dire que GNOME interdisait de lancer deux terminaux en même temps

Je n'utilise pas Gnome, mais ça me paraît surprenant.

qui a décidé qu'à partir de maintenant, les noyaux linux aussi devaient être signés ?

Les distributions, à partir du moment où elles ont choisi de rendre leur système d'amorçage compatible avec le secure boot.
Si on n'utilise pas le secure boot on n'est pas obligé d'utiliser un noyau signé, Debian fournit aussi des noyaux non signés (paquets linux-image-*-unsigned).

---

Il vaut mieux montrer que raconter.

captnfab

Admin-Girafe

Lieu : /dev/random

Distrib. : Debian

Noyau : Dur

(G)UI : gui gui, je zuis un doiseau

Inscription : 07-07-2008

Site Web

Re : Secure boot et noyaux obligatoirement signés.

@Lunix64:

Pour synthétiser un peu ce qui a été dit sur l'UEFI.

L'UEFI contient par défaut des clefs signées par Microsoft, mais potentiellement d'autres aussi, et l'utilisateur peut à sa guise en rajouter.
L'UEFI peut être paramétré pour n'amorcer que des systèmes qui ont été signés par une clef en sa possession (c'est le SecureBoot), cela a plus de sens si l'on interdit le boot usb/réseau et que l'on rajoute un mot de passe à l'uefi.

Autrement dit, c'est juste une possibilité, mais qui est activée par défaut sur la plupart du matériel.

Debian propose des noyaux signés par une clef signée par Microsoft. Cela permet à ces noyaux d'êtres amorcés par l'UEFI en mode SecureBoot, car les clefs par défaut suffisent à authentifier les noyaux signés.

Si un utilisateur veut compiler ses propres noyaux, il peut, mais ils ne seront alors pas signés par la clef Debian (comme les noyaux -unsigned proposés par Debian). Les noyaux seront alors bootable si le SecureBoot est désactivé, ou si l'utilisateur a généré une nouvelle clef pour signer les noyaux, et a rajouté cette clef dans son UEFI.

Une fois le noyau démarré, il fait un peu ce qu'il veut. Il peut décider de n'accepter de charger seulement des modules noyau signés. Il pourrait exiger que toutes les applications soient signées aussi, par une clef de son choix.

Mais… Il ne faut pas oublier que l'on est dans le monde du logiciel libre. Et donc contrairement à la signature du noyau, qui peut être imposée par les constructeurs de cartes mères, la signature des applications ne sera pas imposée par le noyau linux, vu que ce dernier est modifiable/compilable par tous.

Tout au plus, certaines options peuvent permettre à la personne compilant le noyau (par exemple une distribution linux), d'activer cette exigence de signature.

---

captnfab,
Association Debian-Facile, bépo.
TheDoctor: Your wish is my command… But be careful what you wish for.

anonyme

Invité

Re : Secure boot et noyaux obligatoirement signés.

Bonjour
pour imagé ce qui a été expliqué au dessus voila sur bullseye avec noyau signé , le sécure-boot désactivé mais les clés chargées dans l' EFI
un EFI Asus par défaut "secureboot " inactif OS => "autre" (autre choix "windows") mais les clés présentes et chargées (possible d' effacer les clés mais a chaque mise a jour de l' EFI elles reviennent )
extrait du syslog

Sep  7 17:04:07 raven2200g kernel: [    0.677596] IPI shorthand broadcast: enabled
Sep  7 17:04:07 raven2200g kernel: [    0.677614] sched_clock: Marking stable (705443204, -27994720)->(685031328, -7582844)
Sep  7 17:04:07 raven2200g kernel: [    0.677709] registered taskstats version 1
Sep  7 17:04:07 raven2200g kernel: [    0.677710] Loading compiled-in X.509 certificates
Sep  7 17:04:07 raven2200g kernel: [    0.693361] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input0
Sep  7 17:04:07 raven2200g kernel: [    0.700999] Loaded X.509 cert 'Debian Secure Boot CA: 6ccece7e4c6c0d1f6149f3dd27dfcc5cbb419ea1'
Sep  7 17:04:07 raven2200g kernel: [    0.701039] Loaded X.509 cert 'Debian Secure Boot Signer 2020: 00b55eb3b9'
Sep  7 17:04:07 raven2200g kernel: [    0.701067] zswap: loaded using pool lzo/zbud
Sep  7 17:04:07 raven2200g kernel: [    0.701284] Key type ._fscrypt registered
Sep  7 17:04:07 raven2200g kernel: [    0.701286] Key type .fscrypt registered
Sep  7 17:04:07 raven2200g kernel: [    0.701287] Key type fscrypt-provisioning registered
Sep  7 17:04:07 raven2200g kernel: [    0.701468] AppArmor: AppArmor sha1 policy hashing enabled
Sep  7 17:04:07 raven2200g kernel: [    0.702216] integrity: Loading X.509 certificate: UEFI:db
Sep  7 17:04:07 raven2200g kernel: [    0.702452] integrity: Loaded X.509 cert 'ASUSTeK MotherBoard SW Key Certificate: da83b990422ebc8c441f8d8b039a65a2'
Sep  7 17:04:07 raven2200g kernel: [    0.702453] integrity: Loading X.509 certificate: UEFI:db
Sep  7 17:04:07 raven2200g kernel: [    0.702645] integrity: Loaded X.509 cert 'ASUSTeK Notebook SW Key Certificate: b8e581e4df77a5bb4282d5ccfc00c071'
Sep  7 17:04:07 raven2200g kernel: [    0.702646] integrity: Loading X.509 certificate: UEFI:db
Sep  7 17:04:07 raven2200g kernel: [    0.702676] integrity: Loaded X.509 cert 'Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8cd54f316ed522988a1bd4'
Sep  7 17:04:07 raven2200g kernel: [    0.702676] integrity: Loading X.509 certificate: UEFI:db
Sep  7 17:04:07 raven2200g kernel: [    0.702719] integrity: Loaded X.509 cert 'Microsoft Windows Production PCA 2011: a92902398e16c49778cd90f99e4f9ae17c55af53'
Sep  7 17:04:07 raven2200g kernel: [    0.702720] integrity: Loading X.509 certificate: UEFI:db
Sep  7 17:04:07 raven2200g kernel: [    0.702915] integrity: Loaded X.509 cert 'Canonical Ltd. Master Certificate Authority: ad91990bc22ab1f517048c23b6655a268e345a63'
Sep  7 17:04:07 raven2200g kernel: [    0.707622] Freeing unused kernel image (initmem) memory: 1632K
Sep  7 17:04:07 raven2200g kernel: [    0.724434] Write protecting the kernel read-only data: 16384k
Sep  7 17:04:07 raven2200g kernel: [    0.725274] Freeing unused kernel image (text/rodata gap) memory: 2044K
Sep  7 17:04:07 raven2200g kernel: [    0.725340] Freeing unused kernel image (rodata/data gap) memory: 88K
 

ça me dérange pas du moment que ça ne perturbe rien (aucune idée de a partir de quelle version du noyau ceci est fait , pas fait attention sur buster ou avant , actuellement sous bullseye a jour)