Garantir que SELinux est en mode enforcing
SELinux doit fonctionner en mode enforcing : les refus de la politique sont réellement bloqués, et non simplement journalisés comme en mode permissive. Pavois vérifie à la fois l'état en cours d'exécution (getenforce renvoie Enforcing) et l'intention persistée (SELINUX=enforcing dans /etc/selinux/config). Famille RHEL uniquement.
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.
Ce que vérifie Pavois
getenforce renvoie l'état effectif du noyau, seul juge de savoir si un refus bloque ou se contente d'être journalisé. /etc/selinux/config n'exprime que l'intention au démarrage : elle peut être écrasée depuis la ligne de commande du noyau (selinux=0, enforcing=0), de sorte qu'un hôte peut démarrer en Permissive ou Disabled alors que son fichier de configuration indique enforcing. Lire seulement ce fichier déclarerait conforme une machine dont SELinux est en réalité inactif. Pavois exige donc les deux : l'état en cours et le réglage persisté, pour que le mode survive aussi au redémarrage.
describe command('getenforce') do
its('stdout.strip') { should cmp 'Enforcing' }
end
describe file('/etc/selinux/config') do
its('content') { should match(/^SELINUX=enforcing/) }
endComment vérifier qu’elle est appliquée
Vérifiez le mode en cours, le mode persisté, et qu'aucun paramètre de la ligne de commande du noyau ne désactive SELinux :
getenforce
# Enforcing
sestatus | grep -E 'SELinux status|Current mode|Policy from config'
grep ^SELINUX= /etc/selinux/config
# SELINUX=enforcing
grep -o 'selinux=0\|enforcing=0' /proc/cmdline
# (aucune sortie attendue)
Inspecter et investiguer
Chaque accès refusé par la politique est écrit dans /var/log/audit/audit.log sous forme d'enregistrement AVC (type=AVC ... denied { ... } scontext=... tcontext=...) ; si auditd est arrêté, les mêmes lignes partent dans le journal du noyau (journalctl -k, dmesg). Cherchez avc: directement dans le fichier d'audit brut plutôt que de vous fier à ausearch, connu pour renvoyer de faux « aucun résultat ». En mode permissive, ces mêmes enregistrements AVC sont produits sans rien bloquer : c'est ainsi que l'on inventorie ce que le mode enforcing cassera, et c'est ce que consomment audit2why / audit2allow pour expliquer un refus ou proposer un module de politique.
Remédiation
Le plan Pavois persiste d'abord le mode, relève ensuite l'état en cours, et refuse délibérément le raccourci dangereux. Il réécrit /etc/selinux/config en SELINUX=enforcing / SELINUXTYPE=targeted, puis exécute setenforce 1 seulement si l'état courant est Permissive. Si SELinux a démarré en Disabled, Pavois n'appelle jamais setenforce (la commande échoue, et basculer d'un coup en enforcing un système de fichiers non étiqueté peut enfermer tout le monde dehors) : il crée /.autorelabel à la place, afin que le prochain redémarrage réétiquette l'ensemble du système de fichiers et relance l'hôte en enforcing. Ce redémarrage reste la décision de l'administrateur. Chaque étape est conditionnée à l'existence de /etc/selinux/config : le bloc est donc sans effet sur Debian et Ubuntu.
Pavois applique ceci avec son propre moteur harden, le plan ci-dessous, pas un script shell :
| resource | selinux_state |
|---|---|
| state | enforcing |
pavois harden plan localoù la cible est local, un alias SSH user@hôte, ou un conteneur , Docs
Impact & précautions
Passer en enforcing sur un système qui n'a jamais été étiqueté peut l'empêcher de démarrer. Quand SELinux a tourné en Disabled, les fichiers créés depuis ne portent aucun contexte de sécurité : basculer en enforcing sans réétiquetage complet du système de fichiers empêche init de changer de domaine, et les services (à commencer par sshd et la pile d'authentification) sont refusés. C'est pourquoi Pavois programme /.autorelabel plutôt que de forcer l'état. Avant d'appliquer :
- Depuis
Disabled: prévoyez le réétiquetage puis un redémarrage, et prévoyez du temps (quelques minutes, bien davantage sur un gros système de fichiers, la machine étant indisponible pendant l'opération). Disposez d'un accès console, ne comptez jamais sur le seul SSH. - Depuis
Permissive: c'est le chemin sûr, mais seulement une fois la file des refus vidée. Inventoriez les enregistrements AVC de/var/log/audit/audit.loget corrigez leurs causes (mauvaise étiquette sur un répertoire de données non standard, service en écoute sur un port non standard qui réclamesemanage port, booléen à basculer) avant de passer en enforcing. Tout ce qui reste refusé dans le journal cassera à l'instant où le mode enforcing prendra effet. - Vérifiez la ligne de commande du noyau : un
selinux=0ouenforcing=0oublié annule silencieusement le changement au prochain démarrage.
Mapping des normes
| Norme | Référence | Type | Version | Confiance |
|---|---|---|---|---|
| ANSSI BP-028 | R37 | direct | 2.0 | haute |
| CIS | 1.3.1.5 | direct | per OS, see the benchmark table | haute |
| NIST | AC-3 | support | 800-53 Rev 5 · 800-171 Rev 2 (pinned) | moyenne |
| PCI DSS | 1.2.6 | support | 4.0.1 | moyenne |
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.