Vérifier les permissions du répertoire /var/log
Garantit que le répertoire /var/log n'est ni accessible en écriture au groupe ou aux autres, ni porteur des bits setuid, setgid ou sticky, afin que seuls les comptes privilégiés puissent modifier l'arborescence des journaux.
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
/var/log est la racine de l'arborescence des journaux système. S'il est accessible en écriture au groupe ou aux autres, n'importe quel utilisateur non privilégié peut créer, renommer ou supprimer des fichiers journaux et ainsi falsifier la piste d'audit pour masquer une intrusion. Un bit setuid/setgid parasite sur le répertoire peut aussi créer une confusion de privilèges. Verrouiller le répertoire préserve l'intégrité et la non-répudiation des journaux.
Ce que vérifie Pavois
Pavois lit l'inode réel de /var/log et vérifie qu'il n'est ni setuid, ni setgid, ni sticky, ni accessible en écriture au groupe ou aux autres. Examiner l'objet réel du système de fichiers (plutôt qu'un manifeste de paquet ou un fichier de configuration) détecte les dérives causées par un chmod négligent, une sauvegarde restaurée ou un paquet défaillant, la permission effective est ce qu'un attaquant voit réellement.
only_if { file('/var/log').exist? }
describe file('/var/log') do
it { should_not be_setuid }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_writable.by('other') }
it { should_not be_sticky }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U:%G' /var/log. Attendez un mode du type drwxr-xr-x (aucune écriture pour le groupe/les autres, aucun bit s ou t) appartenant à root:root. La chaîne de permissions ne doit contenir ni w groupe/autres, ni s/S/t/T.
Inspecter et investiguer
Les changements de permissions sur le répertoire sont visibles via le sous-système d'audit si une surveillance est posée : auditctl -w /var/log -p wa puis consultez /var/log/audit/audit.log. L'état courant se lit toujours avec ls -ld /var/log et stat /var/log.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle ; elle doit donc être appliquée manuellement : chown root:root /var/log et chmod g-w,o-w,u-s,g-s,-t /var/log (généralement chmod 0755 /var/log).
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0755 |
|---|---|
| path | /var/log |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un /var/log accessible en écriture à tous permet à un attaquant d'effacer des preuves ou de remplir le disque ; un bit setgid inattendu peut propager le groupe adm/syslog aux nouveaux fichiers. Précautions : conservez le répertoire au moins lisible et traversable par le groupe/les autres (0755), un durcissement excessif à 0700 cassera journald, rsyslog, logrotate et de nombreux services non-root qui écrivent des journaux, et peut masquer les journaux aux agents de supervision. Vérifiez que le propriétaire reste root:root et qu'aucun service ne dépendait d'un bit spécial avant de le retirer.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| DISA STIG | UBTU-22-232025, UBTU-24-700120 | 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.