Systemd supremo propose de resserrer le processus de démarrage de Linux •

  • Français


  • Le dernier article de blog de Lennart Poettering propose de déplacer le processus de démarrage Linux dans un “Brave New Trusted Boot World” d’images de noyau unifiées signées cryptographiquement.

    L’agent Poettering propose un mécanisme pour renforcer la sécurité du processus de démarrage du système sur les machines Linux, en utilisant le matériel TPM 2.0. En bref, ce qu’il considère comme le problème est que sur le matériel avec Secure Boot activé, alors que le processus de démarrage jusqu’au noyau inclus est signé, l’étape suivante, le chargement du initrd, n’est pas. C’est ce qu’il veut réparer.

    L’initrd est le “disque RAM initial”. C’est ainsi que les distributions Linux gèrent le problème du démarrage d’une machine sur un matériel extrêmement différent sans créer un noyau personnalisé unique pour chaque machine individuelle. Le chargeur de démarrage charge le noyau et l’initrd en mémoire, puis lorsque le noyau commence à s’exécuter, il dispose d’un système de fichiers temporaire prêt pour lui en mémoire, à partir duquel il peut charger tous les pilotes de périphériques supplémentaires dont il a besoin – y compris les pilotes de périphériques qui pourraient être nécessaires afin de trouver son réel système de fichiers racine, qui peut se trouver n’importe où : pas seulement sur un lecteur local, mais sur FibreChannel, InfiniBand, une clé USB, un lecteur réseau via iSCSI ou AoE ou NFS, ou autre.

    Le problème est que d’autres pilotes de périphériques peuvent également avoir besoin d’être dans l’initrd, tels que les pilotes graphiques. Si vous avez des pilotes graphiques Nvidia, par exemple, chaque fois que les pilotes sont mis à jour, la distribution construit un nouvel initrd.

    Cela fonctionne, mais le problème est que les initrds générés localement sont potentiellement non sécurisés. En principe, un logiciel malveillant ou un intrus pourrait insérer un code malveillant dans l’initrd, et il sera chargé à chaque démarrage de votre système, même si aucune autre copie de ce code malveillant n’existe ailleurs sur votre disque dur.

    La situation concernant le chiffrement intégral du disque (FDE) est pire : l’initrd est la façon dont Linux démarre les disques locaux avec FDE. Comme Le Reg Le bureau FOSS a découvert lors de la mise en place de Linux sur un nouveau Dell Latitude, certaines formes de chiffrement complet du disque peuvent déverrouiller les disques chiffrés sans mot de passe en utilisant les informations stockées dans les registres de configuration de la plate-forme de la puce TPM. L’agent P est très préoccupé par la manière dont le code de l’initrd a accès aux PCR TPM.

    Il décrit le processus de démarrage actuel comme suit :

    Il énumère sept problèmes différents avec cette séquence d’événements, et la première menace qu’il mentionne est l’attaque de la “femme de chambre maléfique”, comme discuté sur Le Reg dès 2009.

    Sa solution proposée est l’image du noyau unifié :

    Pour éviter tout doute, un fichier PE est un “exécutable portable” de Microsoft, comme nous l’avons expliqué lors de l’introduction du binaire multiplateforme Redbean 2. Oui, c’est ainsi que fonctionne UEFI ; en effet, comme il le note en expliquant le processus de démarrage :

    Oui, comme pour la plupart de ces choses, Microsoft a la main sur les rênes, et déjà certains appellent cela une autre étape dans la manœuvre de longue date Embrace, Extend, Extinguish de l’entreprise – par exemple, le tout premier commentaire sur le fil Hacker News sur le sujet.

    Comme d’habitude avec les déclarations de Poettering, nous prédisons la panique et la parcimonie. Dans certains scénarios, cela pourrait fournir une protection utile. Comme Le Reg noté il y a plus de dix ans, lorsque UEFI était nouveau, Secure Boot pouvait être un problème pour Linux, et nous avons lié à un article de blog sur le sujet par le boffin suprême du démarrage Matthew Garrett. Cependant, avec le temps, les distributions d’entreprise ont adopté le démarrage sécurisé et ChromeOS Flex le recommande en fait. Cette fois-ci, le Dr Garrett est encourageant:

    Si MJG l’approuve, nous n’oserons pas différer. Tout ce que nous remarquons, c’est que cela élargit potentiellement le fossé entre les distributions d’entreprise, de plus en plus verrouillées, sécurisées et de plus en plus difficiles à personnaliser, et le monde sauvage et libre des systèmes d’exploitation de logiciels libres par et pour ceux qui ne veulent pas d’autres, ou des sociétés, pour pouvoir contrôler leurs ordinateurs.

    Comme l’a écrit Aldous Huxley :

    Sur x86, du moins pour le moment, vous pouvez désactiver Secure Boot. Vous ne pouvez pas sur les machines Arm, ce qui, à notre avis, il y a dix ans, était l’une des raisons pour lesquelles la Surface RT ne se vendait pas. L’informatique de confiance, après tout, ne signifie pas que vous faites confiance à votre propre ordinateur. Il y a déjà un mouvement contre systemd, et nous soupçonnons qu’il va maintenant s’élargir pour être également anti-UKI. ®

    L'équipe de Comparaland

    L'équipe rédactionnnelle du site

    Pour contacter personnellement le taulier :

    Laisser un commentaire

    Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *