Systemd 260 : TPM2, sandboxing et nouvelles fonctionnalités sous Linux

Guide matériel » Guides d'achat » Systemd 260 : TPM2, sandbox et nouvelles fonctionnalités sous Linux

Avec l'arrivée de systemd 260, les distributions Linux franchissent une nouvelle étape importante vers un écosystème plus moderne et sécurisé, orienté vers le cloud, la virtualisation et l'automatisation. Cette version ne se contente pas d'apporter des améliorations mineures : elle introduit des changements significatifs au niveau du démarrage, de la gestion des services, du réseau, de l'utilisation du TPM2 pour l'intégrité et le chiffrement, ainsi que des capacités de sandbox au niveau du disque.

Dans le même temps, le projet renforce sa documentation et son approche de l'interaction avec les agents d'intelligence artificielle , démontrant ainsi que systemd est un pilier essentiel auquel se connectent de plus en plus d'outils de développement et d'observabilité. Si vous administrez des systèmes Linux sur des serveurs, dans le cloud, sur des postes de travail d'entreprise ou dans des laboratoires, il est judicieux de prendre le temps d'examiner ces nouvelles fonctionnalités afin d'anticiper les mises à jour et les ajustements de configuration.

Adieu définitif au System V et à la dépendance totale aux disques natifs

L'un des changements les plus marquants de systemd 260 est la suppression totale de la prise en charge des scripts System V. Le processus de démarrage classique basé sur /etc/init.d avait été progressivement abandonné depuis des années, mais il disparaît désormais complètement du code de systemd.

Cela signifie que les composants assurant la liaison entre les scripts SysV et les unités natives ont été supprimés : systemd-rc-local-generator, rc-local.service, systemd-sysv-generator et systemd-sysv-install n’existent plus. Par conséquent, tout service dépendant encore de ces mécanismes hérités ne pourra tout simplement pas démarrer sur les systèmes adoptant systemd 260.

Lors du nettoyage, plusieurs options de compilation de Meson ont été jugées obsolètes ou supprimées. Les options ` -Drc-local=`, `-Dsysvinit-path=` et `-Dsysvrcnd-path=` ont été archivées, tandis que d'autres, comme `-Dintegration-tests=` et `-Dcryptolib=`, ont été purement et simplement supprimées. Le message est clair : tout doit désormais être géré par les unités natives et l'infrastructure systemd moderne.

Pour de nombreuses infrastructures européennes qui reposent encore sur des composants anciens, ce changement implique une révision des services internes, des scripts personnalisés et des déploiements existants. La migration vers des fichiers unitaires bien définis n'est plus seulement recommandée ; elle est désormais indispensable pour continuer à exécuter des services sur les distributions intégrant systemd 260.

Des exigences plus élevées au niveau du noyau et une attention particulière portée aux environnements actuels

Cette nouvelle version rehausse les exigences concernant le noyau : désormais, la version minimale de Linux prise en charge est la 5.10 , ce qui rend obsolètes les branches très anciennes comme la 5.4. De plus, le projet indique qu’idéalement, les utilisateurs devraient travailler avec un noyau 5.14 ou supérieur , et recommande tout particulièrement la série 6.6 pour profiter pleinement de toutes les fonctionnalités disponibles.

Cette augmentation des exigences ne pose généralement pas de problème dans les distributions modernes, mais elle peut compliquer les choses dans les environnements très conservateurs ou les solutions embarquées maintenues depuis de nombreuses années. Avant de passer à systemd 260, il est conseillé de vérifier le noyau utilisé, notamment dans les centres de données européens avec des déploiements à long terme ou des images personnalisées.

À l'opposé, les distributions à mise à jour continue comme Arch Linux ou openSUSE Tumbleweed, très prisées par ceux qui souhaitent bénéficier des dernières fonctionnalités, intègrent rapidement les nouveaux noyaux et les nouvelles branches de systemd. D'autres, comme Fedora, maintiennent une certaine stabilité de la version majeure de systemd tout au long du cycle de vie de chaque version, ce qui laisse plus de temps pour planifier les migrations.

