Vérifier les permissions de la commande journal
Garantit que le binaire /usr/bin/journalctl n'a aucune écriture ou exécution pour le groupe/les autres, aucune lecture pour les autres et aucun bit setuid/setgid, afin que l'accès au journal reste contrôlé.
Vérifié sur le contenu d’un fichier de configuration persistant, la source de vérité qui survit aux redémarrages.
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
Le binaire journalctl lit le journal systemd, qui peut contenir des données opérationnelles et de sécurité sensibles. Le STIG exige que les permissions de la commande soient strictement contrôlées afin que des utilisateurs non privilégiés ne puissent ni altérer le binaire ni l'utiliser pour lire plus que ce qu'ils devraient. Si /usr/bin/journalctl était modifiable par le groupe/les autres, il pourrait être remplacé ou modifié ; un bit setuid/setgid inattendu accorderait un accès élevé au journal. Le binaire ne doit avoir aucune écriture/exécution pour le groupe ou les autres, aucune lecture pour les autres et aucun bit spécial, afin que seul un usage autorisé et privilégié de la commande journal soit possible.
Ce que vérifie Pavois
Pavois lit le mode effectif de l'inode de /usr/bin/journalctl et vérifie l'absence de bits setuid/setgid/sticky, l'absence d'écriture/exécution pour le groupe et d'écriture/exécution/lecture pour les autres. Protégé par only_if { file('/usr/bin/journalctl').exist? }. Lire le mode réel du binaire détecte un binaire remplacé ou dont les bits ont été modifiés après l'installation, précisément l'altération contre laquelle ce contrôle STIG protège.
only_if { file('/usr/bin/journalctl').exist? }
describe file('/usr/bin/journalctl') do
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
it { should_not be_writable.by('other') }
it { should_not be_readable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%a %U %G' /usr/bin/journalctl. La sortie attendue est 740 root root selon le STIG (aucune écriture/exécution pour le groupe, aucun accès pour les autres, ni setuid/setgid). Certaines distributions livrent 750 ; dans tous les cas il ne doit y avoir aucune écriture pour le groupe/les autres ni bit setuid/setgid.
Inspecter et investiguer
stat /usr/bin/journalctl affiche le mode courant. Le journal qu'il lit s'interroge avec journalctl ; l'intégrité du paquet se vérifie avec dpkg --verify systemd (signale les changements de mode/propriétaire par rapport à la base de données des paquets). Les modifications de fichier apparaissent dans /var/log/audit/audit.log si surveillées.
Remédiation
Aucun plan de durcissement automatisé n'est défini pour cette règle, appliquez-la donc manuellement : chown root:root /usr/bin/journalctl puis chmod 0740 /usr/bin/journalctl (selon le STIG Ubuntu).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0740 |
|---|---|
| path | /usr/bin/journalctl |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Si le binaire est modifiable par un non-root, il peut être piégé pour capturer ou masquer des données de journal ; un bit setuid inattendu permettrait à tout utilisateur de lire l'intégralité du journal. Précautions : définir 0740 retire l'exécution pour autres, ce qui signifie que les utilisateurs non-root ne peuvent plus du tout exécuter journalctl, vérifiez qu'aucun opérateur non privilégié ni agent de supervision n'en dépend avant d'appliquer, ou accordez plutôt l'accès au journal via l'appartenance au groupe systemd-journal. Une mise à jour du paquet systemd peut réinitialiser les permissions du binaire, re-vérifiez donc après les mises à niveau.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-232140, UBTU-24-700030 | direct | per OS STIG release | haute |
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.