Journaliser les modifications des contrôles d'accès discrétionnaires (DAC) - chmod
Garantit qu'auditd possède une règle active marquée perm_mod journalisant chaque modification de permissions/propriété de fichier (DAC).
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.
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
Les modifications de permissions, de propriété et d'ACL (les contrôles d'accès discrétionnaires) sont le moyen par lequel un attaquant ouvre l'accès à des fichiers interdits, ou efface les traces d'une intrusion. Auditer la famille d'appels système chmod/chown/setxattr sous la clé perm_mod produit un enregistrement immuable permettant aux intervenants de reconstituer qui a modifié les droits d'accès et quand, révélant les schémas d'abus par des utilisateurs autorisés comme non autorisés.
Ce que vérifie Pavois
Pavois exécute auditctl -l et vérifie que l'ensemble de règles chargé contient une règle marquée perm_mod. Il s'agit de l'ensemble effectif chargé dans le noyau, et non du contenu de /etc/audit/rules.d/. Une règle présente dans un fichier mais jamais chargée (erreur de syntaxe, augenrules --load oublié, redémarrage en attente) passerait un scan de fichier tout en échouant ici : c'est précisément l'écart que Pavois est conçu pour détecter.
describe command('auditctl -l') do
its('stdout') { should match(/(-k +|key=)perm_mod\b/) }
end
describe command("grep -rhwsE 'perm_mod' /etc/audit/rules.d/*.rules /etc/audit/audit.rules 2>/dev/null") do
its('stdout') { should match(/\S/) }
endComment vérifier qu’elle est appliquée
Exécutez auditctl -l | grep perm_mod. Attendu : une ou plusieurs lignes se terminant par -k perm_mod (ou key=perm_mod), couvrant chmod, chown, setxattr, etc. Aucune sortie signifie que la règle n'est pas chargée.
Inspecter et investiguer
- Confirmer la règle chargée :
auditctl -l | grep perm_mod. - Voir les événements enregistrés : grep du journal brut, ex.
grep 'key="perm_mod"' /var/log/audit/audit.log(ausearch est peu fiable ici, préférez un grep brut). - État du service :
systemctl status auditd.
Remédiation
pavois harden apply utilise la ressource audit_ruleset : elle écrit les règles d'audit des modifications DAC (clé perm_mod) dans le répertoire de règles d'auditd et recharge l'ensemble. Cette règle est marquée reboot_required : un redémarrage garantit que les nouvelles règles sont actives dès le démarrage et que toute configuration immuable (-e 2) prend effet.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| reboot_required | true |
|---|---|
| resource | audit_ruleset |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Sans cette règle, la falsification des permissions et de la propriété passe inaperçue, paralysant l'investigation d'incident et enfreignant les exigences de piste d'audit PCI/STIG. L'appliquer ajoute des règles d'audit et peut nécessiter un redémarrage ; sur des systèmes chargés, un fort volume d'événements chmod/chown peut faire grossir /var/log/audit/ rapidement, dimensionnez donc max_log_file/space_left avant d'activer.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R73 | direct | 2.0 | haute |
| CIS | 10.3.4, 6.2.3.9, 6.3.3.18, 6.3.3.9 | direct | per OS, see the benchmark table | haute |
| NIST | 3.1.7, AU-12(c), AU-2(d), CM-6(a) | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 10.3.4 | support | 4.0.1 | moyenne |
| DISA STIG | UBTU-22-654155, UBTU-22-654160, UBTU-22-654180, UBTU-24-900150, UBTU-24-900140, UBTU-24-900130 | direct | per OS STIG release | 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.