TPM2, intégrité du démarrage et prise en charge avancée de SRK

L'un des domaines où systemd évolue le plus est son intégration avec le TPM2 (Trusted Platform Module 2.0) . Cette puce, de plus en plus répandue sur les cartes mères UEFI modernes et les matériels de milieu et haut de gamme, permet d'ancrer les secrets à l'état du système, de mesurer les phases de démarrage et de déverrouiller automatiquement les volumes chiffrés lorsque l'environnement est conforme aux attentes.

Systemd 260 renforce cette intégration en ajoutant des outils et des services couvrant différentes étapes du processus de démarrage. Un composant clé est systemd-tpm2-setup , chargé de préparer l'infrastructure autour de la clé racine de stockage (SRK) du TPM . Cette clé racine constitue le fondement cryptographique de la sécurisation des communications avec la puce et du stockage sécurisé d'autres données sensibles.

Au démarrage, deux phases se distinguent : une première, très précoce, dans l’initrd, et une seconde, une fois dans le système racine. Dans la première, un service nommé « Configuration initiale de la clé SRK du TPM » vérifie si le TPM possède déjà une clé SRK enregistrée. Si ce n’est pas le cas, il la crée et la rend temporairement disponible sous /run/systemd/tpm2-srk-public-key.* . Plus tard, une fois le système de fichiers réel monté, ce service consolide la clé SRK et vérifie que la clé stockée dans /var/lib/systemd/tpm2-srk-public-key.pem correspond à celle du TPM.

Dans une configuration optimale, des entrées de journal telles que « SRK est déjà stocké dans le TPM » et des messages indiquant que l'empreinte SRK correspond à celle attendue s'afficheront. Cependant, si l'environnement est mal configuré (par exemple, avec Yocto ou sur des cartes comme le Raspberry Pi doté d'un TPM SPI et de méthodes de démarrage personnalisées telles que U-Boot et le démarrage mesuré), il est possible que systemd ne parvienne pas à créer ces fichiers dans /var/lib/systemd, ce qui soulève des doutes quant à la configuration correcte de SRK.

Lorsque l'état du TPM change, que des partitions sont modifiées ou que la séquence de démarrage est altérée, la stratégie associée peut ne plus être valide. Dans ce cas, certains administrateurs recommandent d'effacer l'emplacement ou la stratégie du TPM et de réenregistrer la clé , en suivant une procédure similaire à celle décrite dans les guides de chiffrement de disque avec TPM pour des environnements comme openSUSE. Ces guides expliquent comment recréer la stratégie PCR et rétablir le déverrouillage du volume.

Outre le SRK, une autre amélioration pratique réside dans l'introduction d'un utilitaire interne appelé tpm2_id dans udev . Cet outil intégré s'exécute lorsque le système détecte un périphérique TPM2 et extrait automatiquement l'identifiant du fabricant et du modèle . Cela simplifie l'inventaire du matériel de sécurité, ce qui s'avère très utile pour les administrations publiques, les entreprises réglementées ou les infrastructures critiques où il est essentiel de connaître précisément les modules TPM déployés.

L'intégration avec l'infrastructure de mesure du démarrage est renforcée par des unités spécifiques comme systemd-pcrextend , qui enregistrent des événements tels que « enter-initrd », « leave-initrd », « sysinit » et « ready » dans différents PCR (par exemple, PCR 11). Cette séquence d'extensions permet au TPM d'accumuler un enregistrement cryptographiquement vérifiable du flux de démarrage, qui peut ensuite être utilisé pour les politiques de démarrage sécurisé ou pour les UKI (Unified Kernel Images) afin de valider l'état de la machine avant la libération des clés.

Mesures de sécurité et mise en sandbox des services avec systemd

Systemd ne se contente pas de lancer des processus ; il offre également un ensemble complet de directives de sandboxing pour isoler les services et limiter les dégâts en cas de compromission. Cette approche de « défense en profondeur » repose sur les cgroups, les espaces de noms, les capacités du noyau et les filtres d’appels système (seccomp).

Pour évaluer la sécurité d'un service spécifique, systemd inclut l' outil de sécurité systemd-analyze . Son exécution génère un rapport avec un score d'exposition sur une échelle de 0 à 10, un score plus bas étant le meilleur. Ce rapport détaille les protections activées ou désactivées (isolation du réseau, accès au système de fichiers, accès aux périphériques, etc.), ce qui facilite l'identification des paramètres manquants et permet de vérifier si les modifications apportées améliorent réellement le score.

Au lieu de modifier l'unité d'origine (qui serait perdue lors des futures mises à jour du package), il est recommandé de créer un Commande en /etc/systemd/system/mi-servicio.service.d/ avec un fichier, par exemple, sandbox.confAprès l'avoir modifiée, il suffit de recharger la configuration avec démon systemctl-recharger et redémarrez le service pour que les nouvelles restrictions prennent effet.

Au niveau du système de fichiers, l'une des options les plus importantes est Système de protection=Des valeurs telles que strict, full o true Ils montent différentes parties de l'arbre en mode lecture seule. La pratique courante, lorsque cela est possible, consiste à utiliser ProtectSystem=strictCela rend les répertoires /usr, /boot, /efi et /etc accessibles en lecture seule pour le service. Si une application a besoin d'écrire dans des répertoires spécifiques, elle est autorisée à le faire en utilisant ReadWritePaths=/chemin dans l'unité.

Pour renforcer la confidentialité, il est également recommandé de restreindre l'accès aux répertoires utilisateur à l'aide de `ProtectHome=true` , ce qui empêche le service de lire `/home`, `/root` ou `/run/user`. De plus, `PrivateTmp=true` crée des espaces isolés `/tmp` et `/var/tmp`, empêchant ainsi la visibilité croisée des fichiers temporaires entre les processus.

Dans la configuration des périphériques, `PrivateDevices=true` masque l'arborescence `/dev` réelle et la remplace par un ensemble minimal de pseudo-périphériques sécurisés (null, zéro, aléatoire, etc.). Si un lecteur nécessite un périphérique spécifique (par exemple, un port série ou un bloc de disque), il peut être autorisé à l'aide de `DeviceAllow=/dev/xxx rw` ou en mode lecture seule.

Le réseau est également un vecteur clé. Réseau privé=vrai Un espace de noms réseau isolé est créé, ne conservant que l'interface de bouclage ; le service ne verra pas les interfaces physiques et ne pourra pas communiquer avec l'extérieur. Vous pouvez également limiter les familles d'adresses qu'il peut utiliser en RestrictAddressFamilies=n'autoriser que AF_INET et AF_INET6 pour IPv4/IPv6, AF_UNIX pour les sockets locaux ou même none pour japoniser pleinement les capacités du réseau.

Concernant les privilèges, la directive `NoNewPrivileges=true` est l'une des plus efficaces : elle empêche le processus d'acquérir de nouveaux privilèges via des binaires setuid ou des modifications de capacités. En bref, même si le service exécute du code vulnérable, il ne devrait pas pouvoir obtenir les privilèges root par les mécanismes traditionnels. Combinée à `CapabilityBoundingSet=` , qui définit la liste exacte des capacités autorisées (par exemple, seules les capacités `CAP_NET_BIND_SERVICE` peuvent écouter sur les ports bas), la surface d'attaque est minimisée.

Pour aller encore plus loin, systemd permet de filtrer les appels système avec SystèmeCallFilter=Au lieu de tenir une liste manuelle des appels système, on utilise des groupes prédéfinis, tels que : @system-service, @network-io, @basic-io ou refuser des groupes comme ~@privileged. avec filtre d'appels système systemd-analyze Il est possible d'examiner quels appels spécifiques appartiennent à chaque groupe. Cela permet de construire un profil d'exécution très limité, similaire à celui qu'offrirait un environnement d'exécution isolé dédié.

Parmi les autres paramètres pertinents, citons `ProtectKernelTunables=true` , qui bloque la modification des paramètres du noyau dans `/proc/sys` et `/sys` ; `ProtectKernelModules=true` , qui empêche le chargement et le déchargement de modules ; `ProtectKernelLogs=true` , qui empêche la lecture des journaux du noyau ; et `ProtectControlGroups=true` , qui bloque les écritures dans la hiérarchie des cgroups. L'ensemble de ces paramètres fonctionne parfaitement avec les nouvelles fonctionnalités d'isolation des utilisateurs, telles que ` PrivateUsers=full` , qui, dans la version 260, a été mis à jour pour couvrir l'ensemble des identifiants utilisateur, éliminant ainsi les solutions de contournement nécessaires auparavant pour les environnements systemd imbriqués.

PrivateUsers, xaccess et nouveaux contrôles d'accès aux appareils

Le mécanisme PrivateUsers , conçu pour permettre aux services de s'exécuter dans un espace d'identifiants utilisateur isolé, est consolidé dans systemd 260. L' option PrivateUsers=full couvre désormais l'ensemble des identifiants, simplifiant ainsi la gestion des conteneurs et des systèmes comportant des instances systemd imbriquées basées sur des versions antérieures (avant la version 257). Cette amélioration a permis d'éliminer les solutions de contournement utilisées auparavant pour détecter ces anciennes instances.

Parallèlement, des composants comme systemd-logind et systemd-udevd ont introduit le concept de xaccess . Ce mécanisme complète la logique classique de uaccess , qui accorde l'accès à certains périphériques (audio ou vidéo, par exemple) aux utilisateurs disposant d'une session graphique active sur la machine locale. Avec xaccess, les permissions peuvent être déléguées à des utilisateurs distants disposant de sessions spécialement marquées , de sorte que, par exemple, un utilisateur connecté via un bureau à distance puisse accéder aux périphériques de rendu GPU locaux sans accorder de permissions étendues à l'ensemble du système.

La configuration de ces sessions repose sur des variables d'environnement exposées via PAM, notamment PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , permettant de définir les périphériques concernés. Cette approche est parfaitement conforme aux exigences réglementaires et de protection des données de l'Union européenne, qui imposent une granularité et une traçabilité strictes pour l'accès au matériel sensible.

mstack, systemd-mstack et nouveaux outils de conteneurisation

Dans le domaine de la conteneurisation, systemd 260 introduit la fonctionnalité mstack et une commande associée, systemd-mstackL'idée derrière mstack est de permettre la définition d'un SuperpositionFS basé sur la structure d'un répertoire spécial appelé .mstack/, qui suit une spécification particulière pour l'organisation de ses couches.

Le nouvel outil en ligne de commande, systemd-mstack, simplifie la manipulation interactive des systèmes de fichiers, offrant une plus grande flexibilité pour la configuration d'environnements multicouches pour les conteneurs ou les services hautement isolés. Cette fonctionnalité est également liée aux améliorations apportées à systemd-importd , qui étend sa prise en charge du téléchargement et de la gestion des images OCI , renforçant ainsi le rôle de systemd en tant que moteur de conteneurisation et de sandbox, une pratique courante chez les fournisseurs de cloud européens et les plateformes d'hébergement modernes.

Réseau : Intégration avec ModemManager et nouvelles options de performance

Au niveau réseau, systemd-networkd continue de gagner en importance. Parmi ses nouvelles fonctionnalités notables figure son intégration avec ModemManager via le protocole « simple connect » , qui permet de gérer les modems et les connexions mobiles directement depuis networkd, sans avoir recours à des outils externes.

