SELinux pas à pas sur RHEL 10 pour RHCSA

SELinux fait chuter plus de candidats RHCSA EX200 que tout autre sujet. Pourtant, sa mécanique repose sur quelques concepts solides qui, une fois assimilés, transforment la grande majorité des dénis en cinq commandes maîtrisées. Sur Red Hat Enterprise Linux 10, SELinux est activé en mode enforcing avec la politique targeted par défaut, et il n’est ni envisageable ni recommandé de le désactiver pour contourner un problème. Ce tutoriel parcourt l’ensemble pas à pas, depuis la lecture d’un contexte jusqu’à la création d’une politique personnalisée avec audit2allow.

Prérequis avant de commencer

• Un système RHEL 10, Rocky Linux 10 ou AlmaLinux 10 fonctionnel.
• Un accès sudo ou root.
• Les paquets policycoreutils, policycoreutils-python-utils, setools-console et setroubleshoot-server installés (présents par défaut sur la plupart des installations Server).
• Niveau attendu : intermédiaire. Temps estimé : 90 minutes.

Étape 1 — Vérifier l’état actuel de SELinux

Avant toute manipulation, on vérifie que SELinux est actif et dans quel mode. Une seule commande donne la totalité de l’information.

sestatus
getenforce
cat /etc/selinux/config

La sortie de sestatus liste sept ou huit informations : SELinux status doit être enabled, Current mode doit être enforcing, Loaded policy name doit être targeted. La commande getenforce retourne uniquement le mode courant, plus rapide à lire dans un script. Le fichier /etc/selinux/config contient la configuration persistante : SELINUX=enforcing et SELINUXTYPE=targeted sur une installation par défaut. Toute autre valeur indique une modification volontaire qui exige justification.

Étape 2 — Basculer entre modes enforcing et permissive

SELinux a trois modes : enforcing applique la politique, permissive ne bloque rien mais journalise tout, disabled le coupe complètement. La bascule entre enforcing et permissive est instantanée et ne demande pas de reboot. Le passage en disabled exige un reboot et n’est pas recommandé.

sudo setenforce 0                        # Bascule en permissive (temporaire)
getenforce
sudo setenforce 1                        # Retour en enforcing
getenforce

L’utilité de permissive tient au diagnostic : si l’on suspecte SELinux de bloquer une opération, on bascule en permissive, on rejoue l’opération, on consulte les logs AVC pour comprendre, puis on revient en enforcing et on corrige les contextes. Le passage à SELINUX=disabled dans /etc/selinux/config n’est jamais une solution sur RHEL 10 — il rend la machine non conforme aux exigences de sécurité par défaut et casse les tâches d’examen RHCSA.

Étape 3 — Lire un contexte de fichier

Chaque fichier porte un contexte SELinux constitué de quatre champs : utilisateur, rôle, type, niveau. Le champ qui compte presque toujours est le type, qui détermine ce qu’un processus est autorisé à faire avec ce fichier.

ls -Z /var/www/html/index.html
ls -Z /etc/passwd
ps -eZ | grep sshd

L’option -Z ajoutée à ls ou ps affiche les contextes SELinux. Pour /var/www/html/index.html, le type attendu est httpd_sys_content_t ; pour /etc/passwd, c’est passwd_file_t ; pour sshd, le contexte de processus est sshd_t. Les politiques SELinux disent par exemple « un processus de type httpd_t peut lire les fichiers de type httpd_sys_content_t ». Tout déplacement ou copie qui change le type de fichier provoque un déni quand le processus consommateur tente d’y accéder.

Étape 4 — Restaurer un contexte avec restorecon

L’erreur la plus courante : un fichier déplacé avec mv conserve son contexte d’origine au lieu d’hériter de celui de la destination. La commande restorecon réapplique le contexte attendu d’après les règles de la politique.

cp /etc/hosts /tmp/hosts
mv /tmp/hosts /var/www/html/hosts
ls -Z /var/www/html/hosts                # Affiche le mauvais type, hérité de /tmp
sudo restorecon -v /var/www/html/hosts
ls -Z /var/www/html/hosts                # Affiche maintenant httpd_sys_content_t

