← Toutes les règles
SOCLE-CLD-FSP-107// File ownershipmoyenneétat du système de fichiers

Vérifier que les outils d'audit appartiennent à root

Garantit que l'outil de contrôle d'audit /sbin/auditctl (représentatif de la suite d'outils d'audit) appartient à root (uid 0).

Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.

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

Les outils d'audit (auditctl, auditd, ausearch, aureport, autrace, augenrules) sont ce qui définit, collecte et examine la piste d'audit de sécurité. Si auditctl appartient à un utilisateur non-root, celui-ci peut remplacer le binaire pour désactiver silencieusement des règles, supprimer des événements ou falsifier les données d'audit, détruisant l'intégrité du registre même sur lequel s'appuient les enquêteurs après un incident. Restreindre la propriété à root (uid 0) garantit que seul le superutilisateur peut exploiter ou modifier l'outillage d'audit.

Ce que vérifie Pavois

Pavois vérifie que le binaire réel /sbin/auditctl a l'uid de propriétaire 0, en l'ignorant via only_if lorsque auditd n'est pas installé. Il lit le propriétaire effectif depuis le système de fichiers (stat) au lieu du manifeste de paquet, de sorte qu'un binaire remplacé ou re-attribué hors des canaux normaux, précisément le type de falsification qu'un attaquant tenterait pour aveugler le sous-système d'audit, est tout de même détecté.

only_if { file('/sbin/auditctl').exist? }
describe file('/sbin/auditctl') do
  its('uid') { should eq 0 }
end

Comment vérifier qu’elle est appliquée

Exécutez stat -c '%U %u' /sbin/auditctl. Sortie attendue : root 0. Pour vérifier toute la suite, exécutez for b in auditctl auditd ausearch aureport autrace augenrules; do stat -c '%U %n' "$(command -v $b)"; done et confirmez que chaque ligne commence par root.

Inspecter et investiguer

La propriété ne produit pas de journal continu ; interrogez-la avec stat /sbin/auditctl. L'activité d'audit elle-même est enregistrée dans /var/log/audit/audit.log ; si le répertoire des binaires d'audit est surveillé, leurs modifications y apparaissent aussi. Notez que ausearch peut renvoyer de faux « no matches », recherchez directement dans le journal brut, par ex. grep auditctl /var/log/audit/audit.log.

Remédiation

Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /sbin/auditctl (et de même pour les autres binaires d'audit). Réinstaller le paquet auditd/audit restaure la bonne propriété root pour toute la suite.

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

ownerroot
path/sbin/auditctl
resourcefile
pavois harden plan local

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

Impact & précautions

Un propriétaire non-root des outils d'audit peut désactiver ou falsifier l'ensemble de votre piste d'audit, mettant en échec d'un seul coup l'investigation et de nombreux contrôles de conformité. Restaurer la propriété root est sans danger : cela ne change pas le comportement des outils pour les administrateurs autorisés (qui les exécutent via sudo). Précaution : les binaires d'audit doivent conserver leur bit exécutable et leur mode normal ; corrigez seulement le propriétaire, n'assouplissez pas les permissions, sinon vous permettriez à des utilisateurs non privilégiés d'invoquer l'administration de l'audit.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS6.2.4.9, 6.3.4.9directper OS, see the benchmark tablehaute
DISA STIGUBTU-22-232110, UBTU-24-901240directper OS STIG releasehaute

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