Lennart Poettering a publié une proposition visant à moderniser le processus de démarrage des distributions Linux, visant à résoudre les problèmes existants et à simplifier l'organisation d'un démarrage entièrement vérifié qui confirme la fiabilité du noyau et de l'environnement système sous-jacent. Les modifications requises pour implémenter la nouvelle architecture sont déjà incluses dans la base de code systemd et affectent des composants tels que systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase et systemd-creds.
Les changements proposés se résument à la création d'une seule image universelle UKI (Unified Kernel Image), combinant l'image du noyau Linux, un gestionnaire de chargement du noyau depuis l'UEFI (UEFI boot stub) et l'environnement système initrd chargé en mémoire, utilisé pour initialisation initiale à l'étape précédant le montage du FS racine. Au lieu d'une image disque RAM initrd, l'ensemble du système peut être empaqueté dans UKI, ce qui vous permet de créer des environnements système entièrement vérifiés chargés dans la RAM. L'image UKI est formatée comme un fichier exécutable au format PE, qui peut être chargé non seulement à l'aide des chargeurs de démarrage traditionnels, mais peut également être appelé directement à partir du micrologiciel UEFI.
La possibilité d'appeler depuis l'UEFI vous permet d'utiliser un contrôle d'intégrité de la signature numérique qui couvre non seulement le noyau, mais également le contenu de l'initrd. Dans le même temps, la prise en charge des appels à partir de chargeurs de démarrage traditionnels vous permet de conserver des fonctionnalités telles que la livraison de plusieurs versions du noyau et la restauration automatique vers un noyau fonctionnel si des problèmes sont détectés avec le nouveau noyau après l'installation de la mise à jour.
Actuellement, dans la plupart des distributions Linux, le processus d'initialisation utilise la chaîne « firmware → couche de calage Microsoft signée numériquement → chargeur de démarrage GRUB signé numériquement par la distribution → noyau Linux signé numériquement → environnement initrd non signé → FS racine ». Le manque de vérification initrd dans les distributions traditionnelles crée des problèmes de sécurité, puisque, entre autres, dans cet environnement, les clés de décryptage du système de fichiers racine sont récupérées.
La vérification de l'image initrd n'est pas prise en charge puisque ce fichier est généré sur le système local de l'utilisateur et ne peut pas être certifié par une signature numérique du kit de distribution, ce qui complique grandement l'organisation de la vérification lors de l'utilisation du mode SecureBoot (pour vérifier l'initrd, le l'utilisateur doit générer ses propres clés et les charger dans le micrologiciel UEFI). De plus, l'organisation de démarrage actuelle ne permet pas l'utilisation des informations des registres TPM PCR (Platform Configuration Register) pour contrôler l'intégrité des composants de l'espace utilisateur autres que shim, grub et le noyau. Parmi les problèmes existants, on mentionne également la complexité de la mise à jour du chargeur de démarrage et l'impossibilité de restreindre l'accès aux clés du TPM pour les anciennes versions du système d'exploitation devenues inutiles après l'installation de la mise à jour.
Les principaux objectifs de l'introduction de la nouvelle architecture de chargement sont :
- Fournir un processus de démarrage entièrement vérifié qui s'étend du micrologiciel à l'espace utilisateur, confirmant la validité et l'intégrité des composants en cours de chargement.
- Liaison des ressources contrôlées aux registres TPM PCR, séparés par propriétaire.
- Possibilité de pré-calculer les valeurs PCR en fonction du noyau, de l'initrd, de la configuration et de l'ID du système local utilisé lors du démarrage.
- Protection contre les attaques de restauration associées au retour à une version précédente vulnérable du système.
- Simplifiez et augmentez la fiabilité des mises à jour.
- Prise en charge des mises à jour du système d'exploitation qui ne nécessitent pas de réapplication ou de provisionnement local de ressources protégées par TPM.
- Le système est prêt pour la certification à distance pour confirmer l'exactitude du système d'exploitation et des paramètres chargés.
- La possibilité de joindre des données sensibles à certaines étapes de démarrage, par exemple en extrayant les clés de chiffrement du système de fichiers racine du TPM.
- Fournir un processus sécurisé, automatique et sans utilisateur pour déverrouiller les clés permettant de déchiffrer un lecteur de partition racine.
- Utilisation de puces prenant en charge la spécification TPM 2.0, avec la possibilité de revenir à des systèmes sans TPM.
Source: opennet.ru