Rocky Linux / SELinux : mode permissif, désactivation et réactivation

Sur Rocky Linux, sudo setenforce 0 permet de passer temporairement SELinux en mode permissif, à condition qu’il soit déjà activé. Pour un dépannage, ce mode conserve les traces de refus et évite une désactivation complète ; désactiver puis réactiver SELinux demande aussi de préparer le démarrage et les étiquettes de sécurité des fichiers.

Comprendre et vérifier les trois états

SELinux, pour Security-Enhanced Linux, ajoute des règles de contrôle d’accès aux permissions Unix habituelles. Un fichier peut donc être lisible selon ses permissions, tout en restant inaccessible au domaine SELinux d’un service. Les deux contrôles doivent autoriser l’opération.

getenforce
sestatus
cat /proc/cmdline

Comparez Current mode et Mode from config file dans sestatus : le mode actif et la configuration prévue au démarrage peuvent différer. Examinez aussi les arguments selinux=0 et enforcing=0 dans /proc/cmdline. Modifier uniquement un fichier ne change pas nécessairement le système en cours d’exécution.

Le guide SELinux de Rocky Linux présente les contextes, les modes et les commandes de diagnostic. Les opérations de modification ci-dessous nécessitent un compte autorisé à utiliser sudo. Pour une intervention à distance, préparez une console de secours et relevez l’état initial.

Passer temporairement en mode permissif

Si getenforce affiche Enforcing, relevez l’heure et reproduisez une opération précise en mode permissif :

sudo setenforce 0
getenforce

Le résultat attendu est Permissive. Ce changement global concerne tous les domaines SELinux ; limitez la durée du diagnostic. Il ne modifie pas à lui seul le mode enregistré pour le prochain démarrage. Si SELinux est Disabled, setenforce ne peut pas le réactiver : utilisez la procédure de réactivation plus bas.

Après avoir relevé les journaux et corrigé la cause, revenez au mode initial Enforcing, puis répétez exactement l’opération :

sudo setenforce 1
getenforce

Attendez Enforcing, un service fonctionnel et l’absence de nouveaux refus correspondant au test. Un succès uniquement en mode permissif signale une piste SELinux ; il ne démontre pas qu’une désactivation permanente soit nécessaire. Si le système était déjà permissif avant l’intervention, ne présentez pas le passage en Enforcing comme une simple restauration sans vérifier sa préparation.

Identifier un refus avant de changer les règles

Un message AVC, pour Access Vector Cache, décrit une décision de contrôle d’accès. Recherchez les événements proches de votre essai :

sudo ausearch -m AVC,USER_AVC -ts recent

Comparez le programme et son contexte source, le contexte de la cible, la classe d’objet et la permission demandée. Si la recherche ne retourne rien, cela ne prouve pas que SELinux n’intervient pas : vérifiez la période, la collecte des journaux et le paquet audit qui fournit ausearch. Un service peut aussi échouer avant toute décision SELinux, par exemple sur une erreur de configuration.

Commencez par les permissions Unix, le chemin réellement utilisé et le journal du service. N’élargissez pas une politique à partir de tous les refus d’un serveur sans distinguer l’action légitime d’une erreur ou d’une activité indésirable.

Corriger les étiquettes d’un répertoire web

Prenons un service HTTP déjà configuré pour lire des documents dans le répertoire existant /srv/www. Vérifiez que cette arborescence contient uniquement le contenu concerné, sans autres données de service ni montage inattendu. Le type httpd_sys_content_t convient ici à la lecture de contenu web ; il ne donne pas au serveur le droit d’y écrire.

La commande semanage est fournie sur Rocky Linux par policycoreutils-python-utils. Si elle manque, installez ce paquet depuis vos dépôts configurés avec sudo dnf install policycoreutils-python-utils. Avant toute modification, relevez les étiquettes actuelles et les personnalisations locales :

ls -ldZ /srv/www
sudo semanage fcontext -l -C
sudo restorecon -nRv /srv/www

restorecon -nRv montre les changements proposés sans les appliquer. Une règle fcontext associe un chemin à une étiquette attendue ; elle ne réétiquette pas immédiatement les fichiers. Si aucune règle locale correspondante ne doit être conservée, ajoutez une règle limitée à cette arborescence, examinez à nouveau la proposition, puis appliquez-la :

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/www(/.*)?'
sudo restorecon -nRv /srv/www
sudo restorecon -Rv /srv/www
ls -ldZ /srv/www

Vérifiez le type affiché et retestez la lecture par le service en mode Enforcing. Si une règle existe déjà, arrêtez-vous pour comprendre son rôle ; -m modifie une règle existante, mais ne doit pas écraser une personnalisation sans examen. Les règles locales qui se recouvrent peuvent aussi changer le résultat. Les manuels du projet décrivent la gestion des règles fcontext et le contrôle et l’application des étiquettes avec restorecon.

Pour annuler uniquement la règle nouvellement ajoutée dans cet exemple, supprimez-la, examinez le résultat attendu et appliquez-le si approprié :

sudo semanage fcontext -d '/srv/www(/.*)?'
sudo restorecon -nRv /srv/www
sudo restorecon -Rv /srv/www

Cela rétablit les types attendus par les règles restantes, pas nécessairement chaque ancienne étiquette modifiée manuellement avec chcon. Pour retrouver exactement des étiquettes particulières antérieures, il faut les avoir conservées. Si vous aviez modifié une règle existante, restaurez sa définition enregistrée au lieu de la supprimer.

Ajuster un booléen ou un port précis

Un booléen pour une connexion réseau sortante

Un booléen active une possibilité déjà prévue par la politique. Par exemple, un serveur web faisant office de mandataire vers un autre service peut nécessiter des connexions sortantes. Consultez d’abord la valeur active, la valeur persistante et la description, puis vérifiez qu’aucun booléen plus ciblé ne répond mieux au besoin :