L’option -v active la sortie verbeuse — utile pour confirmer que restorecon a effectivement modifié le contexte. Pour appliquer récursivement à un répertoire entier, restorecon -Rv /var/www/html/ traite l’arborescence en une seule passe. C’est la commande à connaître par cœur — elle résout 80 % des dénis SELinux rencontrés sur RHCSA.

Étape 5 — Modifier durablement un contexte avec semanage fcontext

Quand un service doit servir des fichiers depuis un répertoire non standard — par exemple Apache servant /srv/web/ au lieu de /var/www/html/ — il faut enregistrer la nouvelle règle dans la base SELinux pour que restorecon la connaisse.

sudo mkdir -p /srv/web
echo 'Contenu test' | sudo tee /srv/web/index.html

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/web(/.*)?'
sudo restorecon -Rv /srv/web
ls -Z /srv/web

L’expression régulière (/.*)? couvre le répertoire et tout ce qu’il contient récursivement. La commande semanage fcontext -a ajoute la règle ; sans l’exécution de restorecon derrière, les fichiers existants gardent l’ancien contexte. Pour vérifier que la règle a été enregistrée, semanage fcontext -l | grep /srv/web doit lister la nouvelle règle. La directive -d au lieu de -a supprime une règle ; -m la modifie sans la recréer.

Étape 6 — Gestion des ports avec semanage port

Un service écoutant sur un port non standard provoque un déni SELinux à moins que ce port soit déclaré comme appartenant au type approprié. Faire écouter Apache sur le port 8080 par exemple exige une déclaration explicite.

sudo semanage port -l | grep http_port_t
sudo semanage port -a -t http_port_t -p tcp 8080
sudo semanage port -l | grep http_port_t
# Pour retirer ensuite :
sudo semanage port -d -t http_port_t -p tcp 8080

La sortie initiale de semanage port -l | grep http_port_t liste les ports déjà associés à http_port_t : 80, 81, 443, 488, 8008, 8009, 8443, 9000. Après semanage port -a, le 8080 apparaît dans la liste. Si le service refuse encore de démarrer après ajout du port, vérifier avec ausearch -m AVC si un autre déni — par exemple sur les fichiers de configuration — bloque le démarrage.

Étape 7 — Booléens SELinux

Les booléens activent ou désactivent des comportements précis sans modifier la politique. Ils permettent par exemple d’autoriser Apache à exécuter des scripts CGI, à faire du proxy HTTP, ou à accéder à des montages NFS — tout cela sans toucher aux contextes ni aux types.

getsebool -a | grep httpd_can_network    # Liste les booléens HTTPd réseau
sudo setsebool -P httpd_can_network_connect on
getsebool httpd_can_network_connect

Sans l’option -P, le booléen est modifié uniquement en mémoire et l’état repasse à la valeur par défaut au prochain reboot. Avec -P, la modification est persistante. C’est le piège classique : un service réparé en bidouillant setsebool sans -P redevient cassé après reboot. La commande semanage boolean -l donne une vue tabulaire avec valeur courante, valeur par défaut et description, plus lisible que getsebool -a.

Étape 8 — Diagnostiquer un déni AVC

Quand SELinux refuse une opération, il génère un message AVC dans le journal d’audit. Trois outils permettent de remonter au coupable et à la solution.

sudo ausearch -m AVC -ts recent          # Dénis récents
sudo ausearch -m AVC,USER_AVC -ts today  # Tous les types AVC du jour
sudo sealert -a /var/log/audit/audit.log | head -60

La commande ausearch filtre le log d’audit par type d’événement et plage temporelle. Chaque entrée AVC indique le contexte source, le contexte cible, l’opération refusée et le chemin éventuellement concerné. La commande sealert du paquet setroubleshoot-server traduit ces entrées brutes en explications humaines avec suggestion de correction — souvent une commande setsebool, semanage fcontext ou restorecon précise. La sortie de sealert est ce qu’il faut consulter en premier sur un système qui refuse mystérieusement un service.

Étape 9 — Politique personnalisée avec audit2allow