Pour faciliter ce processus, une nouvelle section a été ajoutée. aux fichiers de configuration, avec des paramètres tels que APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Cela facilite les déploiements dans zones rurales ou environnements dotés d'une connectivité basée sur les réseaux mobiles, très présentes dans certains territoires d'Europe où la fibre optique ou les lignes téléphoniques fixes de qualité ne sont pas toujours disponibles.

En termes de performances, les fichiers .link de systemd-networkd incluent de nouvelles options spécifiques aux périphériques Ethernet. Il s'agit notamment de ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList et GenericReceiveOffloadUDPForwarding . Ces options permettent d'optimiser la répartition des tâches entre le matériel et les pilotes, ce qui est crucial pour les réseaux d'entreprise, les centres de données et les fournisseurs de services qui doivent minimiser chaque milliseconde de latence.

De plus, les interfaces Varlink et JSON de systemd-networkd peuvent désormais afficher les adresses IP dans un format lisible (chaînes de caractères) tout en conservant leur représentation sous forme de tableau d'entiers. Ceci simplifie l'intégration avec les tableaux de bord de supervision, les scripts de gestion ou les outils tiers qui préfèrent éviter les formats numériques complexes.

Portabilité des services, machines virtuelles éphémères et services non privilégiés

Le composant systemd-portabled , chargé de gérer les services « portables » inclus dans les images, bénéficie d'une fonctionnalité très intéressante : il peut désormais s'exécuter comme un service utilisateur . Cela signifie que les utilisateurs sans privilèges, dans leur session normale, peuvent lancer et gérer des services portables dans leur propre espace sans avoir recours à sudo ni à des privilèges élevés.

De plus, à partir de cette version, portabled peut générer des politiques et verrouiller l'image associée à un service portable , empêchant ainsi toute modification de cette image sans la rattacher. Les utilisateurs peuvent ainsi configurer des environnements autonomes avec des garanties d'immuabilité accrues, une fonctionnalité particulièrement intéressante pour les laboratoires, les environnements de développement et les environnements de test isolés.

Par ailleurs, systemd-vmspawn , l'outil conçu pour lancer des machines virtuelles de manière intégrée à systemd, étend ses fonctionnalités pour permettre l'enregistrement auprès de systemd-machined au sein de la session utilisateur . Il introduit également une option `-ephemeral` pour créer des machines éphémères qui sont détruites une fois leur utilisation terminée. Cette solution est parfaitement adaptée aux pipelines CI/CD, aux classes virtuelles et aux plateformes éducatives européennes qui nécessitent la création et la destruction rapides et contrôlées de machines virtuelles.

Contrôle précis du processeur, de la mémoire et de la planification grâce à SCHED_EXT et THP

Systemd 260 explore également le contrôle des performances grâce à de nouvelles politiques. L'option de service Stratégie d'ordonnancement du processeur = acceptez maintenant la valeur ext, qui active le planificateur SCHED_EXTCe planificateur alternatif ouvre la porte à expérimentations avec différentes politiques de planification aux normes du noyau, ce qui peut présenter un intérêt dans les laboratoires de R&D ou dans des déploiements hautement spécialisés.

Dans la section mémoire, vous trouverez `MemoryTHP=` , qui vous permet de gérer l'utilisation des pages transparentes volumineuses (THP) pour chaque service. Au lieu d'un paramètre global pour l'ensemble du système, vous pouvez décider si une unité spécifique doit utiliser les THP, les désactiver ou adopter des modes intermédiaires. Pour les applications critiques dans les secteurs bancaire, de l'assurance ou gouvernemental, ce contrôle précis peut avoir un impact significatif sur la latence, la consommation de mémoire et les performances.

Nouvelles commandes dans systemctl et utilisation étendue de Varlink

