Vérifier les permissions des fichiers dans /var/log/sssd
Garantit que le répertoire /var/log/sssd n'est pas accessible en écriture au groupe ou aux autres, afin que les journaux de débogage de SSSD ne puissent être modifiés que par des comptes privilégiés.
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/sssd contient les journaux de débogage du System Security Services Daemon, qui assure l'authentification contre LDAP/AD/Kerberos. Ces journaux peuvent exposer des noms d'utilisateurs, la topologie du domaine et des erreurs d'authentification ; un répertoire inscriptible permettrait à un attaquant de supprimer ou forger des entrées pour masquer une attaque sur les identifiants. Le verrouiller à root protège la confidentialité des données d'identité et l'intégrité de la piste d'audit d'authentification.
Ce que vérifie Pavois
Pavois lit l'inode réel de /var/log/sssd et vérifie qu'il n'est inscriptible ni par le groupe ni par les autres. Examiner le répertoire réel détecte les dérives causées par un chmod manuel, une mise à jour de paquet ou une sauvegarde restaurée, le mode effectif est ce qu'un attaquant pourrait réellement exploiter, indépendamment de l'intention de sssd.conf ou du paquet.
only_if { file('/var/log/sssd').exist? }
describe file('/var/log/sssd') do
it { should_not be_writable.by('group') }
it { should_not be_writable.by('other') }
endComment vérifier qu’elle est appliquée
Exécutez stat -c '%A %U:%G' /var/log/sssd. Attendez drwxr-x--- (0750) appartenant à root:root, aucun bit d'écriture pour le groupe ou les autres.
Inspecter et investiguer
Le répertoire contient les journaux propres à SSSD (sssd.log, journaux de domaine et des répondeurs nss/pam) ; inspectez avec ls -l /var/log/sssd/ et tail sur le fichier concerné, ou utilisez journalctl -u sssd. Pour détecter une altération des permissions, ajoutez auditctl -w /var/log/sssd -p wa et consultez /var/log/audit/audit.log.
Remédiation
Le plan de durcissement de Pavois applique une ressource directory sur /var/log/sssd, fixant le propriétaire root, le groupe root et le mode 0750, ce qui retire tout accès en écriture au groupe/aux autres (et en lecture aux autres). Appliquez-le avec pavois harden apply.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| group | root |
|---|---|
| mode | 0750 |
| owner | root |
| path | /var/log/sssd |
| resource | directory |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Un répertoire de journaux SSSD inscriptible permet à un attaquant d'effacer les traces de connexions échouées/forgées ou de divulguer des métadonnées d'annuaire. Précautions : le démon sssd s'exécute en root (ou sous l'utilisateur sssd sur certaines distributions) et écrit ici ; conservez donc le propriétaire/mode cohérent avec l'installation de SSSD, sur les distributions où SSSD tourne sous un utilisateur sssd dédié, il peut falloir le groupe sssd plutôt que root pour que le démon puisse écrire. Après application de 0750, redémarrez avec systemctl restart sssd et vérifiez que la journalisation fonctionne ; si SSSD ne peut écrire, l'authentification continuera mais les journaux de diagnostic seront perdus.
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.