Vérifier l'appartenance des fichiers dans /var/log/sssd
S'assurer que chaque fichier sous /var/log/sssd appartient à sssd ou root et à aucun autre utilisateur.
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 démon de services de sécurité système (SSSD), qui assure l'authentification auprès de LDAP/Active Directory et peut enregistrer des détails de comptes et d'identifiants. Les fichiers ne doivent appartenir qu'à sssd ou root ; tout autre propriétaire pourrait lire ou altérer les journaux d'authentification, compromettant la piste d'audit.
Ce que vérifie Pavois
Pavois exécute find -P /var/log/sssd -type f ! -user sssd ! -user root (uniquement si le répertoire existe) et attend aucune sortie, tout fichier appartenant à autre chose que sssd ou root constitue une non-conformité. Il vérifie l'appartenance effective des inodes réels, détectant les fichiers ré-attribués à l'exécution qu'un contrôle de configuration statique manquerait.
only_if { command('test -d /var/log/sssd').exit_status.zero? }
describe command('timeout 60 find -P /var/log/sssd -type f ! -user sssd ! -user 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 find -P /var/log/sssd -type f ! -user sssd ! -user root, il ne doit rien afficher. Toute ligne affichée correspond à un fichier de journal SSSD mal attribué à corriger.
Inspecter et investiguer
Listez les fichiers fautifs avec find -P /var/log/sssd -type f ! -user sssd ! -user root -printf '%u %p\n'. Les journaux propres à SSSD s'y trouvent (par ex. sssd_*.log) ; les événements de service du démon se consultent avec journalctl -u sssd.
Remédiation
Il n'existe aucun plan de durcissement automatisé pour cette règle. Appliquez-la manuellement après examen : ré-attribuez les fautifs à root ou sssd, par ex. find -P /var/log/sssd -type f ! -user sssd ! -user root -exec chown root {} +. (Ne concerne que les systèmes où SSSD est installé.)
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
Ce qui peut casser : très peu, SSSD écrit ses journaux sous son propre utilisateur de service et n'est pas affecté par la correction des propriétaires égarés. Précautions : préférez ré-attribuer à sssd (l'utilisateur du démon) plutôt qu'à root pour que SSSD puisse continuer à écrire ; examinez d'abord chaque fichier, car un propriétaire inattendu peut signaler une session de débogage laissée active avec journalisation élevée. Là où SSSD n'est pas installé, le répertoire est absent et la règle est ignorée (only_if).
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.