Renforcer la sécurité des services systemd (hardening)

• systemd fournit de puissantes fonctions de gestion des services, mais sa configuration par défaut est optimisée pour l’utilisabilité plutôt que pour la sécurité, d’où la nécessité d’appliquer des options de hardening dédiées
• La commande systemd-analyze security permet d’analyser les indicateurs d’exposition en matière de sécurité pour l’ensemble des services ou pour un service précis, et d’établir des priorités
• Il existe de nombreuses options de sécurité applicables au niveau de l’unité de service, modifiables individuellement via /etc/systemd/system/ServiceName.service.d/override.conf et autres fichiers similaires
• Parmi les principales options figurent ProtectSystem, PrivateTmp, NoNewPrivileges, SystemCallFilter, MemoryDenyWriteExecute, qui limitent les privilèges des processus et l’accès aux ressources
• Plutôt que de viser une sécurité parfaite, il est possible de réduire les risques en durcissant en priorité les services exposés vers l’extérieur, avec un effet également très bénéfique dans les environnements self-hosting

---

Vue d’ensemble de systemd

• systemd propose une approche très aboutie et robuste pour la gestion des services
• Toutefois, ses paramètres par défaut privilégient l’usage immédiat plutôt que la sécurité, et restent donc relativement permissifs
• Ce document présente plusieurs options de renforcement de la sécurité applicables aux unités de service systemd et à podman quadlet, afin de réduire les possibilités de compromission et de limiter l’ampleur des dégâts en cas d’incident
• Il ne s’agit pas d’un guide à appliquer uniformément à tous les services : chaque service exige des tests, une vérification des logs et des ajustements en fonction de ses caractéristiques et de ses besoins
• La responsabilité de la sécurité de l’infrastructure incombe entièrement à l’exploitant ; ce document n’est qu’un outil de référence

Analyse de sécurité de systemd

• La commande systemd-analyze security permet de vérifier l’état de sécurité global des services ou d’analyser la configuration détaillée d’un service donné (par ex. sshd.service)
  • La sortie inclut l’état des contrôles, le nom de la fonctionnalité, sa description et un score d’exposition ; plus l’Exposure est élevé, plus le risque est important
• Les options de sécurité peuvent être ajoutées dans la section [Service] (systemd) ou [Container] (podman quadlet)
• Il est recommandé de créer un fichier d’override via systemctl edit ServiceName.service ; en cas d’échec, il faut vérifier puis ajuster les autorisations nécessaires

Options de sécurité des services

• systemd fournit divers mots-clés d’options de sécurité, consultables notamment via man systemd.exec 5, man capabilities 7, etc.
• Options de sécurité représentatives
  • ProtectSystem → option qui limite le système de fichiers en lecture seule
  • ProtectHome → option qui bloque l’accès à /home, /root, /run/user
  • PrivateDevices → option qui bloque l’accès aux périphériques physiques et n’autorise que les périphériques virtuels comme /dev/null
  • ProtectKernelTunables, ProtectKernelModules, ProtectKernelLogs → options qui bloquent l’accès aux ressources du noyau
  • NoNewPrivileges → option qui empêche l’obtention de nouveaux privilèges via setuid/setgid, etc.
  • MemoryDenyWriteExecute → option qui empêche l’usage simultané de mémoire inscriptible et exécutable ; cela peut poser problème à certains langages avec JIT
  • SystemCallFilter → option qui limite les appels système autorisés ; en cas de violation, le processus peut être terminé ou recevoir un retour EPERM

Description de chaque option

