Vérifier le propriétaire de la commande journalctl
Garantit que le binaire journalctl (/usr/bin/journalctl) appartient à root (uid 0).
Vérifié sur les métadonnées d’un chemin, mode, propriétaire, groupe, SUID/SGID.
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
journalctl est l'outil utilisé pour lire le journal systemd, qui contient des événements opérationnels, des erreurs et des éléments pertinents pour la sécurité. Si le binaire appartient à un utilisateur non-root, celui-ci pourrait le remplacer ou le falsifier pour masquer des entrées de journal, divulguer des informations sensibles (PII, détails opérationnels exposés dans les messages d'erreur) à des personnes non autorisées, ou exécuter du code piégé avec les privilèges de quiconque l'invoque. Conserver le binaire sous la propriété de root (uid 0) garantit que seul le superutilisateur peut modifier l'outillage de consultation des journaux.
Ce que vérifie Pavois
Pavois vérifie que le fichier réel /usr/bin/journalctl a l'uid de propriétaire 0, en ignorant le test via only_if si le binaire est absent. Il lit le propriétaire effectif depuis le système de fichiers (stat) plutôt que de se fier à la base de données des paquets, ainsi, même si dpkg -V systemd ne signale aucun changement, un binaire remplacé ou re-attribué manuellement est tout de même signalé.
only_if { file('/usr/bin/journalctl').exist? }
describe file('/usr/bin/journalctl') do
its('uid') { should eq 0 }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%U %u' /usr/bin/journalctl. Sortie attendue : root 0. De façon équivalente, ls -l /usr/bin/journalctl doit afficher root comme propriétaire.
Inspecter et investiguer
La propriété ne génère pas de journal continu ; vérifiez l'état courant avec stat /usr/bin/journalctl. L'usage de l'outillage du journal est lui-même visible via journalctl, et si /usr/bin est surveillé par auditd, toute altération du binaire apparaît dans /var/log/audit/audit.log.
Remédiation
Aucun plan de durcissement automatisé n'est défini, appliquez-la donc manuellement : chown root:root /usr/bin/journalctl. Réinstaller le paquet systemd (apt install --reinstall systemd) restaure également la bonne propriété root.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| owner | root |
|---|---|
| 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
Un propriétaire non-root de ce binaire constitue un risque sérieux : cet utilisateur contrôle l'outil que tout le monde utilise pour lire les journaux et pourrait le piéger. Restaurer la propriété root est sans danger et n'affecte pas la capacité des utilisateurs normaux à exécuter journalctl (l'accès en lecture est régi par l'appartenance à un groupe et les permissions, pas par la propriété). Précaution : ne supprimez pas le bit setgid ni ne changez la propriété de groupe en corrigeant le propriétaire, car journalctl s'appuie sur la sémantique du groupe systemd-journal dans certaines configurations.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-232100, UBTU-24-700040 | 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.