Publication du gestionnaire système systemd 252 avec prise en charge du UKI (Unified Kernel Image)

Après cinq mois de développement, la version du gestionnaire de système systemd 252 a été publiée. Le changement clé de cette nouvelle version est l'intégration du support d'un processus de démarrage modernisé, permettant de vérifier par des signatures numériques non seulement le noyau et le chargeur de démarrage, mais aussi les composants de l'environnement système de base.

La méthode proposée consiste à utiliser une image de noyau unifiée UKI (Unified Kernel Image) au démarrage, qui combine le gestionnaire de démarrage du noyau à partir de l'UEFI (UEFI boot stub), l'image du noyau Linux et l'environnement système initrd chargé en mémoire, utilisé pour l'initialisation initiale avant le montage du système de fichiers racine. L'image UKI est présentée sous la forme d'un exécutable au format PE, pouvant être chargée au moyen de chargeurs traditionnels ou appelée directement depuis le firmware UEFI. Lors de l'appel depuis l'UEFI, il est possible de vérifier l'intégrité et l'authenticité par une signature numérique non seulement du noyau, mais aussi du contenu de l'initrd.

Pour le calcul des paramètres des registres TPM PCR (Trusted Platform Module Platform Configuration Register), utilisés pour contrôler l'intégrité et générer la signature numérique de l'image UKI, un nouvel outil systemd-measure a été inclus. La clé publique utilisée dans la signature et les informations associées sur le PCR peuvent être intégrées directement dans l'image de démarrage UKI (la clé et la signature sont enregistrées dans un fichier au format PE dans les champs ‘.pcrsig’ et ‘.pcrkey’) et extraites par des outils externes ou internes.

Notamment, pour utiliser ces informations, les outils systemd-cryptsetup, systemd-cryptenroll et systemd-creds ont été adaptés, permettant d'assurer le lien entre les partitions de disque chiffrées et le noyau validé par une signature numérique (dans ce cas, l'accès à la partition chiffrée est accordé uniquement si l'image UKI a passé la vérification par signature numérique basée sur les paramètres stockés dans le TPM).

De plus, l'outil systemd-pcrphase a été intégré, permettant de gérer l'association de différentes étapes de démarrage aux paramètres stockés en mémoire des crypto-processeurs prenant en charge la spécification TPM 2.0 (par exemple, il est possible de rendre la clé de déchiffrement de la partition LUKS2 accessible uniquement dans l'image initrd et de bloquer l'accès à celle-ci lors des étapes ultérieures du démarrage).

D'autres modifications incluent :

