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

Vérifier les permissions des fichiers journaux

Garantit qu'aucun fichier sous /var/log n'est inscriptible/exécutable par le groupe ni accessible aux autres en lecture/écriture/exécution (aucun bit du masque /037).

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 24.04CIS 1.0.0Ubuntu 26.04
Un seul check, mappé sur 5 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 fichiers journaux consignent la configuration système, les événements d'authentification et l'activité applicative. S'ils sont lisibles par tous, un utilisateur non privilégié peut y récolter noms d'utilisateurs, noms d'hôtes internes, chemins et messages d'erreur facilitant une attaque ; s'ils sont inscriptibles par le groupe ou par tous, un attaquant peut altérer ou effacer des entrées pour détruire les preuves forensiques. Restreindre /var/log au propriétaire (et au groupe de journalisation dédié) maintient des messages d'erreur utiles aux défenseurs sans révéler d'informations exploitables par un adversaire.

Ce que vérifie Pavois

Pavois exécute find /var/log -type f -perm /037 et attend une sortie vide. Le masque /037 correspond à tout fichier possédant au moins un des bits : écriture groupe, exécution groupe, ou lecture/écriture/exécution pour les autres. Une sortie vide signifie que chaque journal est au plus en 0640 (propriétaire rw, groupe r, autres aucun). Analyser les inodes en direct détecte les fichiers créés à l'exécution par les services et logrotate, qu'un audit de configuration statique manquerait.

describe command('timeout 90 find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal 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

Exécutez sudo find /var/log -type f -perm /037 2>/dev/null. Sortie attendue : vide. Chaque chemin renvoyé est un journal au mode trop permissif ; inspectez-le avec ls -l <chemin>.

Inspecter et investiguer

Listez les fichiers fautifs et leurs modes avec find /var/log -type f -perm /037 -ls. Après remédiation, find /var/log -type f -perm /037 ne doit rien afficher. Surveillez les exécutions de logrotate dans /var/log/syslog si des fichiers reprennent de mauvais modes (directive create personnalisée dans /etc/logrotate.d/*).

Remédiation

Le plan de durcissement de Pavois exécute une ressource exec nommée fix-varlog-perms qui repère chaque fichier fautif et lui applique chmod g-wx,o-rwx, retirant l'écriture/exécution groupe et tout accès aux autres tout en préservant le propriétaire et la lecture groupe. Une garde not_if saute l'action quand aucun fichier ne correspond, garantissant l'idempotence. Appliqué avec pavois harden apply.

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

commandif [ -f /etc/sysstat/sysstat ]; then sed -ri 's/^[[:space:]]*UMASK=.*/UMASK=0027/' /etc/sysstat/sysstat; grep -q '^UMASK=' /etc/sysstat/sysstat || echo UMASK=0027 >> /etc/sysstat/sysstat; fi; for u in apt-daily apt-daily-upgrade unattended-upgrades sysstat-collect sysstat-summary; do systemctl list-unit-files ${u}.service --no-legend 2>/dev/null | grep -q . || continue; mkdir -p /etc/systemd/system/${u}.service.d; printf '[Service]\nUMask=0027\n' > /etc/systemd/system/${u}.service.d/pavois-umask.conf; done; systemctl daemon-reload; find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal -exec chmod g-wx,o-rwx {} + 2>/dev/null; true
namefix-varlog-perms
not_iftest -z "$(find /var/log -type f -perm /037 ! -group utmp ! -group systemd-journal 2>/dev/null | head -1)" && { ! test -f /etc/sysstat/sysstat || grep -q '^UMASK=0027' /etc/sysstat/sysstat; }
reasonthe chmod alone does not hold: the files are RE-CREATED by the services that write them. Two sources must be fixed, not one: the systemd units (UMask=0027 drop-in, for apt-daily / unattended-upgrades / dnf-makecache) AND sysstat's own UMASK knob in /etc/sysstat/sysstat, which overrides the unit's umask. The chmod only repairs what already exists.
resourceexec
pavois harden plan local

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

Impact & précautions

Resserrer les permissions présente peu de risque car le propriétaire et le groupe de journalisation conservent l'accès. Toutefois, une application non privilégiée qui lit son propre journal sous /var/log via la lecture autres pourrait perdre cette visibilité après le retrait de o-rwx ; vérifiez que ces services s'exécutent en tant que propriétaire du fichier ou appartiennent au groupe de journalisation. Retirer l'écriture groupe peut casser une configuration de journalisation non standard à plusieurs écrivains partageant un groupe ; vérifiez votre topologie rsyslog/journald avant une application large.

Mapping des normes

NormeRéférenceTypeVersionConfiance
ANSSI BP-028R71direct2.0haute
CIS10.3.1, 6.1.4.1, 6.2.4.1, 6.2.6.1, 6.2.3.1directper OS, see the benchmark tablehaute
NISTSI-11(a), SI-11(b), SI-11support800-53 Rev 5 · 800-171 Rev 2 (pinned)moyenne
PCI DSS10.3.1support4.0.1moyenne
DISA STIGUBTU-24-700120directper 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