← Toutes les règles
SOCLE-CLD-FSP-184// Filesystem (scan)moyenneétat du système de fichiers

Vérifier l'utilisateur propriétaire du répertoire /var/log

Garantit que chaque fichier sous /var/log appartient à l'utilisateur root ou syslog.

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é →
FedoraRHEL 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 4 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

L'arborescence /var/log contient les journaux système, d'authentification et d'audit qui ne doivent être accessibles qu'au personnel autorisé. Un fichier de journal appartenant à un utilisateur autre que root ou syslog peut être lu par cet utilisateur, exposant des messages d'erreur, des identifiants ou des données de session, ou réécrit pour effacer les traces d'une attaque. Restreindre le propriétaire du fichier préserve la confidentialité et l'intégrité de la piste d'audit.

Ce que vérifie Pavois

Pavois lance find /var/log -type f ! -user root ! -user syslog et attend une sortie vide. Auditer le système de fichiers réel détecte les journaux créés à l'exécution par les démons, les fichiers après rotation et les fichiers déposés manuellement qu'une liste statique ou une vérification de paquet manquerait.

describe command('timeout 90 find /var/log -type f ! -user root ! -user syslog ! -user _aide 2>/dev/null') do
  its('exit_status') { should_not cmp 124 }  # timeout killed the scan: no evidence, not a pass
  its('stdout.strip') { should eq '' }
end

Comment vérifier qu’elle est appliquée

Lancez l'analyse manuellement :

find /var/log -type f ! -user root ! -user syslog

Sortie attendue : rien (vide). Inspectez tout fichier affiché avec ls -l <fichier>.

Inspecter et investiguer

Listez les fautifs et leur propriétaire avec find /var/log -type f ! -user root ! -user syslog -printf '%u %p\n'. Après correction, vérifiez avec ls -l /var/log/. Les changements de propriétaire ne sont enregistrés que si une surveillance auditd sur chown est configurée.

Remédiation

Aucun plan de durcissement automatisé n'est défini pour cette règle ; elle doit être appliquée manuellement. Réattribuez les fichiers fautifs avec chown root <fichier> (ou syslog selon le cas). Sur Debian/Ubuntu, la règle proche findloop-file-ownerships-var-log fournit un correctif automatisé ; cette variante RHEL/Ubuntu laisse volontairement la main à l'administrateur.

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

commandfind /var/log -type f ! -user root ! -user syslog -exec chown root {} + 2>/dev/null; find /var/log -type f ! -group root ! -group adm ! -group syslog ! -group utmp ! -group systemd-journal -exec chgrp root {} + 2>/dev/null; true
namefix-varlog-ownership
not_iftest -z "$(find /var/log -type f \( ! -user root ! -user syslog -o ! -group root ! -group adm ! -group syslog ! -group utmp ! -group systemd-journal \) 2>/dev/null | head -1)"
resourceexec
pavois harden plan local

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

Impact & précautions

Risque en l'état : des journaux appartenant à un utilisateur non privilégié peuvent fuiter des secrets ou être altérés pour masquer une intrusion. Avant de corriger : certains services (base de données ou serveur web écrivant dans /var/log/<service>/) possèdent volontairement leurs journaux avec un utilisateur dédié ; forcer root peut casser la rotation ou empêcher le démon d'écrire. Examinez les fichiers listés et excluez les sous-arborescences légitimes appartenant à un service au lieu de tout réécrire.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R71direct2.0haute
CIS6.1.4.1, 6.2.4.1, 6.2.6.1, 6.2.3.1, 6.2.2.1directper OS, see the benchmark tablehaute
PCI DSS10.3.2support4.0.1moyenne
DISA STIGUBTU-22-232120, UBTU-24-700110directper 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