← Toutes les règles
SOCLE-RUN-SVC-010// systemd servicesmoyenneruntime effectif

Désactiver le service SystemD debug-shell

Garantit que l'unité systemd debug-shell.service est désactivée et arrêtée, afin qu'aucun shell root sans mot de passe ne soit accessible au démarrage.

Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0
Un seul check, mappé sur 1 norme

Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.

Un mapping est une référence croisée vers l’endroit où chaque norme situe cette exigence, ancrée et recoupée, pas une affirmation d’équivalence. Un check réussi est une preuve vers ces références, comment le lire.

Pourquoi cette règle

debug-shell.service ouvre un shell root sans authentification sur tty9, prévu pour diagnostiquer les échecs de démarrage. S'il est activé, toute personne ayant un accès physique ou console (ou capable de forcer un redémarrage) obtient un shell root immédiat, contournant tous les contrôles de connexion. Il doit rester désactivé sur tout système de production.

Ce que vérifie Pavois

Pavois interroge l'état résolu de l'unité via systemctl is-enabled / is-active pour debug-shell.service. Lire l'état effectif du service détecte une unité activée par un drop-in ou un alias statique qu'un scan de fichiers dans /etc/systemd manquerait.

describe service('debug-shell.service') do
  it { should_not be_enabled }
  it { should_not be_running }
end

Comment vérifier qu’elle est appliquée

Exécutez systemctl is-enabled debug-shell.service (résultat attendu disabled ou masked) et systemctl is-active debug-shell.service (résultat attendu inactive).

Inspecter et investiguer

Examinez systemctl show debug-shell.service pour UnitFileState et ActiveState ; les événements d'activation apparaissent dans journalctl -u debug-shell.service.

Remédiation

Le plan harden de Pavois applique une ressource service sur debug-shell avec les actions disable et stop, garantissant que l'unité ne démarrera pas au boot et qu'elle est arrêtée immédiatement. Appliquez-le avec pavois harden apply.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

actiondisable, stop
namedebug-shell
resourceservice
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Désactiver debug-shell.service supprime seulement un shell de diagnostic d'urgence ; aucune charge de production n'en dépend, l'impact est donc minime. Précaution : si vous l'utilisez pour récupérer des systèmes qui ne démarrent plus, conservez une voie de récupération alternative (cible rescue, accès console, mot de passe root connu) avant d'appliquer.

Mapping des normes

NormeRéférenceTypeVersionConfiance
NIST3.4.5support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne

Chaque référence est une référence croisée ancrée dans le benchmark amont et recoupée avec le SCAP Security Guide et ansible-lockdown, pas une affirmation d’équivalence. Direct = une exigence prescriptive au niveau de la ligne ; support = une famille de contrôle abstraite (NIST) vers laquelle le check apporte une preuve. Comment lire un mapping.

Sources & références