Durcissement des services systemd : ce que le score d'exposition ne vous dit pas

Lancez systemd-analyze security sur une machine ordinaire et vous obtenez un tableau de services avec un nombre en face de chacun. Il est tentant de lire ce nombre comme un verdict. La page de manuel dit, en des termes inhabituellement directs, que ce n’en est pas un.

Ce que la commande mesure réellement

systemd-analyze security inspecte les réglages de sécurité et de sandboxing des unités de service. Si on lui donne un nom d’unité, elle affiche une analyse détaillée ; si on ne lui en donne aucun, elle inspecte toutes les unités de service de longue durée actuellement chargées et imprime un tableau succinct.

Elle attribue à chaque réglage pertinent un exposure level (niveau d’exposition) chiffré, puis calcule une valeur globale pour l’unité. La documentation décrit cela comme « une estimation dans l’intervalle 0.0…10.0 indiquant à quel point un service est exposé du point de vue de la sécurité ». Les valeurs élevées signifient que très peu de sandboxing a été appliqué. Les valeurs basses signifient un sandboxing serré et de fortes restrictions.

Jusqu’ici, cela ressemble à un scanner. La partie importante, c’est l’avertissement qui suit.

Les trois limites que le manuel énonce sans détour

L’outil ne voit que ce que systemd implémente lui-même. La documentation est explicite : la commande « analyse uniquement les fonctions de sécurité par service que systemd lui-même implémente », ce qui signifie que « tout mécanisme de sécurité supplémentaire appliqué par le code du service lui-même n’est pas pris en compte ». Un service qui abandonne ses privilèges en interne, se place lui-même dans un chroot ou applique son propre filtre seccomp n’obtient aucun crédit.

Un score élevé ne signifie pas vulnérable. Cette phrase mérite d’être citée en entier, parce que c’est celle que tout le monde saute : un exposure level élevé « ne signifie ni qu’aucun sandboxing effectif n’est appliqué par le code du service lui-même, ni que le service est réellement vulnérable à des attaques distantes ou locales ». Ce qu’il indique, c’est que le service « pourrait bénéficier de réglages supplémentaires ».

Les réglages pris isolément peuvent être défaits. Le manuel avertit que de nombreux réglages de sandboxing « peuvent individuellement être contournés » s’ils ne sont pas combinés à d’autres. Il donne un cas concret : un service qui conserve le privilège d’établir ou de défaire des points de montage peut annuler depuis son propre code beaucoup des autres options de sandboxing. L’outil tient compte de certaines de ces relations, mais la documentation dit clairement qu’il ne les prend pas toutes en compte.

Pourquoi « combinés » est le mot qui compte

L’exemple des points de montage vaut qu’on s’y arrête, parce qu’il change la façon dont vous devriez lire vos propres résultats.

Si une unité peut manipuler les points de montage, alors des restrictions exprimées sous forme de visibilité du système de fichiers peuvent potentiellement être renversées par le service lui-même. La restriction est toujours déclarée, et le score la compte toujours, mais sa valeur pratique dépend de la présence d’un autre réglage à ses côtés.

C’est pourquoi l’approche par liste de contrôle donne des résultats décevants. Choisir les trois directives qui font baisser le score le plus vite peut laisser une configuration qui obtient un bon score et tient mal. La conclusion de la documentation elle-même est que chaque service devrait utiliser « les réglages de sandboxing et de sécurité les plus complets et les plus stricts possibles », et non une sélection d’entre eux.

Comment utiliser le score sans le mésinterpréter

Une lecture exploitable, cohérente avec ce que le manuel revendique pour l’outil :

Traitez-le comme un inventaire, pas comme un audit. Il vous dit quelles protections au niveau de systemd sont absentes. C’est réellement utile et peu coûteux à obtenir. Il ne vous dit pas si un service est sûr.

Comparez-vous à vous-même dans le temps. L’usage le plus fiable est la détection de régression : une unité dont l’exposure level augmente après une mise à jour de paquet ou un changement de configuration mérite investigation. Cette comparaison a du sens même si le nombre absolu n’est pas un verdict.

Ne classez pas des services tiers d’après leur score. Deux services affichant le même nombre peuvent avoir une exposition réelle très différente, parce que l’outil ne peut pas voir le sandboxing que l’un d’eux applique en interne. Les classer par le score reviendrait à récompenser celui qui déclare le plus et à punir celui qui fait le plus.

Commencez par les unités réellement atteignables. Un service exposé au réseau avec un exposure level élevé n’est pas la même affaire qu’un timer local affichant le même nombre. Le score ne sait pas lequel est lequel ; vous, si.

Le résumé honnête

systemd-analyze security est un bon outil qui se décrit avec exactitude, ce qui est plus rare que ça ne devrait l’être. Il mesure le sandboxing au niveau de systemd que vous avez déclaré, sur une échelle de 0 à 10, et il dit explicitement qu’un nombre élevé n’est pas un constat de vulnérabilité et qu’un nombre bas n’est pas un certificat de bonne santé.

Utilisez-le pour trouver les protections manquantes et pour attraper les régressions. Combinez les réglages plutôt que de choisir les moins coûteux, puisque le manuel avertit que des restrictions isolées peuvent être défaites depuis l’intérieur du service. Et gardez à l’esprit que le nombre décrit votre configuration, pas votre surface d’attaque.

Pour la couche située en dessous de celle-ci, notre guide de durcissement Linux couvre les paramètres du noyau, sysctl et le contrôle d’accès obligatoire.

La description de la commande, l’intervalle d’exposition 0.0 à 10.0, les trois limites énoncées et l’exemple des points de montage sont tirés de la page de manuel systemd-analyze telle que livrée avec systemd 255. La formulation et le comportement peuvent changer d’une version de systemd à l’autre ; consultez le manuel de la version que vous utilisez. Cet article ne comporte aucun exemple de sortie de commande, parce que l’environnement utilisé pour l’écrire n’exécute pas systemd en PID 1, et qu’en inventer une reviendrait à donner une fausse représentation d’un résultat réel.