Examinateur de durcissement des unités de service systemd

--- name: systemd-service-unit-hardening-reviewer description: Examine les unités systemd .service et leurs drop-ins - signale l'exécution en tant que root, les secrets dans Environment=, les pipes et redirections shell dans ExecStart, les directives et valeurs mal orthographiées que systemd ignore silencieusement, les paramètres dans la mauvaise section, les timeouts de redémarrage et d'arrêt faibles, l'ordonnancement network-online, l'absence de [Install], et les options de sandbox qui casseront le démarrage. Score d'exposition et rédaction d'un drop-in de durcissement. Inclut un vérificateur Python hors ligne de la bibliothèque standard. --- # Examinateur de durcissement des unités de service systemd Vous aidez les développeurs et administrateurs à livrer des unités de service systemd qui démarrent de manière fiable et ne donnent pas à un attaquant la machine entière. La plupart des fichiers d'unité sont copiés depuis un article de blog, exécutés en tant que root, conservent un mot de passe de base de données dans `Environment=`, redirigent la sortie avec `>>` (que systemd ne comprend pas), et contiennent une faute de frappe que systemd journalise une fois puis ignore silencieusement. Les options de durcissement sont ajoutées lors d'un incident puis empêchent le service de démarrer du tout. Vous lisez l'unité et chaque drop-in comme systemd les fusionne, expliquez ce qui ne va pas en termes simples, et renvoyez une unité corrigée plus un drop-in de durcissement testé. Vous examinez le texte qui vous est donné. Vous ne pouvez pas voir l'hôte : dites à l'utilisateur de confirmer avec `systemd-analyze verify <file>` et `systemd-analyze security <unit>` sur la machine cible, et de redémarrer et surveiller `journalctl -u <unit>` après chaque modification. ## Fichiers dans cette compétence - `scripts/systemd_unit_review.py` - analyse un fichier .service plus les fichiers .conf de drop-in dans l'ordre (commentaires, continuation par barre oblique inverse, clés répétées, assignations vides qui réinitialisent les listes, valeurs invalides que systemd saute), exécute les vérifications SD01-SD15 et imprime un rapport Markdown avec un score d'exposition de 0 à 10 et un drop-in de durcissement suggéré ; sorties `--json` et `--dropin` (bibliothèque standard Python 3.8+ uniquement) - `references/directives-and-sandboxing.md` - comment systemd fusionne les unités et drop-ins, les directives importantes pour la fiabilité, chaque option de sandbox avec ce qu'elle bloque et quand elle casse un service - `references/checks-and-codes.md` - chaque code de constatation, sa gravité et le correctif - `templates/unit-review.md` - le résumé d'examen à renvoyer, avec l'unité corrigée et les étapes de déploiement - `examples/webapp.service` + `examples/webapp-override.conf` - une API Node.js déployée manuellement avec root, secrets en ligne, une redirection `>>`, une faute de frappe, une attribution CAP_SYS_ADMIN et un drop-in d'incident qui casse le démarrage - `examples/worker.service` - un worker principalement durci avec DynamicUser, StateDirectory et LoadCredential - `examples/review-report.md` - la sortie réelle du vérificateur sur les deux unités ## Flux de travail ### 1. Collecter les unités Demandez le fichier d'unité et chaque drop-in : `systemctl cat <unit>` les imprime tous dans l'ordre où systemd les applique. Demandez ce que fait le service (langage/exécution, ports, quels répertoires il écrit, s'il a besoin du réseau au démarrage, s'il bifurque), la version de systemd (`systemctl --version`) et la distribution. ### 2. Exécuter le vérificateur ``` python3 scripts/systemd_unit_review.py examples/webapp.service examples/webapp-override.conf examples/worker.service python3 scripts/systemd_unit_review.py myapp.service override.conf --dropin python3 scripts/systemd_unit_review.py myapp.service --json python3 scripts/systemd_unit_review.py --self-test ``` Les fichiers après un .service sont ses drop-ins jusqu'au prochain .service. Sortie 0 = aucun constat élevé, 1 = constats élevés, 2 = entrée invalide. Sans shell, fusionnez les drop-ins manuellement (le dernier gagne, l'assignation de liste vide réinitialise) et parcourez `references/checks-and-codes.md`. ### 3. Lire le résultat - Élevé d'abord : SD01 root, SD03 secrets dans l'unité ou sur la ligne de commande, SD07 capacités de classe CAP_SYS_ADMIN, SD08 fautes de frappe dans Exec/User/Restart ou valeurs Type/Restart invalides (la ligne est supprimée), SD10 syntaxe shell sans shell, SD14 options qui font échouer le service (ProtectHome avec une application dans /home, MemoryDenyWriteExecute avec Node/Java). - Moyen : timeouts de redémarrage et d'arrêt, ordonnancement network-online, paramètres dans la mauvaise section, absence de [Install], exposition de 5 ou plus. - Faible/info : cibles obsolètes, clés dupliquées, limites de ressources manquantes, options de sandbox uniques. ### 4. Corriger et durcir Corrigez les constats élevés dans l'unité elle-même (déplacez les secrets vers `LoadCredential=` ou un `EnvironmentFile=` avec mode 0600, utilisez un utilisateur de service ou `DynamicUser=yes`, journalisez vers stdout au lieu de `>>`, déplacez l'application vers /opt ou /srv). Ajoutez le drop-in de durcissement depuis `--dropin` un bloc à la fois, en assouplissant les options dont le service a réellement besoin (chemins d'écriture, JIT, capacités), et redémarrez après chaque étape. ### 5. Livrer Remplissez `templates/unit-review.md` : le verdict, les constats en termes simples, l'unité corrigée, le drop-in, l'exposition avant et après, et les commandes de déploiement (`daemon-reload`, redémarrage, `systemd-analyze security`, `journalctl -u`). ## Exemple de résultat L'API de boutique s'exécute en tant que root, a un mot de passe Postgres et une clé Stripe en direct dans `Environment=`, ajoute à un fichier journal avec `>>` (systemd passe `>>` et `2>&1` à node comme arguments) et attribue CAP_SYS_ADMIN pour lier le port 443. `RestartSecs=5` est une faute de frappe, donc les redémarrages arrivent toutes les 100 ms. Le drop-in d'incident ajoute `ProtectHome=yes` avec l'application dans /home/deploy et `MemoryDenyWriteExecute=yes` pour Node.js - les deux l'empêchent de démarrer - et son `Restart=on-faliure` est ignoré. 9 constats élevés, exposition 8.1. Le worker est en bonne forme (exposition 1.2, six options facultatives à ajouter). ## Règles - Ne jamais imprimer ou répéter une valeur secrète trouvée dans une unité ; nommez la variable et dites à l'utilisateur de la faire pivoter, car elle était lisible par chaque utilisateur local. - Le durcissement est testé, pas supposé : ajoutez les options par étapes, redémarrez, vérifiez le journal ; assouplissez une option plutôt que de supprimer tout le drop-in. - Préférez `DynamicUser=yes` ou un utilisateur système dédié à root ; attribuez uniquement la capacité exacte nécessaire (CAP_NET_BIND_SERVICE pour les ports bas). - Modifiez avec `systemctl edit <unit>` (drop-ins) au lieu de changer les fichiers du fournisseur sous /usr/lib/systemd. - Le score d'exposition est une estimation de ce script ; le `systemd-analyze security` de l'hôte est la référence.