Vérifier les permissions du fichier /etc/sestatus.conf
Garantit que /etc/sestatus.conf n'est ni modifiable, ni exécutable, ni setuid/setgid ni sticky pour le groupe ou les autres, afin que seul root puisse modifier la configuration du rapport d'état SELinux.
Vérifié sur l’état résolu en cours d’exécution (ex. sshd -T, sysctl, systemctl show), attrape les drop-ins et Include qu’une lecture de fichier raterait. Réserve : runtime ≠ persistance ; une valeur correcte maintenant peut ne pas survivre à un redémarrage.
Pavois vérifie la configuration effective, l’état résolu et réellement appliqué, pas un fichier. Les scanners basés fichier (OVAL/SCAP, Lynis) ratent les Include, drop-ins et défauts runtime ; ce check voit ce qui est réellement en vigueur.
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
/etc/sestatus.conf indique à la commande sestatus -v les fichiers et processus dont le contexte SELinux doit être rapporté. Bien qu'informatif, il fait partie de l'ensemble de configuration SELinux. S'il est modifiable par le groupe ou les autres, un attaquant pourrait le réécrire pour que les audits de sécurité rapportent un état SELinux trompeur, masquant un système altéré ; les bits setuid/setgid/exécutable n'ont aucune utilité sur un fichier texte. Restreindre les permissions garantit que seul root contrôle la configuration du rapport d'état SELinux.
Ce que vérifie Pavois
Pavois lit les bits de mode réels de /etc/sestatus.conf sur la cible (exécutable/setuid/setgid/sticky/modifiable par groupe et autres), les permissions effectives appliquées par le noyau, et non une base documentée. Les permissions sont des métadonnées d'inode, aucun include ni drop-in ne peut donc les contourner. La garde only_if ignore le contrôle si le fichier est absent.
only_if { file('/etc/sestatus.conf').exist? }
describe file('/etc/sestatus.conf') do
it { should_not be_executable.by('owner') }
it { should_not be_setuid }
it { should_not be_executable.by('group') }
it { should_not be_writable.by('group') }
it { should_not be_setgid }
it { should_not be_executable.by('other') }
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' /etc/sestatus.conf. Attendu : mode -rw-r--r-- (0644) appartenant à root root, sans bit d'écriture pour le groupe/les autres ni bits s/t. Vérification rapide : find /etc/sestatus.conf -perm /0133 ne doit rien renvoyer.
Inspecter et investiguer
Les changements de permissions ne sont pas journalisés par défaut. Surveillez le fichier avec auditd : auditctl -w /etc/sestatus.conf -p wa -k selinux, puis consultez avec grep 'key="selinux"' /var/log/audit/audit.log. L'effet de la configuration est visible en exécutant sestatus -v. Mode et propriété actuels : stat /etc/sestatus.conf.
Remédiation
Aucun plan de durcissement automatisé n'est fourni pour cette règle, elle doit donc être appliquée manuellement : chown root:root /etc/sestatus.conf && chmod 0644 /etc/sestatus.conf. Cela supprime toute écriture groupe/autres et tout bit setuid/setgid/sticky tout en gardant le fichier lisible par tous.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| mode | 0644 |
|---|---|
| path | /etc/sestatus.conf |
| resource | file |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Risque si mal réglé : un /etc/sestatus.conf modifiable permet à un utilisateur non-root de manipuler ce que sestatus -v rapporte, aidant à dissimuler une altération aux administrateurs. Appliquer le correctif est sûr : 0644 root:root est le mode standard et le fichier reste lisible par l'outil sestatus. Précaution : conservez le bit de lecture pour other afin que les requêtes d'état non privilégiées fonctionnent toujours ; aucun redémarrage de service n'est nécessaire.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R50 | direct | 2.0 | 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.