• L'utilisation de la locale C.UTF-8 est assurée par défaut, sauf indication contraire dans les paramètres.
• La possibilité d'exécuter l'opération de préconfiguration complète des services («systemctl preset») lors du premier démarrage a été mise en œuvre. Pour activer la préconfiguration au démarrage, une construction avec l'option «-Dfirst-boot-full-preset» est requise, mais elle devrait être activée par défaut dans les futures versions.
• Dans les unités de gestion des utilisateurs, un contrôleur de ressources CPU a été mis en œuvre, ce qui a permis d'assurer l'application des réglages CPUWeight à toutes les unités slice utilisées pour diviser le système en parties (app.slice, background.slice, session.slice) afin d'isoler les ressources entre les différents services utilisateur qui concourent pour les ressources CPU. Le CPUWeight prend également en charge la valeur «idle» pour activer le mode de fourniture de ressources correspondant.
• Dans les unités temporaires («transient») et dans l'outil systemd-repart, la possibilité de redéfinir des réglages par la création de fichiers drop-in dans le répertoire /etc/systemd/system/nom.d/ a été autorisée.
• Pour les images système, un drapeau de fin de support (‘support-ended’) a été mis en place, déterminant ce fait sur la base de la valeur du nouveau paramètre «SUPPORT_END=» dans le fichier /etc/os-release.
• Les réglages «ConditionCredential=» et «AssertCredential=» ont été ajoutés, pouvant être utilisés pour ignorer ou terminer de manière abrupte les unités en l'absence de certaines informations d'identification dans le système.
• Dans system.conf et user.conf, les réglages «DefaultSmackProcessLabel=» et «DefaultDeviceTimeoutSec=» ont été ajoutés pour définir le niveau de sécurité SMACK et le délai d'activation de l'unité, appliqués par défaut.
• Dans les réglages «ConditionFirmware=» et «AssertFirmware=», il est désormais possible d'indiquer des champs SMBIOS spécifiques, par exemple pour démarrer l'unité uniquement si le champ /sys/class/dmi/id/board_name contient la valeur «Custom Board», on peut spécifier «ConditionFirmware=smbios-field(board_name = «Custom Board»)».
• Au cours de l'initialisation (PID 1), la possibilité d'importer des informations d'identification à partir de champs SMBIOS (Type 11, «lignes de fournisseur OEM») a été ajoutée, en complément de leur définition via qemu_fwcfg, ce qui facilite la fourniture d'informations d'identification. aux machines virtuelles et permet d'éviter des outils tiers tels que cloud-init et ignition.
• Lors de l'arrêt, la logique de démontage des systèmes de fichiers virtuels (proc, sys) a été modifiée et des informations sur les processus bloquant le démontage des systèmes de fichiers ont été enregistrées dans le journal.
• Dans le filtre des appels système (SystemCallFilter), l'accès à l'appel système riscv_flush_icache est autorisé par défaut.
• Le chargeur sd-boot a introduit la possibilité de démarrer en mode mixte, où un noyau Linux 64 bits est lancé depuis un firmware UEFI 32 bits. Une fonctionnalité expérimentale a été ajoutée pour appliquer automatiquement les clés SecureBoot à partir des fichiers trouvés dans l'ESP (partition système EFI).
• De nouvelles options ont été ajoutées à l'outil bootctl : « —all-architectures » pour installer des fichiers binaires pour toutes les architectures EFI prises en charge, « —root= » et « —image= » pour travailler avec un répertoire ou une image disque, « —install-source= » pour définir la source pour l'installation, « —efi-boot-option-description= » pour gérer les noms des entrées de démarrage.
• L'outil systemctl a ajouté la commande ‘list-automounts’ pour afficher la liste des répertoires montés automatiquement, et l'option « —image= » pour exécuter des commandes en liaison avec l'image disque spécifiée. Les commandes ‘show’ et ‘status’ ont reçu les options « —state= » et « —type= ».
• Dans systemd-networkd, des options « TCPCongestionControlAlgorithm= » ont été ajoutées pour choisir l'algorithme de contrôle de congestion TCP, « KeepFileDescriptor= » pour conserver le descripteur de fichier des interfaces TUN/TAP, « NetLabel= » pour définir des étiquettes NetLabel, et « RapidCommit= » pour accélérer la configuration via DHCPv6 (RFC 3315). Dans le paramètre « RouteTable= », il est désormais autorisé de spécifier les noms des tables de routage.
• Dans systemd-nspawn, l'utilisation de chemins de fichiers relatifs est désormais autorisée dans les options « —bind= » et « —overlay= ». L'option « —bind= » a été enrichie du paramètre ‘rootidmap’ pour lier l'identifiant utilisateur root dans le conteneur au propriétaire du répertoire monté côté hôte.
• Dans systemd-resolved, le paquet OpenSSL est utilisé par défaut comme backend pour le chiffrement (le support de gnutls reste en option). Les algorithmes DNSSEC non pris en charge sont désormais traités comme non sécurisés, au lieu de renvoyer une erreur (SERVFAIL).
• Dans systemd-sysusers, systemd-tmpfiles et systemd-sysctl, la possibilité de transmettre des configurations via le mécanisme de stockage des identifiants a été mise en œuvre.
• L'outil systemd-analyze a ajouté la commande ‘compare-versions’ pour comparer des chaînes contenant des numéros de version (similaire à ‘rpmdev-vercmp’ et ‘dpkg —compare-versions’). La commande ‘systemd-analyze dump’ a introduit la possibilité de filtrer les unités par masque.
• Lors du choix du mode de suspension en plusieurs étapes (suspend-then-hibernate, passage en mode veille après le mode d'attente), le temps passé en mode d'attente est désormais déterminé en fonction de l'estimation du temps d'autonomie restante. Le passage instantané en mode veille se produit lorsque la batterie reste à moins de 5 % de charge.
• Un nouveau mode de sortie « -o short-delta » a été ajouté à 'journalctl', affichant la différence de temps entre les différents messages dans le journal.
• Le support de la création de partitions avec FS Squashfs et de partitions pour dm-verity, y compris avec des signatures numériques, a été ajouté à systemd-repart.
• Une configuration « StopIdleSessionSec= » a été ajoutée à systemd-logind pour terminer une session inactive après l'expiration d'un délai spécifié.
• Une option « —unlock-key-file= » a été ajoutée à systemd-cryptenroll pour extraire la clé de déchiffrement depuis un fichier, plutôt que par une demande interactive à l'utilisateur.
• La possibilité d'exécuter l'utilitaire systemd-growfs dans des environnements sans udev a été assurée.
• L'amélioration du support des systèmes avec plusieurs cartes graphiques a été apportée à systemd-backlight.
• La licence des exemples de code fournis dans la documentation a été modifiée de CC0 à MIT-0.

Modifications rompant la compatibilité :

• Lors de la vérification du numéro de version du noyau à l’aide de la directive ConditionKernelVersion, un simple comparatif de chaînes est désormais appliqué pour les opérateurs ‘=’ et ‘!=’. Si l'opérateur de comparaison n'est pas spécifié, un correspondance par glob avec les caractères ‘*’, ‘?’ et ‘[‘, ‘]’ peut être utilisée. Pour comparer les versions au style de la fonction stverscmp(), les opérateurs ‘’, ‘=’ doivent être utilisés.
• L'étiquette SELinux utilisée pour vérifier l'accès depuis le fichier de unit est désormais lue au moment du chargement du fichier, et non au moment de la vérification d'accès.
• La condition « ConditionFirstBoot » se déclenche désormais uniquement lors du premier démarrage du système, directement au stade de démarrage et renvoie « false » lors de l'appel des unités après le démarrage.
• En 2024, la prise en charge du mécanisme de limitation des ressources cgroup v1 sera interrompue dans systemd, ce qui en fait un élément obsolète dans la version systemd 248. Les administrateurs sont invités à prévoir la migration vers cgroup v2 pour les services qui dépendent de cgroup v1. La principale différence entre cgroups v2 et v1 est l'utilisation d'une hiérarchie de cgroups commune pour tous les types de ressources, au lieu de hiérarchies séparées pour la répartition des ressources CPU, la gestion de la mémoire et l'entrée/sortie. Les hiérarchies séparées entraînent des difficultés d'organisation de l'interaction entre les gestionnaires et des coûts supplémentaires pour le noyau lors de l'application des règles pour un processus mentionné dans différentes hiérarchies.
• Au cours de la seconde moitié de 2023, la prise en charge des hiérarchies de répertoires séparées sera interrompue lorsque /usr est monté séparément de la racine ou lorsque les répertoires /bin et /usr/bin, /lib et /usr/lib sont séparés.

Source : opennet.ru