Vérifier la propriété de groupe des fichiers dans /var/log/sssd
Garantit que chaque fichier sous /var/log/sssd a pour groupe propriétaire sssd ou root (lorsque le répertoire existe).
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
Le répertoire /var/log/sssd contient les journaux de débogage du System Security Services Daemon (SSSD), qui assure l'authentification contre LDAP, Active Directory ou Kerberos. Ces journaux peuvent exposer noms d'utilisateurs, appartenances de groupes, topologie de domaine et erreurs d'authentification. S'ils ont pour groupe propriétaire un groupe inattendu, ses membres pourraient lire ces données d'identité sensibles ou altérer les journaux. Restreindre la propriété de groupe à sssd ou root les réserve au personnel autorisé.
Ce que vérifie Pavois
Protégé par only_if test -d /var/log/sssd, il est ignoré là où SSSD n'est pas déployé. Pavois exécute alors find -P /var/log/sssd -type f ! -group sssd ! -group root et attend une sortie vide. Lire le groupe réel de chaque inode détecte les journaux de débogage créés à l'exécution qu'un examen de fichier de configuration ne verrait pas.
only_if { command('test -d /var/log/sssd').exit_status.zero? }
describe command('timeout 60 find -P /var/log/sssd -type f ! -group sssd ! -group root -print -quit 2>/dev/null') do
its('exit_status') { should_not cmp 124 } # timeout killed the scan: no evidence, not a pass
its('stdout.strip') { should eq '' }
endComment vérifier qu’elle est appliquée
Exécutez sudo find /var/log/sssd -type f ! -group sssd ! -group root 2>/dev/null. Sortie attendue : vide. Inspectez tout fichier renvoyé avec ls -l <chemin> pour voir son groupe incorrect.
Inspecter et investiguer
Listez les fichiers fautifs avec leur groupe via find /var/log/sssd -type f -printf '%g %p\n'. Aucun journal de service pour la propriété ; vérifiez directement avec stat -c '%G %n' /var/log/sssd/*.
Remédiation
Aucun plan de durcissement automatisé n'est fourni. Corrigez manuellement avec chgrp sssd <fichier> pour chaque fichier fautif, par ex. find /var/log/sssd -type f ! -group sssd ! -group root -exec chgrp sssd {} +.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| command | # Set root ownership recursively under the sssd log dir (only if it exists): [ -d /var/log/sssd ] && find /var/log/sssd -print0 | xargs -0 -r chown root: || echo 'no /var/log/sssd' |
|---|---|
| reason | recursive ownership fix under /var/log/sssd, verify the service is present and review |
| resource | manual |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Changer le groupe des journaux SSSD présente peu de risque et n'a aucun effet là où SSSD est absent (le contrôle est ignoré). Attribuez le groupe sssd pour que le service conserve l'accès en écriture à ses journaux de débogage ; un groupe incorrect pourrait empêcher SSSD de journaliser. Un simple chgrp n'affecte pas l'authentification elle-même, seulement les fichiers journaux.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| CIS | 6.1.4.1, 6.2.2.1 | direct | per OS, see the benchmark table | 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.