← Toutes les règles
SOCLE-CLD-FSP-115// File permissionsmoyenneconfig persistante

Les permissions des fichiers de configuration d'audit sont 640 ou plus restrictives

Garantit que l'arborescence de configuration d'audit /etc/audit n'est ni lisible par les autres, ni modifiable par le groupe/les autres, et ne porte aucun bit exécutable ou spécial (setuid/setgid/sticky), soit le mode 0640 ou plus strict.

Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.

Un PASS prouve? actif maintenant✓ sur disque✓ survit au rebootle verdict qualifié →
Debian 12CIS 1.1.0Debian 13CIS 1.0.0FedoraRHEL 10 / Rocky 10 / AlmaLinux 10RHEL 8 / Rocky 8 / AlmaLinux 8CIS 4.0.0RHEL 9 / Rocky 9 / AlmaLinux 9CIS 2.0.0Ubuntu 22.04CIS 3.0.0Ubuntu 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 2 normes

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

La configuration d'audit sous /etc/audit (auditd.conf, audit.rules, rules.d/, plugins.d/) définit quels événements sont enregistrés et comment. Si ces fichiers sont modifiables par le groupe/les autres, un attaquant pourrait désactiver silencieusement des règles pour que ses actions ne soient pas journalisées ; s'ils sont lisibles par les autres, ils révèlent exactement ce qui est, et n'est pas, surveillé, aidant un intrus à échapper à la détection. Les restreindre à 0640 (ou plus strict pour le répertoire) garde la politique d'audit sous le contrôle exclusif de root et préserve l'intégrité de la piste d'audit.

Ce que vérifie Pavois

Pavois lit les bits de mode réels de /etc/audit via la ressource InSpec file, les permissions réellement appliquées par le noyau, plutôt qu'une hypothèse de paquet. Cela détecte une configuration relâchée après installation. Note : ce contrôle inspecte le nœud /etc/audit ; un durcissement complet applique aussi 0640 récursivement à rules.d/*.rules. La garde only_if ignore le contrôle si l'audit n'est pas installé.

only_if { file('/etc/audit').exist? }
describe file('/etc/audit/auditd.conf') do
  it { should_not be_executable }
  it { should_not be_writable.by('group') }
  it { should_not be_readable.by('other') }
  it { should_not be_writable.by('other') }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%a %U %G %n' /etc/audit /etc/audit/auditd.conf /etc/audit/rules.d/*.rules. La sortie attendue affiche 640 (fichiers) / 750 ou 700 (répertoire) appartenant à root root, sans lecture par les autres ni écriture groupe.

Inspecter et investiguer

auditd rapporte sa politique chargée avec auditctl -l et son état avec auditctl -s ; les événements arrivent dans /var/log/audit/audit.log. Surveillez les modifications de la configuration en ajoutant une règle auditd sur /etc/audit et en recherchant sa clé dans le journal.

Remédiation

Pavois applique le mode 0750 au répertoire /etc/audit (le propriétaire root conserve lecture/écriture/parcours, le groupe lecture/parcours, aucun accès pour les autres). C'est automatisé, appliquez-le avec pavois harden apply. Critique : /etc/audit est un répertoire, il DOIT donc conserver le bit exécute/parcours du propriétaire. Ne lui appliquez jamais un 0640 de style fichier : un répertoire sans x ne peut pas être parcouru, et sous SELinux enforcing le domaine confiné auditd_t se voit alors refuser la capacité dac_read_search, si bien qu'auditd échoue au démarrage avec Error opening config file (/etc/audit/auditd.conf): Permission denied. Le cas échéant, rétablissez avec chmod 750 /etc/audit /etc/audit/rules.d && restorecon -R /etc/audit.

Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :

grouproot
mode0640
ownerroot
path/etc/audit/auditd.conf
resourcefile
pavois harden plan local

où la cible est local, un alias SSH user@hôte, ou un conteneur , Docs

Impact & précautions

Risque en cas de non-application : une config d'audit modifiable permet de couper la journalisation ; une config lisible cartographie votre couverture de détection. Précaution (parcours de répertoire) : appliquez la restriction en tant que mode répertoire 0750, pas un mode fichier 0640. Retirer le bit de parcours du propriétaire (par ex. chmod 0640 ou un chmod -R u-x /etc/audit récursif) rend le répertoire non parcourable ; sur RHEL/Alma/Fedora sous SELinux enforcing, cela refuse au domaine auditd_t la capacité dac_read_search et brique auditd au démarrage. Rétablissement : chmod 750 /etc/audit /etc/audit/rules.d && restorecon -R /etc/audit, puis vérifiez avec systemctl is-active auditd et auditctl -l. Seuls root et le démon auditd lisent ces fichiers, donc 0750 est sans danger.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS6.3.4.5directper OS, see the benchmark tablehaute
NISTAU-12 bsupport800-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.

Sources & références