Pour développer l'option 1 de FSMaxB, j'ai écrit une page avec des instructions (principalement) pas à pas pour remplacer vos clés Secure Boot. ici. Notez toutefois que certains détails de la sélection dans l'interface utilisateur du microprogramme seront spécifiques au système. Il existe également d'autres moyens d'atteindre cet objectif. L'ajout de nouvelles clés (comme décrit prochainement) nécessitera des étapes qui ne sont pas documentées sur cette page.
Cette approche permet de limiter ce que l'ordinateur peut démarrer, mais elle va un peu trop loin en ce qui concerne les exigences de FSMaxB. Plus précisément, elle empêche non seulement Windows de démarrer, mais aussi la plupart des CD live de Linux. Je pense à un certain nombre de moyens de minimiser ce problème, mais certains d'entre eux sont gênants et la plupart ne fonctionnent que sur des distributions qui sont compatibles avec Secure Boot :
- Ajouter les clés publiques des distributions aux clés Secure Boot de l'ordinateur et ajuster leurs processus de démarrage pour contourner shim et démarrer directement Grub ou un autre Grub. Cela nécessite toutefois de modifier des fichiers sur les CD live, ce qui est une tâche fastidieuse pour les utilisateurs finaux peu avertis sur le plan technique.
- Placez une copie de rEFInd sur le disque dur. Cela devrait permettre de rediriger le processus de démarrage vers Grub sur un CD live, en contournant sa copie de shim. En théorie, cela devrait fonctionner pour tout ce qui utilise shim, à condition que la clé de la distribution figure dans la liste de clés Secure Boot que vous avez créée.
- Placez une copie de rEFInd sur le disque dur, lancée via le site de la Fondation Linux PreBootloader. Cela permettra aux utilisateurs d'ajouter des hachages pour n'importe quel boot loader au micrologiciel, ce qui leur permettra de lancer n'importe quelle version de Linux, même si son boot loader et ses noyaux ne sont pas signés. Cela leur permettrait probablement aussi de démarrer Windows, mais ils devraient au moins approuver explicitement cette action.
- Placer une copie de rEFInd sur le disque dur, lancée via shim. Cela ne présente aucun avantage par rapport à la configuration de base, si ce n'est qu'il est plus facile pour les utilisateurs d'ajouter des clés (via la liste MOK de shim). Il est concevable que la présence de shim facilite l'utilisation de certains chargeurs de démarrage.
- Incluez dans le jeu de clés que vous ajoutez à la liste Secure Boot la clé publique associée à celle que Microsoft utilise pour signer les fichiers binaires de tiers. Étant donné que Microsoft signe ses propres produits avec une clé différente, cela permettra au micrologiciel de lancer des outils tiers, tels qu'Ubuntu 12.10 ou Fedora 18, mais pas de lancer la version de Windows de Microsoft. Les produits tiers basés sur Windows, cependant, peuvent être signés avec la clé tierce de Microsoft et donc se lancer. Notez que certaines cartes enfichables ont également un micrologiciel signé avec cette clé. Cette action peut donc être nécessaire pour utiliser le micrologiciel de ces cartes.
Quant à l'idée selon laquelle il s'agit d'une mauvaise idée, je ne suis pas d'accord, à condition que ce soit ce que le propriétaire de la machine souhaite réellement. À l'époque du DOS, il était courant que des ordinateurs soient infectés en démarrant accidentellement une disquette contenant un virus du secteur d'amorçage. En principe, la même chose pourrait se produire aujourd'hui via une clé USB ou un CD-R. Il vaut la peine de fermer cette voie d'attaque, même si elle n'est plus courante aujourd'hui. Cela dit, je ne recommanderais pas de donner ou de vendre un tel ordinateur sans indiquer clairement au destinataire ce qui lui a été fait et sans lui fournir des instructions sur la manière d'annuler les changements, s'il le souhaite.