La commande systemctl, déjà bien connue, s'enrichit d'une nouvelle fonctionnalité : enqueue-marked . Cette action invoque en interne la méthode D-Bus EnqueueMarkedJobs() et permet de gérer des files d'attente de tâches et de services pré-marqués. Bien que cela puisse paraître un détail, pour les équipes d'exploitation qui gèrent des fermes de serveurs à grande échelle, il s'agit d'un outil supplémentaire pour optimiser les flux de déploiement et d'automatisation.

En parallèle, le projet continue de développer l'utilisation de Varlink comme mécanisme de communication entre les composants. De nombreuses parties de systemd exposent des interfaces Varlink stables, facilitant ainsi l'intégration avec des outils externes, des tableaux de bord personnalisés ou des agents de surveillance nécessitant un accès structuré aux informations système.

Champs d'identification du système et expérience utilisateur

Une nouvelle fonctionnalité curieuse mais utile pour certaines distributions est l'introduction du champ NOM_FANTAISIE= dans l'archive /etc/os-releaseCe champ ressemble à PRETTY_NAME, mais permet Séquences ANSI et caractères Unicode plus élaborésGrâce à cela, des distributions et éditions spécifiques peuvent être présentées sous des noms plus accrocheurs ou distinctifs.

La valeur de FANCY_NAME peut être consultée via le gestionnaire systemd, à l'aide de systemd-hostnamed ou en interrogeant hostnamectl . Bien qu'il s'agisse d'une modification mineure, elle peut s'avérer utile dans les environnements de bureau et les panneaux d'administration graphiques pour identifier rapidement le système géré, notamment lors de la gestion de nombreuses variantes.

Documentation spécifique pour les agents d'IA et le flux de travail de révision assistée

L'un des signes les plus intéressants de l'évolution de systemd est l'apparition d'une documentation spécifiquement dédiée aux agents d'intelligence artificielle . Le dépôt inclut un fichier AGENTS.md , conçu pour aider les outils d'analyse de code et les assistants de programmation, ainsi que des guides techniques , à mieux comprendre l'architecture, le style, le flux de développement et les directives de contribution du projet.

Ce document décrit les composants, les chemins de compilation, la procédure d'exécution des tests et des intégrations, ainsi que les recommandations pour la génération de correctifs valides. L'objectif est de fournir aux agents d'IA chargés d'examiner le code ou d'y apporter des modifications une solide compréhension de l'organisation de systemd , afin de réduire les erreurs et les suggestions inappropriées.

À côté d'AGENTs.md se trouve un fichier nommé CLAUDE.md , qui fait explicitement référence au premier et est conçu pour guider l'outil Claude Code, l'un des assistants de développement basés sur l'IA les plus utilisés. De cette manière, le projet intègre explicitement l'IA à son cycle de développement.

De plus, un fichier de configuration est inclus. claude-review.ymlCe document définit comment le processus d'analyse des demandes de modification (pull requests) doit être examiné à l'aide de Claude Code. Dans ce contexte, les contributions ayant utilisé l'IA sont tenues de s'intégrer. étiquettes de divulgation como Co-developed-by dans les correctifs, laissant la preuve qu'un outil automatisé a participé à la création du code.

Grâce à cet ensemble complet de modifications – amélioration de la prise en charge des systèmes hérités, optimisation du sandboxing, optimisation de TPM2 et SRK, intégration réseau avancée, nouvelles fonctionnalités de portabilité et documentation conçue pour les agents intelligents – systemd 260 renforce son rôle central dans l'écosystème Linux moderne. Pour les administrateurs et les développeurs en Espagne et en Europe, le défi immédiat consiste à examiner les noyaux, à adapter les configurations de démarrage et les services, et à tirer parti de ces fonctionnalités pour construire des infrastructures plus sécurisées et automatisées, en adéquation avec l'utilisation actuelle des systèmes.