Pour les cas que les outils standard ne couvrent pas, on peut générer un module de politique personnalisé à partir des dénis observés. Cette approche est à manier avec prudence : elle accorde des permissions, et un module trop large affaiblit la sécurité.

sudo ausearch -m AVC -ts recent | audit2allow -M monmodule
sudo semodule -i monmodule.pp
sudo semodule -l | grep monmodule

audit2allow -M génère deux fichiers : monmodule.te qui contient la politique en clair, et monmodule.pp qui en est la forme compilée. Toujours lire le fichier .te avant d’installer le module — il indique exactement quelles permissions sont accordées. Si le module accorde des accès trop larges (par exemple allow domain_t self:capability_class_set { all };), il faut affiner manuellement avant compilation. La commande semodule -i charge le module dans le noyau ; semodule -r monmodule le retire.

Étape 10 — Vérifier la cohérence après changements

sestatus
sudo semanage fcontext -l -C              # Règles fcontext personnalisées (locales)
sudo semanage port -l -C                  # Règles port personnalisées
sudo semodule -l --modified                # Modules modifiés vs politique de base
sudo restorecon -Rv /chemin                # Réapplique partout dans une arborescence

Sur un système RHCSA propre après une session de manipulation, les sorties de -C doivent contenir uniquement les règles ajoutées délibérément. Tout reste indésirable signale une trace d’expérimentation à nettoyer. Pour relabeller l’ensemble du système — opération à effectuer par exemple après une longue session en permissive — la commande fixfiles -F onboot programme un relabel complet au prochain reboot.

Erreurs fréquentes

Adaptation aux serveurs partagés

Sur des serveurs hébergeant plusieurs services indépendants, l’utilisation de confined users renforce l’isolement entre administrateurs. La commande semanage user -a -R 'staff_r' compta_u crée un utilisateur SELinux limité au rôle staff_r, ce qui empêche les commandes administratives standard. Cette configuration dépasse le périmètre RHCSA strict mais reste utile à connaître pour qui prépare RHCE par la suite.

Tutoriels frères

• Gérer utilisateurs, groupes et permissions sur RHEL 10
• DNF 5, Flatpak et la gestion des paquets sur RHEL 10

Pour explorer plus loin

• 🔝 Retour à l’article principal : RHCSA EX200 v10 : la voie d’entrée Linux entreprise
• Documentation officielle : Using SELinux RHEL 10
• SELinux Notebook (référence communautaire approfondie)

Questions fréquentes

Désactiver SELinux pour gagner du temps est-il acceptable ?

Non, jamais. Sur RHEL 10, désactiver SELinux casse la posture de sécurité par défaut, échoue toute conformité CIS Benchmark et est sanctionné à RHCSA. Toutes les difficultés rencontrées trouvent une solution propre via restorecon, semanage ou les booléens.

Faut-il connaître les ports SELinux par cœur ?

Non. Il faut savoir interroger la base avec semanage port -l | grep type_t et ajouter un port avec semanage port -a. La documentation reste accessible pendant l’examen via man semanage-port.

Comment réinitialiser tous les contextes du système ?

La commande fixfiles -F onboot programme un relabel complet au prochain démarrage. Le boot suivant prendra plusieurs minutes mais restaurera la totalité des contextes. Cette opération est rare et n’est pas dangereuse en soi.

Que faire en cas de relabel impossible au boot ?

Démarrer en rescue, vérifier que /.autorelabel existe ou créer ce fichier avec touch /.autorelabel, puis rebooter. Le système relabellera intégralement avant de continuer le démarrage normal.

Les conteneurs Podman respectent-ils SELinux ?

Oui. Podman applique des contextes spécifiques aux conteneurs (container_t) et aux volumes (container_file_t). Pour partager un répertoire de l’hôte avec un conteneur, ajouter le suffixe :Z ou :z sur l’option -v demande à Podman de relabeller automatiquement le répertoire avec le bon contexte.

Comment savoir quel booléen activer pour un cas donné ?

La commande sealert sur un déni récent suggère systématiquement le booléen pertinent quand il en existe un. semanage boolean -l | grep mot-cle permet aussi de chercher dans les descriptions humaines.