Vérifier les permissions du fichier /etc/security/opasswd.old
Garantit que la sauvegarde d'historique /etc/security/opasswd.old 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 archivés.
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.old est la sauvegarde du fichier d'historique des mots de passe PAM, créée automatiquement lors de la mise à jour de opasswd. Elle contient les mêmes anciens condensats de mots de passe et est donc aussi sensible que /etc/security/opasswd lui-même, une sauvegarde ancienne reste tout aussi cassable. Si elle est lisible par le groupe ou les autres, ces condensats fuient ; si modifiable, l'intégrité de l'historique est perdue. Les bits setuid/setgid/exécutable n'ont aucune utilité. Seul root doit pouvoir la lire ou l'écrire.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/security/opasswd.old sur la cible, y compris le bit de lecture groupe/autres, car la sauvegarde porte les mêmes condensats cassables que le fichier actif. Les permissions sont des métadonnées d'inode, l'audit reflète donc exactement ce que le noyau applique. La garde only_if ignore le contrôle si aucune sauvegarde n'existe.
only_if { file('/etc/security/opasswd.old').exist? }
describe file('/etc/security/opasswd.old') 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.old. 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.old -perm /0177 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez la sauvegarde avec auditd, comme le fichier actif : auditctl -w /etc/security/opasswd.old -p wa -k identity, puis consultez avec grep 'key="identity"' /var/log/audit/audit.log. L'activité de changement de mot de passe PAM apparaît dans /var/log/auth.log (Debian/Ubuntu) ou /var/log/secure (RHEL). Mode et propriété actuels : stat /etc/security/opasswd.old.
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.old && chmod 0600 /etc/security/opasswd.old. Cela supprime tout accès groupe/autres et tout bit setuid/setgid/sticky de la sauvegarde d'historique.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0600 |
|---|---|
| path | /etc/security/opasswd.old |
| 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é : une sauvegarde lisible divulgue d'anciens condensats comme le fichier actif, les attaquants ciblent souvent les copies .old/de sauvegarde précisément parce qu'elles sont négligées. Appliquer le correctif est sûr : 0600 root:root correspond au mode du fichier actif. Précaution : ne relâchez pas vers une lecture par tous ; cette sauvegarde doit refléter les permissions strictes de /etc/security/opasswd.
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.