Les fichiers de configuration d'audit doivent appartenir à root
Garantit que le répertoire de configuration d'audit /etc/audit appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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 répertoire /etc/audit contient auditd.conf et les fichiers de règles (audit.rules, rules.d/) qui décident quels événements de sécurité sont enregistrés. Si un utilisateur non-root possède ce répertoire, il peut réécrire les règles pour cesser d'auditer des événements critiques, désactiver entièrement la piste d'audit ou la saturer pour masquer son activité, rendant bien plus difficile la détection, la corrélation et l'attribution d'un incident. Restreindre la propriété à root (uid 0) garantit que seul le superutilisateur contrôle ce qui est audité.
Ce que vérifie Pavois
Pavois vérifie que le répertoire réel /etc/audit a l'uid de propriétaire 0, en l'ignorant via only_if lorsque l'audit n'est pas présent. Il lit le propriétaire effectif depuis le système de fichiers (stat) plutôt qu'un manifeste de déploiement, de sorte que tout chown hors-canal sur la configuration d'audit, méthode classique pour préparer une falsification des règles, est détecté.
only_if { file('/etc/audit').exist? }
describe file('/etc/audit') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u' /etc/audit. Sortie attendue : root 0. Pour couvrir aussi le contenu, exécutez find /etc/audit -not -user root, il ne doit rien afficher.
Inspecter et investiguer
La propriété ne génère pas de journal continu ; interrogez-la avec stat /etc/audit. Le sous-système d'audit écrit dans /var/log/audit/audit.log ; si /etc/audit est surveillé (auditctl -w /etc/audit/ -p wa -k auditconfig), les modifications y apparaissent, recherchez dans le journal brut : grep auditconfig /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /etc/audit et, par souci d'exhaustivité, chown -R root:root /etc/audit. Réinstaller le paquet auditd/audit restaure également la propriété root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| path | /etc/audit |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un propriétaire non-root de /etc/audit peut neutraliser votre politique d'audit et effacer ses traces. Restaurer la propriété root est sans danger et n'affecte pas l'auditd en cours d'exécution, qui tourne déjà en root. Précaution : si vous récursez avec chown -R, ne modifiez pas aussi les permissions, les fichiers de règles doivent rester lisibles uniquement par root (mode 0640/0600) ; les assouplir laisserait des attaquants lire quels événements sont surveillés et les contourner.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.2.4.6, 6.3.4.6 | direct | per OS, see the benchmark table | haute |
| DISA STIG | UBTU-22-653070, UBTU-24-900050 | 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.