Comment Lire les Journaux Linux sans Root (Guide des Permissions)

Sur la plupart des distributions, deux appartenances à des groupes couvrent presque tout ce dont un analyste a besoin : adm pour les journaux texte dans /var/log sur Debian et Ubuntu, et systemd-journal pour le journal système complet. Ajoutez le compte avec sudo usermod -aG adm,systemd-journal <utilisateur> et démarrez une nouvelle session de connexion. Quelques journaux restent réservés au root par conception, notamment /var/log/secure et /var/log/messages sur les systèmes de la famille Red Hat et tout ce qui se trouve sous /var/log/audit. Pour ceux-ci, utilisez un sudo à portée limitée, pas un shell root.

Donner à quelqu’un l’accès root juste pour qu’il puisse lire les journaux est le genre de raccourci qui ressort lors du prochain audit, ou du prochain incident. Ce guide couvre la méthode du moindre privilège, ainsi que les pièges qui rendent le fait de « simplement les ajouter à un groupe » moins simple qu’il n’y paraît.

Commencez gratuitement

Qui peut lire quoi

La propriété exacte varie selon la distribution et la version, vérifiez donc directement sur la machine :

id
ls -l /var/log/auth.log /var/log/secure 2>/dev/null
getfacl /var/log/journal 2>/dev/null

Option 1 : Appartenance à un groupe

sudo usermod -aG adm,systemd-journal analyst

Deux détails importent. Le -a n’est pas facultatif : sans lui, usermod -G remplace les groupes de l’utilisateur au lieu de les ajouter. Et les changements de groupe ne s’appliquent qu’aux nouvelles sessions. Déconnectez-vous et reconnectez-vous, ou démarrez un nouveau shell de connexion, avant de tester. « J’ai ajouté le groupe et ça indique toujours permission refusée » est presque toujours une ancienne session.

Sur les systèmes de la famille Red Hat, adm ne débloque pas /var/log/secure ou /var/log/messages. Ces fichiers sont root uniquement là-bas. Utilisez l’Option 2 ou 3.

Option 2 : Sudo restreint pour les journaux root uniquement

Accordez des commandes spécifiques, pas un shell. Créez /etc/sudoers.d/log-readers avec visudo -f :

%logreaders ALL=(root) NOPASSWD: /usr/sbin/ausearch, /usr/local/bin/read-secure-log

read-secure-log est un petit script possédé par root (mode 0755, possédé par root) qui fait exactement une chose :

#!/bin/sh
exec /usr/bin/zcat -f /var/log/secure /var/log/secure-*

Pourquoi un wrapper au lieu de cat /var/log/secure* dans sudoers ? Parce qu’un * dans un argument sudoers correspond à tout, y compris les espaces. cat /var/log/secure /etc/shadow correspond à cat /var/log/secure*. Un wrapper sans arguments n’a pas de telle faille.

Ne pas accorder journalctl via sudo. Il ouvre un pager (less), et !sh dans less vous donne un shell root. Pour l’accès au journal, utilisez le groupe systemd-journal à la place.

Option 3 : Propriété du groupe qui survit à la rotation

Définir un ACL directement fonctionne jusqu’à la prochaine rotation : sudo setfacl -m g:logreaders:r /var/log/secure. Ensuite, le fichier est recréé et le ACL est perdu. Pour rendre l’accès permanent, faites créer de nouveaux fichiers avec le bon groupe dès le départ, dans les deux endroits qui les créent :

• logrotate, dans le stanza du fichier : create 0640 root logreaders
• rsyslog, sur l’action qui l’écrit : action(type= »omfile » file= »/var/log/secure » fileGroup= »logreaders » fileCreateMode= »0640″)

Testez-le avec logrotate -f sur une machine non-production avant de le déployer.

Conteneurs

Ne pas ajouter des analystes au groupe docker juste pour lire les journaux de conteneur. L’appartenance à docker équivaut à root sur cet hôte. Obtenez les journaux de conteneurs de votre collecteur de journaux ou SIEM à la place, ou demandez à l’équipe plateforme un accès en lecture seule.

Quand ça tourne mal