Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Dernière modification par --gilles-- (02-08-2020 10:45:14)
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil 
Hors ligne
Si tout le monde pense pareil, c'est qu'aucune personne ne pense beaucoup.
Intel® Core™2 Duo E8500 × 2
4,0 Gio DDR3 - 1333 MHz
Et si vous cherchiez votre solution dans le wiki => https://debian-facile.org/accueil
Hors ligne
Pensez à mettre à jour, le correctif pour grub2 est dans les mises à jour pour buster en attendant la 10.5 qui devrait arriver sous peu :
La 10.5 est sortie hier débit d’après midi
--
Jc E
Hors ligne
Dernière modification par MicP (02-08-2020 09:38:45)
Hors ligne
BootHole
Je constate encore une fois avec plaisir que les baptiseurs de failles de sécurité n'ont rien perdu de leur humour et ne perdent pas une occasion de faire un jeu de mot scabreux.
Pensez à mettre à jour
Il y a un truc qui m'échappe. L'article de Debian dit :
il est fortement recommandé à tous les utilisateurs de Debian de prendre la précaution d'installer toutes les mises à jour recommandées
mais d'un autre côté certaines de ces mises à jour "fortement recommandées" ne sont disponibles que dans l'archive buster-proposed-updates, alors que ce dépôt n'est pas activé sur la plupart des installations (ne pas confondre avec buster-updates). Ce n'est pas cohérent. Heureusement que la publication de la révision 10.5 vient remettre tout ça à plat en intégrant toutes ces mises à jour dans le dépôt principal buster.
Je constate que le Secure Boot n'a de Secure que le nom
Ce n'est que maintenant que tu t'en rends compte ? La chaîne de "confiance" du secure boot ne vérifie que le chargeur d'amorçage et le noyau, mais pas le reste, notamment le fichier de configuration du chargeur d'amorçage (qui n'est rien de moins qu'un script dans le cas de GRUB) et l'initramfs. On peut donc leur faire faire presque tout ce qu'on veut (une exception étant l'impossibilité de charger des modules du noyau non signés ou corrompus, par exemple dans le but d'injecter un rootkit) sans toucher au secure boot à moins de mettre en place des métriques sur ces éléments (avec la puce TPM).
ne jamais activer l'UEFI sur mes machines
Ne pas confondre UEFI et secure boot. D'ailleurs on n'a plus le choix sur un certain nombres de machines récentes, et de plus en plus souvent : l'amorçage UEFI est systématiquement activé, on peut seulement activer ou désactiver l'amorçage traditionnel BIOS/legacy (quand il est encore pris en charge).
Dernière modification par raleur (02-08-2020 11:09:27)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Celle là est quand même assez magnifique, je dois le concéder, puisqu'il faut un accès root!
Précisément. Le secure boot est censé protéger même contre une attaque en root.
Si un attaquant root modifie GRUB ou le noyau, la somme de contrôle ne correspond plus et le secure boot refuse de booter.
Dernière modification par raleur (02-08-2020 11:04:16)
Il vaut mieux montrer que raconter.
Hors ligne
Franchement, faut arrêter avec ce genre de post..
Et pourquoi donc ?
Grace à ton coup de gueule et ton intervention, je ne m'inquiète donc plus maintenant.
Le post est donc utile pour ceux qui n'y connaissent rien, comme moi
Dernière modification par Anonyme (02-08-2020 11:32:58)
Dernière modification par raleur (02-08-2020 11:54:12)
Il vaut mieux montrer que raconter.
Hors ligne
…Cette version intermédiaire corrige aussi l'annonce de sécurité de Debian DSA-4735 grub2 qui traite de plusieurs problèmes de CVE concernant la vulnérabilité "BootHole" de UEFI SecureBoot dans GRUB2. …
https://www.debian.org/News/2020/20200801
Voir aussi : https://debian-facile.org/viewtopic.php?id=27975
Hors ligne