Renforcement de la sécurité systemd avec des exemples pratiques : guide d'implémentation

Introduction

Des unités systemd durcies (systemd security) réduisent la surface d'attaque des services Linux en appliquant le principe du moindre privilège, en isolant fichiers et périphériques, en limitant les appels système et en contrôlant strictement l'exposition réseau. Ce guide propose un parcours pratique, avec des extraits copiables que vous pouvez adapter à des services existants ou nouveaux. Vous apprendrez à exécuter un service sous un compte non privilégié, à verrouiller l'accès au système de fichiers, à restreindre les capacités et les appels système (syscalls), à manipuler les secrets en sécurité, à limiter l'accès réseau et à valider vos changements à l'aide de vérifications sûres. Ces techniques s'appliquent à des services courants (par exemple un backend HTTP interne, un reverse-proxy Nginx, un job par lot) et s'intègrent naturellement à vos pratiques Linux, Bash et de gestion des logs.

Vue d'ensemble du workflow

Profiler le service : identifier l'utilisateur effectif, les chemins d'écriture requis, les ports d'écoute, et d'éventuels besoins noyau spécifiques.
Réduire les privilèges : exécuter sous un utilisateur/groupe dédié, supprimer les capacités Linux inutiles, bloquer l'escalade de privilèges.
Verrouiller le système de fichiers : le rendre en lecture seule par défaut, puis autoriser explicitement les chemins en écriture nécessaires.
Isoler périphériques et espaces de noms : retirer l'accès aux périphériques hôte et aux namespaces risqués.
Limiter les appels système et l'exécution en mémoire : appliquer des filtres de syscalls et éviter les violations W^X.
Contraindre le réseau : refuser tout par défaut, puis autoriser seulement ce qui est requis.
Gérer correctement les secrets : passer par des credentials ou des fichiers verrouillés, pas par des variables d'environnement en clair.
Vérifier et itérer : charger l'unité, lancer l'analyse de sécurité, tester la fonctionnalité, consulter les logs, et revenir en arrière proprement si besoin.

Exemples pratiques de durcissement

Utilisez ces extraits comme point de départ et adaptez-les à votre service. Les directives illustrent systemd hardening, systemd access control et systemd permissions.

1) Modèle de service durci de base

Hypothèse : un service TCP simple lié à localhost, qui doit écrire un état et des logs.

# /etc/systemd/system/myapp.service
[Unit]
Description=MyApp (durci)
After=network-online.target
Wants=network-online.target

[Service]
# Commande
ExecStart=/usr/local/bin/myapp --listen 127.0.0.1:8080

# Moindre privilège
User=myapp
Group=myapp
UMask=0077
NoNewPrivileges=yes
CapabilityBoundingSet=
AmbientCapabilities=

# Protections du système de fichiers
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectControlGroups=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectKernelLogs=yes

# Emplacements d'écriture gérés par systemd
StateDirectory=myapp
CacheDirectory=myapp
LogsDirectory=myapp
# Si vous devez autoriser d'autres écritures, déclarez-les
# ReadWritePaths=/var/lib/myapp /var/log/myapp

# Durcissement mémoire et personnalité
MemoryDenyWriteExecute=yes
LockPersonality=yes
RestrictRealtime=yes
RestrictSUIDSGID=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
# Liste d'autorisation prudente; ajustez selon l'app
SystemCallFilter=@system-service

# Contrôles réseau : refus par défaut, loopback uniquement
IPAddressDeny=any
IPAddressAllow=127.0.0.1
IPAddressAllow=::1
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX

# Environnement et credentials
EnvironmentFile=-/etc/myapp/myapp.env
# Fournir les secrets via credentials; lire avec $CREDENTIALS_DIRECTORY
# Le fichier doit être root: root, mode 0400 ou plus strict
LoadCredential=api_token:/etc/credentials/myapp_api_token

# Politique de redémarrage
Restart=on-failure
RestartSec=2s

[Install]
WantedBy=multi-user.target

Notes :

StateDirectory=, CacheDirectory= et LogsDirectory= créent des répertoires dédiés, appartenant à l'utilisateur du service, avec des permissions sûres. Préférez-les aux chemins ad hoc.
ProtectSystem=strict rend la plupart du système de fichiers en lecture seule. Autorisez les écritures nécessaires via les options XDirectory= ou ReadWritePaths=.
CapabilityBoundingSet= et AmbientCapabilities= vides suppriment toutes les capacités, sauf celles ajoutées explicitement.
IPAddressDeny=any combiné à IPAddressAllow= borne le trafic entrant et sortant.
SystemCallFilter= emploie un profil conservateur. Si le service casse, inspectez le journal et ajoutez les groupes de syscalls requis.

2) Service sans aucun accès réseau

# /etc/systemd/system/batch-job.service
[Unit]
Description=Tâche nocturne (isolée)
After=local-fs.target

