Vérifier les permissions du fichier /etc/shells
Garantit que /etc/shells n'est ni modifiable, ni exécutable, ni setuid/setgid ni sticky pour le groupe ou les autres, afin que seul root puisse modifier la liste des shells de connexion valides.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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
/etc/shells liste les chemins complets des shells de connexion que le système considère comme valides. Il est consulté par chsh, les démons FTP et d'autres programmes pour décider si un compte peut se connecter de manière interactive. Si le fichier est modifiable par le groupe ou les autres, un utilisateur non privilégié pourrait ajouter un programme arbitraire comme « shell valide », par exemple pour contourner les restrictions sur des comptes limités à /usr/sbin/nologin, ou supprimer un shell pour bloquer des services. Les bits setuid/setgid/exécutable n'ont aucune utilité sur ce fichier texte. Seul root doit pouvoir le modifier.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/shells sur la cible (exécutable/setuid/setgid/sticky/modifiable par groupe et autres), les permissions effectives dans l'inode, et non une base documentée. Les permissions ne peuvent être masquées derrière un include ou un drop-in. La garde only_if ignore le contrôle si le fichier est absent.
only_if { file('/etc/shells').exist? }
describe file('/etc/shells') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U %G' /etc/shells. Attendu : mode -rw-r--r-- (0644) appartenant à root root, sans bit d'écriture pour le groupe/les autres ni bits s/t. Vérification rapide : find /etc/shells -perm /0133 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez le fichier avec auditd : auditctl -w /etc/shells -p wa -k shells, puis consultez avec grep 'key="shells"' /var/log/audit/audit.log. Les changements de shell qui lisent ce fichier (chsh) apparaissent dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Mode et propriété actuels : stat /etc/shells.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/shells && chmod 0644 /etc/shells. Cela supprime toute écriture groupe/autres et tout bit setuid/setgid/sticky tout en gardant le fichier lisible par tous, car les programmes doivent le lire.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/shells |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si mal réglé : un /etc/shells modifiable permet à un utilisateur non-root d'autoriser un shell non prévu et potentiellement d'élargir les capacités interactives d'un compte restreint, ou de casser la politique FTP/chsh. Appliquer le correctif est sûr : 0644 root:root est le mode standard. Précaution : conservez le bit de lecture pour other, chsh, les démons FTP et l'outillage de connexion doivent lire la liste ; supprimer la lecture par tous peut casser le changement de shell et les vérifications de connexion FTP.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | haute |
| CIS | 7.1.9 | direct | per OS, see the benchmark table | haute |
| NIST | AC-3, MP-2 | support | 800-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.