← Toutes les règles
SOCLE-CLD-FSP-032// File ownershipmoyenneétat du système de fichiers

Vérifier le groupe propriétaire du fichier /etc/shells

Garantit que la liste des shells de confiance /etc/shells appartient au groupe root (gid 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

Un PASS prouve✓ actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 3 normes

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

Le fichier /etc/shells liste les chemins complets des shells de connexion approuvés sur le système. Il est consulté par chsh, les démons FTP et d'autres programmes pour décider si un compte peut ouvrir une session interactive. Si son groupe propriétaire n'est pas privilégié, un attaquant pourrait y ajouter un interpréteur malveillant et le faire passer pour un shell de connexion de confiance. Le faire appartenir au groupe root (gid 0) empêche toute modification non autorisée.

Ce que vérifie Pavois

Pavois lit l'identifiant de groupe réel de /etc/shells via la ressource InSpec file et vérifie gid == 0. Comme il contrôle la propriété effective du système de fichiers plutôt que ce qu'affirme un modèle de gestion de configuration, il détecte les dérives survenues après le dernier déploiement (chgrp manuel, archive décompressée, paquet ayant réinitialisé le groupe).

only_if { file('/etc/shells').exist? }
describe file('/etc/shells') do
  its('gid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%G %g' /etc/shells. Sortie attendue : root 0.

Inspecter et investiguer

Non journalisé par défaut. Ajoutez une surveillance auditd, auditctl -w /etc/shells -p wa -k system-locale, les modifications apparaissent alors dans /var/log/audit/audit.log (filtrez avec grep '/etc/shells' /var/log/audit/audit.log).

Remédiation

Aucune remédiation automatique n'est câblée pour cette règle ; elle doit être appliquée manuellement : chgrp 0 /etc/shells. Relancez ensuite pavois harden verify.

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

grouproot
path/etc/shells
resourcefile
pavois harden plan local

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

Impact & précautions

Un /etc/shells au groupe trop permissif permet à un attaquant d'enregistrer un shell de connexion malveillant. Remettre le groupe à root est sans danger : le fichier est lisible par tous et seul root doit pouvoir l'écrire. Aucun service ni flux de connexion n'est cassé. Précaution : conservez le mode 0644 pour que les programmes qui le consultent (FTP, chsh) puissent toujours le lire.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R50direct2.0haute
CIS7.1.9directper OS, see the benchmark tablehaute
NISTAC-3, MP-2support800-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