Vérifier les permissions du fichier /etc/security/opasswd
Garantit que /etc/security/opasswd n'est ni lisible ni modifiable par le groupe ou les autres (sans setuid/setgid/sticky/exec), afin que seul root puisse accéder aux condensats d'historique.
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/security/opasswd est le fichier d'historique des mots de passe utilisé par pam_pwhistory/pam_unix pour empêcher la réutilisation d'anciens mots de passe. Il contient d'anciens condensats de mots de passe, il est donc aussi sensible que /etc/shadow. S'il est lisible par le groupe ou les autres, ces condensats deviennent exploitables par cassage hors ligne ; s'il est modifiable, un attaquant pourrait effacer l'historique pour autoriser la réutilisation ou injecter des entrées falsifiées. Les bits setuid/setgid/exécutable n'ont aucune utilité ici. Seul root doit pouvoir le lire ou l'écrire.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/security/opasswd sur la cible, y compris le bit de lecture groupe/autres (pas seulement écriture), car la menace ici est la divulgation des condensats. Les permissions sont des métadonnées d'inode, l'audit reflète donc exactement ce que le noyau applique, aucun include ni drop-in à contourner. La garde only_if ignore le contrôle si aucun fichier d'historique n'existe encore.
only_if { file('/etc/security/opasswd').exist? }
describe file('/etc/security/opasswd') 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_readable.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_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U %G' /etc/security/opasswd. Attendu : mode -rw------- (0600), ou 0640 root:root au plus, appartenant à root root, sans bit de lecture/écriture pour le groupe ou les autres. Vérification rapide : find /etc/security/opasswd -perm /0177 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez ce fichier sensible avec auditd : auditctl -w /etc/security/opasswd -p wa -k identity, puis consultez avec grep 'key="identity"' /var/log/audit/audit.log. L'activité de l'historique PAM apparaît dans /var/log/auth.log (Debian/Ubuntu) ou journalctl -u systemd-logind//var/log/secure (RHEL). Mode et propriété actuels : stat /etc/security/opasswd.
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/security/opasswd && chmod 0600 /etc/security/opasswd. Cela supprime tout accès groupe/autres et tout bit setuid/setgid/sticky, limitant les condensats d'historique à root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0600 |
|---|---|
| path | /etc/security/opasswd |
| 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é : la lecture par tous/groupe expose d'anciens condensats au cassage hors ligne, révélant des mots de passe réutilisés ou faibles encore en usage ailleurs. Appliquer le correctif est sûr, 0600 root:root est le mode attendu et seul pam_unix (exécuté en root lors d'un changement de mot de passe) en a besoin. Précaution : ne relâchez pas vers 0644 ; contrairement à /etc/passwd, ce fichier ne doit pas être lisible par tous.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 7.1.10 | direct | per OS, see the benchmark table | haute |
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.