• ProtectSystem : avec le réglage strict, l’ensemble du système de fichiers est monté en lecture seule ; /dev, /proc, /sys nécessitent des options de protection distinctes
• ReadWritePaths : permet de réautoriser l’écriture uniquement sur certains chemins
• ProtectHome : bloque l’accès à /home, /root, /run/user
• PrivateDevices : désactive l’accès aux périphériques physiques et n’autorise que des pseudo-périphériques comme /dev/null
• ProtectKernelTunables : passe /proc et /sys en lecture seule
• ProtectControlGroups : n’autorise qu’un accès en lecture seule aux cgroups
• ProtectKernelModules : interdit le chargement explicite de modules du noyau
• ProtectKernelLogs : restreint l’accès au tampon des logs du noyau
• ProtectProc : avec invisible, masque dans /proc/ les processus appartenant à d’autres utilisateurs
• ProcSubset : bloque dans /proc le contenu autre que certains éléments liés au PID
• NoNewPrivileges : bloque toute nouvelle élévation de privilèges via setuid, setgid ou les capabilities du système de fichiers
• ProtectClock : bloque l’écriture sur l’horloge système/matérielle
• SystemCallArchitectures : avec native, n’autorise que les syscalls natifs comme x86-64
• RestrictNamespaces : limite les namespaces spécifiques aux conteneurs
• RestrictSUIDSGID : empêche le positionnement des bits setuid et setgid sur les fichiers
• LockPersonality : empêche le changement de domaine d’exécution (utile seulement pour certaines anciennes applications)
• RestrictRealtime : limite l’ordonnancement temps réel (nécessaire uniquement pour certains services spécialisés)
• RestrictAddressFamilies : limite les familles d’adresses socket autorisées (par ex. AF_INET, AF_INET6, AF_UNIX, etc.)
• MemoryDenyWriteExecute : bloque la création de nouvelles zones mémoire à la fois inscriptibles et exécutables (prudence pour les services utilisant du JIT)
• ProtectHostname : interdit l’usage des syscalls sethostname, setdomainname
• SystemCallFilter : permet de définir, service par service, les syscalls autorisés/interdits, avec un filtrage fin
  • Les groupes, syscalls individuels et modes autorisation/interdiction peuvent être ajustés
  • En cas de violation, il est aussi possible de renvoyer un code d’erreur comme EPERM au lieu de terminer le processus
  • La liste complète est disponible via systemd-analyze syscall-filter ou man systemd.exec(5)
  • Le préfixe ~ permet de négativer l’ensemble d’une liste (ex. CapabilityBoundingSet=~CAP_SETUID etc.)

Processus d’ajustement des restrictions SystemCallFilter

• Avec auditd, il est possible de consulter les logs pour voir quel syscall a été bloqué lorsqu’un service échoue
  • Exécuter sudo ausearch -i -m SECCOMP -ts recent, puis vérifier la valeur du syscall
  • Il est ensuite possible d’ajouter ce syscall ou le groupe concerné à SystemCallFilter afin de résoudre le problème progressivement

Priorités d’application du hardening et conseils d’exploitation

• Il n’est pas nécessaire de tout appliquer à tous les services
• Le modèle de menace et la gestion du risque sont essentiels ; en particulier, les services exposés vers l’extérieur (httpd, nginx, ssh, etc.) doivent être considérés en priorité
• Il est aussi efficace d’appliquer ces mesures de façon préventive aux commandes personnalisées, aux unités timer (remplaçantes de cron), etc.
• Plus un service est simple, plus il est généralement possible d’effectuer des ajustements fins

Checklist : combinaison d’options de sécurité recommandée (priorité d’application initiale)

• ProtectSystem=strict
• PrivateTmp=yes
• ProtectHome=yes ou ProtectHome=tmpfs
• ProtectClock=yes, ProtectKernelLogs=yes, ProtectKernelModules=yes
• RestrictSUIDGUID=yes
• UMask=0077
• LockPersonality=yes
• RestrictRealtime=yes
• MemoryDenyWriteExecute=yes
• DynamicUser=yes ou définir User sur un utilisateur spécifique autre que root

• Les éléments ci-dessus constituent en général une combinaison utilisable sans presque aucun impact sur le service
• L’ajout d’un filtrage des syscalls (SystemCallFilter) nécessite en revanche des tests détaillés

Exemple de configuration Traefik

• Il s’agit d’un exemple d’exécution d’un service Traefik conteneurisé avec systemd quadlet, en appliquant de nombreuses options de sécurité
  • ProtectSystem=full, ProtectHome=yes, SystemCallFilter=@system-service @mount @privileged, etc.
  • CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP retire certains privilèges spécifiques
  • RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX AF_NETLINK, etc., applique des limitations d’accès réseau

Conclusion

• Les options de hardening de systemd constituent un moyen pratique à garder dans la boîte à outils de tout administrateur système Unix
• Il ne faut pas les considérer comme une solution de sécurité parfaite, mais comme un outil de réduction du risque ; il n’est pas nécessaire d’appliquer indistinctement des réglages de sécurité à tous les services
• Elles peuvent être particulièrement utiles aux administrateurs d’environnements self-hosting pour améliorer nettement leur niveau de sécurité
• En privilégiant la « praticité plutôt que la perfection », il est recommandé de les appliquer au moins partiellement, dans la mesure adaptée au travail et à l’environnement