[Service]
ExecStart=/usr/local/bin/batch-job
User=batch
Group=batch
UMask=0077
NoNewPrivileges=yes
CapabilityBoundingSet=
AmbientCapabilities=
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
PrivateDevices=yes
RestrictSUIDSGID=yes
MemoryDenyWriteExecute=yes
LockPersonality=yes
RestrictNamespaces=yes
SystemCallArchitectures=native
SystemCallFilter=@system-service
# Isolation réseau stricte
PrivateNetwork=yes
RestrictAddressFamilies=AF_UNIX
IPAddressDeny=any
StateDirectory=batch-job
LogsDirectory=batch-job
Restart=on-failure

3) Secrets transmis en sécurité avec credentials

Évitez de placer des secrets en clair dans les unités. Utilisez LoadCredential= et lisez depuis le répertoire des credentials.

# /etc/systemd/system/report.service
[Unit]
Description=Générateur de rapports

[Service]
ExecStart=/usr/local/bin/report --token-file "$CREDENTIALS_DIRECTORY/api_token"
User=report
Group=report
NoNewPrivileges=yes
CapabilityBoundingSet=
AmbientCapabilities=
ProtectSystem=strict
ProtectHome=yes
PrivateTmp=yes
LoadCredential=api_token:/etc/credentials/report_api_token
StateDirectory=report
LogsDirectory=report

Sur disque :

/etc/credentials/report_api_token doit être root: root et mode 0400.
Le service lit le secret depuis $CREDENTIALS_DIRECTORY/api_token à l'exécution. Cette approche renforce la gestion des systemd secrets tout en limitant l'exposition dans les logs et l'environnement.

4) Vérifications et validation sûres

Syntaxe et intégrité de l'unité :
systemd-analyze verify /etc/systemd/system/myapp.service
Charger les changements et redémarrer en sécurité :
systemctl daemon-reload
systemctl restart myapp.service
Inspecter les logs pour les refus et permissions manquantes :
journalctl -u myapp.service -b
Score de sécurité et pistes d'amélioration :
systemd-analyze security myapp.service
Confirmer la configuration effective :
systemctl show -p User, Group, NoNewPrivileges, CapabilityBoundingSet myapp.service
Vérifier l'exposition réseau :
ss -tulpn | grep 8080

Si un durcissement casse une fonctionnalité, revenez progressivement en arrière : commentez le dernier changement, rechargez et testez à nouveau. Ajoutez uniquement les permissions, capacités ou syscalls indispensables au rétablissement.

Plan pilote local

Objectif : appliquer un socle durci à un service non critique et vérifier localement avant un déploiement élargi.

Portée

Choisir un service avec des checks de santé clairs (par ex., un service HTTP interne sur localhost). Cette méthode s'applique aussi à des frontaux comme Nginx pilotés par systemd. Pour des conteneurs Docker démarrés via des units, isolez la partie systemd de la même manière.

Plan

Capturer le comportement actuel : utilisateur effectif, chemins en écriture, ports utilisés, variables d'environnement nécessaires.
Créer un drop-in d'override plutôt que de modifier l'unité fournisseur :

systemctl edit myapp.service
Ajouter : User=, Group=, NoNewPrivileges=yes, ProtectSystem=strict, PrivateTmp=yes, CapabilityBoundingSet=, IPAddressDeny=any avec allow sur loopback.

Ajouter StateDirectory= et LogsDirectory=, déplacer les écritures, retirer les chemins ad hoc.
Ajouter RestrictAddressFamilies= et SystemCallFilter=@system-service ; redémarrer et vérifier les logs pour les opérations refusées.
Remplacer les secrets inline par LoadCredential= et pointer l'app vers $CREDENTIALS_DIRECTORY.
Valider :

systemd-analyze security myapp.service et capturer le score avant/après.
Vérifs fonctionnelles : curl localhost:8080, écritures dans /var/lib/myapp, logs dans /var/log/myapp.
ss -tulpn confirme uniquement les écouteurs attendus.

Plan de rollback :

Conserver chaque changement séparément et commenté. En cas d'échec, retirer la dernière directive, daemon-reload, restart et re-tester.

Critères de sortie

Le service fonctionne de façon fiable en conditions normales.
Seuls les fichiers attendus sont en écriture.
Seuls les ports prévus sont exposés.
Le score de sécurité s'améliore sans briser la fonctionnalité.

Conclusion

Le durcissement des unités systemd (systemd hardening) offre des défenses fortes et reproductibles : moindre privilège, permissions explicites du système de fichiers, limites réseau strictes et gestion sûre des secrets. Démarrez par un petit pilote, mesurez les progrès et itérez. Comme socle durable, exécutez sous un utilisateur dédié, activez NoNewPrivileges=yes, retirez toutes les capacités sauf nécessité, mettez le système de fichiers en lecture seule par défaut, autorisez seulement les chemins d'écriture requis, restreignez les familles d'adresses et appliquez IPAddressDeny/Allow. Utilisez des credentials pour les secrets. Validez avec systemd-analyze verify et systemd-analyze security, observez le journal pour les refus et étendez le modèle aux autres services une fois stabilisé. Ainsi, vos services Linux bénéficient d'un contrôle d'accès systemd (systemd access control) et de permissions systemd (systemd permissions) clairs et faciles à maintenir.