Un service démarre, le port écoute, puis l’application reçoit un refus d’accès sur un fichier ou un répertoire. Sur Rocky Linux 9 ou RHEL 9, SELinux peut être la cause, mais couper sa protection masque le problème au lieu de le corriger.
Le diagnostic part du mode actif, du contexte du chemin concerné et du message AVC. Cette méthode permet de corriger un service précis sans transformer le serveur en machine permissive.
Lire le refus avant de modifier une règle
Commencez par confirmer que SELinux applique bien sa politique. Enforcing signifie que les refus sont bloqués. Permissive les journalise sans les bloquer. Disabled retire ce contrôle après redémarrage.
getenforce
sestatusSi le service échoue sur /srv/monapp, regardez le type SELinux attribué au chemin, pas uniquement ses permissions Unix. Un processus HTTP peut avoir les droits rwx sur le répertoire et rester bloqué si le type ne lui convient pas.
ls -Zd /srv /srv/monapp
ls -Z /srv/monappLe journal donne ensuite le processus, le chemin et l’action refusée. Sur RHEL et Rocky, ausearch cible les événements AVC lorsque le paquet audit est présent.
sudo ausearch -m AVC -ts recent
sudo journalctl -t setroubleshoot --since "15 minutes ago"Gardez l’heure du test et le nom du service. Sans cet événement, une commande trouvée au hasard peut autoriser un accès plus large que nécessaire.
Corriger le contexte d’un chemin d’application
Un cas fréquent concerne un répertoire déplacé hors de /var/www. Pour un contenu servi par Apache ou Nginx, appliquez d’abord le type prévu par la politique, puis enregistrez la règle pour les prochains relabels.
sudo semanage fcontext -a -t httpd_sys_content_t "/srv/monapp(/.*)?"
sudo restorecon -Rv /srv/monapp
ls -Zd /srv/monappLe dernier ls -Zd doit afficher httpd_sys_content_t sur le contenu. Si l’application doit écrire dans un sous-répertoire dédié, ne donnez pas un type inscriptible à toute l’arborescence. Isolez le dossier de données, puis utilisez un type adapté comme httpd_sys_rw_content_t uniquement sur ce dossier.
sudo semanage fcontext -a -t httpd_sys_rw_content_t "/srv/monapp/data(/.*)?"
sudo restorecon -Rv /srv/monapp/dataLa documentation Red Hat sur SELinux détaille les types et les booléens livrés avec la politique. Pour un blocage réseau ou un accès à une base distante, cherchez d’abord un booléen documenté avant de fabriquer un module local.
Relancer le service et vérifier le résultat
Redémarrez uniquement le service concerné, puis rejouez l’action qui échouait. Un démarrage réussi ne valide pas toujours l’écriture d’un fichier ou l’accès à un socket.
sudo systemctl restart monapp
sudo systemctl status monapp --no-pager
sudo ausearch -m AVC -ts recentLe contrôle passe quand la fonction métier répond et qu’aucun nouvel AVC ne correspond au test. Un ancien AVC peut rester dans l’historique, comparez donc l’heure de l’événement avec celle du redémarrage.
Quand laisser la politique intacte
setenforce 0 peut confirmer un diagnostic durant quelques minutes sur une VM de test, mais ce n’est pas une réparation de production. Une ligne SELINUX=disabled dans /etc/selinux/config enlève le contrôle après redémarrage et complique le retour à une politique propre.
Je privilégierais un changement de contexte persistant avec semanage fcontext suivi de restorecon. Il décrit le rôle du chemin et survit à un relabel. Cette logique vise SELinux sur RHEL, Rocky ou Fedora. Ubuntu utilise surtout AppArmor, dont les profils et les journaux suivent un autre modèle.
Avant une modification sur un serveur distant, gardez une seconde session SSH ouverte. Si le service dépend d’un chemin partagé ou d’un montage réseau, validez aussi le montage et ses labels avant de modifier la politique SELinux.