Comme si les utilisateurs de Linux n’étaient pas assez déçus par Microsoft Windows…
Microsoft est connu pour son approche signature « à ma façon ou sur l’autoroute » en ce qui concerne ses offres, le système d’exploitation Windows étant le plus important parmi ceux-ci.
De nombreux membres de la communauté FOSS sont en désaccord avec cette approche, avec un rejet catégorique de telles pratiques, suggérant aux gens d’opter pour des options plus ouvertes pour leurs systèmes d’exploitation et leurs applications, et je suis d’accord avec eux.
Malheureusement, cette même approche a désormais affecté de nombreux utilisateurs de la distribution Linux, qui ont été envoyés en courant à la recherche d’une solution à un problème causé par une mise à jour de Windows (qui se serait attendu à cela ?) .
Microsoft fait une erreur : attention aux utilisateurs de Linux !
Repérée pour la première fois par Ars Technica, une mise à jour mensuelle de Windows publiée le 13 août incluant un correctif pour une vulnérabilité vieille de deux ans, CVE-2022-2601, avec un indice de gravité CVSS de 8,6, provoquait sur des systèmes à double démarrage avec Windows et des distributions Linux de ne pas démarrer.
Ce correctif visait à résoudre un problème avec le chargeur de démarrage GRUB, qui permettait à des acteurs malveillants d’effectuer des écritures hors limites et éventuellement de contourner le démarrage sécurisé.
Mais cela a causé des dommages collatéraux dans le processus. Après la mise à jour, de nombreux utilisateurs, y compris les utilisateurs de Ventoy et Ubuntu 24.04 , ont signalé que l’erreur suivante leur était affichée :
Échec de la vérification des données shim SBAT : violation de la politique de sécurité
Quelque chose ne va vraiment pas : échec de l’auto-vérification SBAT : violation de la politique de sécurité
Cette mise à jour a installé un SBAT , qui est un acronyme pour Secure Boot Advanced Targeting, une méthode axée sur Linux pour supprimer divers composants dans le chemin de démarrage à l’aide de numéros de génération intégrés dans les binaires EFI. (désolé pour le jargon)
Cependant, ce mécanisme était censé fonctionner avec des appareils exécutant uniquement Windows et, selon Microsoft , cela n’aurait dû causer aucun problème sur les systèmes à double démarrage, du moins sur les distributions Linus les plus récentes.
Mais, comme nous le savons déjà, c’est le cas. 😑
Suite à ces révélations, dans un communiqué, Microsoft a mentionné qu’il était conscient de « certains scénarios de démarrage secondaires causaient des problèmes à certains clients », et qu’il travaillait avec ses partenaires Linux pour enquêter et résoudre le problème.
Heureusement, la communauté est venue à la rescousse, avec manutheeng, membre des forums Linux Mint, trouvant une solution pour Ubuntu dans un ancien message sur les forums Ubuntu.
La solution
- Tout d’abord, désactivez Secure Boot dans le menu UEFI.
- Ensuite, connectez-vous à Ubuntu avec l’utilisateur de votre choix.
- Maintenant, ouvrez un terminal et exécutez la commande suivante :
sudo mokutil --set-sbat-policy delete
- Après cela, redémarrez votre PC pour voir les modifications.
- Maintenant, si vous le souhaitez, vous pouvez réactiver le démarrage sécurisé à partir du menu UEFI.
Les étapes ci-dessus devraient également fonctionner avec n’importe quelle distribution Linux basée sur Ubuntu . Si cela ne fonctionne pas, vous pourriez être confronté à ce à quoi un utilisateur d’ordinateur portable Framework a été confronté.
Pensées finales
Si les systèmes à double démarrage étaient plus courants, ce problème aurait été traité plus rapidement, comme l’incident CrowdStrike survenu le mois dernier, mais ce n’était pas la faute de Microsoft.
Donc c’est mieux que rien. 🙂
En fin de compte, le démarrage sécurisé reste un gâchis absolu, ce qui a amené de nombreuses personnes à se demander si cela aurait pu être mieux implémenté.
Je pense que cela aurait pu, l’industrie du PC a précipité sa mise en œuvre avant qu’elle ne soit prête.
Article traduit
Aucune réponse