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

Vérifier le groupe propriétaire des fichiers /var/log/*.journal(~)

Garantit que chaque fichier sous /var/log/journal a pour groupe propriétaire systemd-journal ou root (lorsque le répertoire existe).

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 1 norme

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 /var/log/*.journal sont les journaux système persistants gérés par systemd-journald. Ils enregistrent les événements d'authentification, noyau, services et pertinents pour l'audit. Le groupe systemd-journal est la frontière contrôlée déterminant qui peut lire le journal ; si ces fichiers ont pour groupe propriétaire un groupe inattendu, ses membres pourraient lire des données sensibles ou, s'ils sont aussi inscriptibles, corrompre le journal et détruire les preuves forensiques. Restreindre la propriété de groupe à systemd-journal (ou root) préserve la confidentialité et l'intégrité du journal.

Ce que vérifie Pavois

Protégé par only_if test -d /var/log/journal, il est ignoré quand la journalisation persistante est désactivée (volatile seulement). Pavois exécute alors find -P /var/log/journal -type f ! -group systemd-journal ! -group root et attend une sortie vide. Lire le groupe réel de chaque inode .journal détecte les fichiers créés/effectués par rotation à l'exécution par journald, ce qu'un audit statique de journald.conf ne peut pas.

only_if { command('test -d /var/log/journal').exit_status.zero? }
describe command('find -P /var/log/journal -type f ! -group systemd-journal ! -group root 2>/dev/null | head -1') do
  its('stdout') { should eq '' }
end

Comment vérifier qu’elle est appliquée

Exécutez sudo find /var/log/journal -type f ! -group systemd-journal ! -group root 2>/dev/null. Sortie attendue : vide. Vous pouvez aussi vérifier avec stat -c '%U:%G %n' /var/log/journal/*/*.journal (propriétaire/groupe attendu root:systemd-journal).

Inspecter et investiguer

Inspectez journald lui-même avec journalctl -u systemd-journald et systemctl show systemd-journald. Listez les groupes des fichiers avec find /var/log/journal -type f -printf '%g %p\n' ; exécutez journalctl --verify pour confirmer que les fichiers du journal ne sont pas corrompus après tout changement de propriété.

Remédiation

Le plan de durcissement de Pavois exécute une ressource exec nommée chown-journal qui applique chown root:systemd-journal à tout le contenu de /var/log/journal, rétablissant le propriétaire et le groupe attendus. Une garde not_if saute l'action quand aucun fichier n'a le mauvais groupe, garantissant l'idempotence. Appliqué avec pavois harden apply.

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

commandfind /var/log/journal -exec chown root:systemd-journal {} + 2>/dev/null || true
namechown-journal
not_iftest -z "$(find /var/log/journal ! -group systemd-journal 2>/dev/null)"
resourceexec
pavois harden plan local

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

Impact & précautions

Rétablir les fichiers du journal à root:systemd-journal est le défaut documenté de systemd et présente peu de risque : journald continue d'écrire et le groupe systemd-journal conserve l'accès en lecture. La commande de durcissement touche aussi les entrées de répertoire ; cela n'interrompt pas la journalisation. Par précaution, exécutez journalctl --verify ensuite pour confirmer l'intégrité, et évitez d'élargir manuellement les permissions des fichiers du journal par chmod, ce qui annulerait le contrôle d'accès imposé par cette règle.

Mapping des normes

NormeRéférenceTypeVersionConfiance
CIS6.1.4.1, 6.2.2.1directper OS, see the benchmark tablehaute

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