getsebool httpd_can_network_connect
sudo semanage boolean -l | grep httpd_can_network_connect

Le booléen httpd_can_network_connect élargit les connexions réseau autorisées au domaine concerné ; il ne se limite pas à une seule adresse de destination. S’il correspond réellement au refus observé, testez sans persistance :

sudo setsebool httpd_can_network_connect on

Retestez la fonction et les journaux. Pour conserver ce réglage, utilisez ensuite sudo setsebool -P httpd_can_network_connect on. Sans -P, seule la valeur active change ; avec -P, la modification est persistante, comme l’indique le manuel de setsebool.

Si le test est inutile, restaurez la valeur active relevée au départ. Par exemple, sudo setsebool httpd_can_network_connect off convient seulement si elle était initialement désactivée. Si vous avez changé la valeur persistante, restaurez aussi celle-ci avec -P, puis rétablissez séparément l’ancienne valeur active si les deux différaient.

Un type de port pour l’écoute HTTP

Un service autorisé à écouter sur un type de port peut être bloqué sur un autre numéro. Pour un exemple HTTP sur TCP 8088, consultez toutes les affectations, y compris les plages et les personnalisations :

sudo semanage port -l
sudo semanage port -l -C

Si TCP 8088 est déjà associé à http_port_t, aucun ajout n’est nécessaire. S’il possède une affectation spécifique destinée à un autre service, ne la remplacez pas automatiquement. Lorsque l’ajout est approprié :

sudo semanage port -a -t http_port_t -p tcp 8088

Le manuel de semanage port distingue l’ajout -a, la modification -m et la suppression -d. Une erreur indiquant un port déjà défini exige de revenir à l’inventaire, pas de remplacer aveuglément -a par -m.

Vérifiez aussi que l’application écoute effectivement sur ce port. SELinux et le pare-feu firewalld sont deux contrôles distincts : une affectation de type n’ouvre pas le pare-feu. Pour retirer seulement l’ajout de cet exemple, utilisez sudo semanage port -d -p tcp 8088, puis contrôlez les affectations restantes. Pour une règle modifiée plutôt qu’ajoutée, restaurez le type d’origine enregistré.

Préparer un mode persistant

Avant d’éditer la configuration, créez une sauvegarde sans écraser les copies précédentes :

sudo cp --backup=numbered -a /etc/selinux/config /etc/selinux/config.backup
sudoedit /etc/selinux/config

Pour conserver le mode permissif au démarrage pendant une investigation, modifiez la ligne existante, sans créer plusieurs définitions :

SELINUX=permissive

Contrôlez le fichier, le mode courant et les arguments du noyau :

grep '^SELINUX=' /etc/selinux/config
getenforce
cat /proc/cmdline

Le fichier ne fait pas basculer la session actuelle : si SELinux est activé, utilisez séparément setenforce pour le mode courant. Un argument du noyau peut modifier le comportement au démarrage ; identifiez son origine dans le chargeur ou l’outil de gestion de votre machine avant d’annoncer qu’un redémarrage appliquera la valeur voulue. Gardez la sauvegarde et la valeur initiale pour revenir à votre configuration précédente.

Désactiver complètement puis réactiver SELinux

Cette intervention implique un redémarrage et peut affecter l’accès aux services. Identifiez la version réelle de Rocky, disposez d’une console de récupération et conservez la configuration ainsi que les arguments de démarrage initiaux :

cat /etc/rocky-release
rpm -q grubby
cat /proc/cmdline
sudo grubby --info=ALL

Sur une installation dont les entrées de démarrage sont gérées par grubby, la procédure documentée pour RHEL 9 ajoute selinux=0 :

sudo grubby --update-kernel ALL --args selinux=0

Après le redémarrage planifié, vérifiez getenforce et /proc/cmdline ; le résultat attendu est Disabled. La documentation RHEL 9 sur les modes SELinux décrit aussi la réactivation. Ne transposez pas cette procédure à un chargeur différent sans vérifier sa documentation.

Pour réactiver, préparez d’abord SELINUX=permissive dans le fichier sauvegardé précédemment. Avec le même chargeur, retirez l’argument de désactivation et prévoyez un démarrage permissif :

sudo grubby --update-kernel ALL --remove-args selinux
sudo grubby --update-kernel ALL --args enforcing=0

Redémarrez depuis la console préparée, attendez la fin d’un éventuel réétiquetage automatique et confirmez Permissive. Alors seulement, préparez un réétiquetage complet supplémentaire :

sudo fixfiles -F onboot

Ce contrôle suit la précaution documentée de lancer fixfiles depuis le mode permissif. Prévoyez un nouveau redémarrage, laissez le réétiquetage se terminer, puis testez les services et traitez les refus avant d’activer Enforcing.

Quand les vérifications sont satisfaisantes, configurez SELINUX=enforcing, retirez uniquement l’argument enforcing=0 ajouté pour cette intervention et passez le système courant avec sudo setenforce 1. Contrôlez ensuite le mode actif et un démarrage planifié. Un argument préexistant ou imposé par une gestion centralisée nécessite une restauration conforme à cette configuration.

Vérifier que la correction tient en mode Enforcing

1. Notez le mode initial, la configuration et l’opération en échec.
2. Écartez une erreur du service, des permissions Unix ou du pare-feu.
3. Si nécessaire, comparez la même opération en mode permissif pendant une courte fenêtre.
4. Corrigez le contexte, le booléen ou le port correspondant au refus réellement observé.
5. Revenez à Enforcing, répétez l’essai et recherchez de nouveaux refus liés à cet essai.
6. Après un changement persistant, vérifiez aussi le prochain démarrage et conservez les informations de retour arrière.