Sur un serveur Linux exposé, SELinux fait la différence entre un incident contenu et une panne générale. Ce mécanisme de sécurité informatique ne remplace pas les permissions Unix, il ajoute une couche de contrôle d’accès indépendante, pilotée par une politique de sécurité décrivant précisément qui peut faire quoi, où et comment. Bien utilisé, il limite les mouvements latéraux après compromission, réduit l’impact des failles zero-day et évite qu’un simple service web se transforme en porte d’entrée vers tout le système. Mal compris, il est souvent accusé de bloquer « sans raison » et finit trop vite désactivé.
Les équipes qui administrent déjà des distributions de type RHEL, Rocky Linux ou Fedora voient passer SELinux dans tous les rapports d’audit, mais rarement dans les procédures d’exploitation. Pourtant, la plupart des incidents attribués à ce module se résument à trois causes répétitives : contextes de sécurité incorrects, ports non déclarés et booléens mal réglés. L’enjeu concret consiste donc moins à apprendre une nouvelle théorie de la sécurité qu’à savoir lire les journaux, corriger les étiquettes avec les bons outils et choisir entre mode enforcing, mode permissif et désactivation SELinux uniquement en connaissance de cause. C’est exactement ce que montre la suite, avec un fil rouge très simple : un serveur web d’entreprise que l’on fait passer progressivement d’un Linux « nu » à un Linux correctement durci.
En bref
- SELinux ajoute un contrôle d’accès obligatoire au noyau Linux et complète les permissions classiques, il ne les remplace pas.
- Pour garder la sécurité informatique au bon niveau, mieux vaut rester en mode enforcing global et n’utiliser le mode permissif que pour diagnostiquer un domaine précis.
- Une configuration SELinux robuste repose sur trois réflexes : étiquettes cohérentes, ports déclarés, booléens documentés.
- La désactivation SELinux doit rester une exception temporaire, jamais un réflexe de confort en production.
- Les contextes de fichiers et de processus (contextes de sécurité) sont le vrai levier d’action pour adapter la politique de sécurité aux besoins métier.
SELinux et le contrôle d’accès obligatoire : remettre les bases à plat
Pour comprendre où SELinux apporte quelque chose, il faut repartir du modèle classique de Linux. Le système repose sur le DAC, pour Discretionary Access Control. En clair, un processus hérite des droits de l’utilisateur qui l’exécute, et ces droits s’expriment par le triptyque propriétaire/groupe/autres sur chaque fichier ou répertoire. Tant que tout le monde respecte la règle du « moindre privilège », ça tient, mais une fois qu’un service réseau est compromis, l’attaquant se retrouve avec les mêmes droits que le démon qu’il contrôle. Sur un serveur mal compartimenté, ça ouvre vite beaucoup trop de portes.
SELinux amène un modèle différent, le MAC, Mandatory Access Control. Le noyau applique une politique de sécurité indépendante des permissions Unix, basée sur des contextes de sécurité attachés aux processus, fichiers, ports et autres ressources. Un processus tourne dans un domaine (par exemple httpd_t pour un Apache) et ne peut interagir qu’avec des objets dont le type a été explicitement autorisé dans la politique. Ce n’est pas l’administrateur système qui décide au cas par cas, c’est la politique globale qui tranche sur chaque accès.
Dans un environnement industriel où les serveurs applicatifs côtoient parfois des automatismes critiques, ce découplage est précieux. Un service web vulnérable ne devrait jamais pouvoir toucher, même accidentellement, un fichier système sensible comme /etc/shadow ou les répertoires de configuration d’un bus de terrain. Avec SELinux, un processus étiqueté httpd_t ne dispose tout simplement pas des permissions MAC nécessaires pour ces ressources, même si les droits Unix sembleraient suffisants. On parle souvent de « confinement » des processus, ce n’est pas une métaphore exagérée.
Il y a un revers : la complexité. Un profil SELinux complet pour un serveur standard représente plusieurs milliers de règles. Red Hat et ses dérivés ont investi lourdement pour livrer des politiques qui tiennent la route en conditions réelles, mais pour l’administrateur lambda, l’ensemble ressemble d’abord à une boîte noire. C’est d’ailleurs une des raisons pour lesquelles certains fournisseurs d’hébergement désactivent SELinux par défaut sur leurs images. La logique n’est pas technique, elle est commerciale : réduire le nombre de tickets liés à des refus d’accès mal compris.
Les distributions de la famille RHEL, y compris Rocky Linux, activent SELinux en mode enforcing sur une installation standard, avec une politique dite « ciblée ». Dans ce mode ciblé, seuls les démons exposés au réseau et quelques services critiques sont placés sous surveillance stricte, tandis que les processus utilisateurs restent en domaine non confiné. Pour un serveur classique, c’est un compromis raisonnable entre durcissement de la sécurité informatique et complexité opérationnelle. À l’inverse, certaines distributions comme Debian ou Ubuntu misent plutôt sur AppArmor, un autre système MAC, ce qui impose de choisir ses outils en cohérence avec sa couche Linux. Sur ce point, un détour par une synthèse des systèmes d’exploitation sur Linux en contexte IoT et serveur éclaire bien les choix possibles.
Un point mérite d’être posé clairement : le débat récurrent sur l’origine de SELinux, développé à l’origine par la NSA. Les suspicions de porte dérobée reviennent régulièrement dans les discussions de couloir. Dans la pratique, le module reste du code libre, longuement audité par la communauté et par des acteurs industriels qui n’ont aucune intention de laisser un service de renseignement se promener dans leurs datacenters. Sur ce sujet précis, la méfiance se trompe d’ennemi : le risque réel vient des configurations bricolées, des règles ajoutées à la va-vite et des désactivations définitives.
Au bout du compte, SELinux sert surtout à forcer une discipline : chaque service vital doit être clairement délimité, ses fichiers identifiés, ses ports connus, ses interactions définies par une politique explicite. C’est cette discipline qui, quand elle manque, fait dérailler les infrastructures dans la durée.
Modes SELinux : enforcing, permissif et désactivé, à quoi ils servent vraiment
Dans l’exploitation quotidienne, les administrateurs jonglent surtout avec trois états. Le mode enforcing applique intégralement la politique de sécurité SELinux : tout ce qui n’est pas explicitement autorisé est bloqué, et un refus est enregistré dans les journaux d’audit SELinux. Le mode permissif laisse passer les accès mais journalise tout ce qui aurait été refusé. Enfin, la désactivation SELinux supprime complètement la couche MAC, plus aucun refus ni journalisation ne sont produits.
Dans la vie réelle d’une DSI, ces modes servent à des choses très différentes. Le mode enforcing doit rester la norme en production, quitte à être doublé d’un monitoring des AVC (les entrées de refus) afin de repérer les dérives. Le mode permissif est un outil de diagnostic : basculer temporairement en permissif sur une préproduction permet de voir ce que SELinux bloquerait sans pour autant casser les tests fonctionnels. Quant au mode désactivé, il se justifie essentiellement lors de migrations lourdes ou de retours arrière d’urgence, sur une fenêtre la plus courte possible.
Une pratique intéressante, encore trop peu utilisée, consiste à activer le mode permissif par domaine plutôt que globalement. SELinux permet par exemple de déclarer le domaine httpd_t en permissif tout en gardant le reste du système en enforcing. C’est très pratique lorsqu’un nouveau module PHP ou une application web maison se comporte mal : les refus sont visibles dans les journaux, mais les sites continuent de répondre, ce qui laisse le temps de corriger les étiquettes et les booléens sans interruption de service.
Dernier point à ne pas négliger lorsque l’on passe d’un mode disabled à un mode actif : le réétiquetage complet du système de fichiers. SELinux stocke ses contextes de sécurité dans les attributs étendus des fichiers. Après une longue période de désactivation, ces attributs peuvent être incomplets ou incohérents. Sur les distributions de type RHEL/Rocky, la création d’un fichier /.autorelabel suivie d’un redémarrage force un parcours complet du disque et réapplique les étiquettes par défaut, en s’appuyant sur la base de contexte livrée par la politique. Ignorer cette étape, c’est s’exposer à des refus d’accès incompréhensibles dès le retour en enforcing.
On pourrait résumer ce premier bloc par une règle simple : les modes SELinux ne sont pas des positions idéologiques, ce sont des outils de conduite de changement. Celui qui les traite comme un interrupteur binaire fini presque toujours par renoncer à la couche MAC, faute de méthode.
Comprendre les contextes de sécurité SELinux et les politiques ciblées
Dès qu’un administrateur commence à manipuler SELinux, il se retrouve confronté à une syntaxe inhabituelle, du type unconfined_u:object_r:httpd_sys_content_t:s0. C’est le contexte de sécurité d’un fichier. La structure complète suit le modèle utilisateur:rôle:type:niveau. Pour la majorité des opérations d’exploitation, c’est le type qui compte vraiment. Le type d’un processus (par exemple httpd_t) définit son domaine d’exécution, et le type d’un fichier (par exemple httpd_sys_content_t) définit à quelle catégorie de ressources il appartient.
Sur un serveur web minimal, cette logique devient très concrète. Les binaires et processus Apache sont étiquetés avec le type httpd_t. Les fichiers de configuration portent httpd_config_t, les journaux httpd_log_t, les pages servies par le site httpd_sys_content_t. La politique de sécurité SELinux, intégrée à la distribution, autorise explicitement un domaine httpd_t à lire httpd_sys_content_t, à écrire dans httpd_log_t, mais certainement pas à modifier des fichiers de type shadow_t ou sshd_config_t. Une fois que ces règles sont chargées, discuter des droits Unix d’Apache sur /etc/shadow n’a plus de sens : le noyau les court-circuite au profit du modèle MAC.
La politique dite « targeted » fournie par Red Hat et ses dérivés repose sur ce principe. Elle ne prétend pas couvrir chaque binaire et chaque script du système. Elle se concentre sur une liste de services bien identifiés, exposés au réseau ou réputés sensibles. Les autres processus tournent dans un domaine non confiné (unconfined_t), ce qui permet une adoption progressive. Ce choix n’est pas parfait, mais il a le mérite de rester exploitable sans une équipe dédiée à SELinux.
Un exemple pratique illustre bien la mécanique. Sur un serveur Rocky Linux fraîchement installé, Apache est activé avec sa configuration par défaut et SELinux en enforcing. Le contenu de /var/www/html porte l’étiquette httpd_sys_content_t, tout fonctionne. Si l’on copie la page index.html ailleurs, par exemple dans /srv/html, puis qu’on la ramène dans /var/www/html, cette nouvelle copie récupère le type var_t hérité de l’endroit où elle a été créée. Le serveur web, qui a le droit de lire httpd_sys_content_t, se voit refuser l’accès à ce fichier var_t. Du point de vue Unix, les droits sont corrects, mais SELinux bloque la lecture. C’est exactement le genre de situation qui pousse certains administrateurs à maudire le module.
En se tournant vers les journaux d’audit SELinux, l’histoire devient plus claire. Une entrée AVC signale que le domaine httpd_t a tenté un getattr ou un read sur un objet var_t et que la politique refuse cette interaction. L’outil sealert résume l’analyse et suggère souvent une commande restorecon pour rétablir le contexte par défaut du fichier. Une fois cette commande exécutée sur /var/www/html, index.html récupère son type httpd_sys_content_t, et le site redevient accessible. Autrement dit, le problème ne venait pas d’Apache ni du pare-feu, mais d’une étiquette incohérente.
La leçon est simple : SELinux ne se configure pas en modifiant des fichiers de politique à la main dès le premier jour. Dans 80 % des cas, corriger des contextes de sécurité avec restorecon ou semanage fcontext suffit. Tenter de contourner ce mécanisme avec des chcon à la chaîne ou, pire, avec des règles audit2allow générées à partir de quelques journaux tronqués revient à empiler de la dette technique sous la couche de sécurité. Ceux qui s’y sont essayé sur des plateformes conteneurisées le paient rapidement lors des audits.
Dans des architectures plus modernes, mêlant conteneurs, microservices et volumes partagés, cette logique d’étiquettes reste valable. Les moteurs de conteneur compatibles SELinux, comme Podman ou Docker sur Rocky Linux, ajoutent des suffixes :Z ou :z aux montages de volumes pour ajuster les contextes de manière contrôlée. Les fichiers montés en :Z reçoivent une étiquette privée pour le conteneur, ceux en :z partagent une étiquette commune entre plusieurs instances. Là encore, c’est la politique associée aux types utilisés qui dicte ce que le processus en conteneur a le droit de faire ou non avec ces fichiers.
En résumé, comprendre les types et les contextes de sécurité, c’est gagner la clé principale de SELinux. Tout le reste, booléens, ports, modules additionnels, s’appuie sur ce socle. Ignorer cette couche, c’est s’embarquer dans des bricolages qui masqueront un temps les symptômes sans traiter la cause.
Configuration SELinux sur un serveur Linux : méthode terrain étape par étape
Pour un responsable système qui exploite des serveurs applicatifs, la bonne approche consiste à traiter SELinux comme on traite un automatisme industriel : on documente l’état initial, on applique les changements un par un, on mesure les effets, puis seulement on généralise. Un fil conducteur utile est celui d’une PME qui déploie une plateforme web métier sur Rocky Linux avec SELinux activé. L’objectif n’est pas d’écrire une thèse, mais d’arriver à une configuration SELinux reproductible, compréhensible et transmissible à l’équipe d’astreinte.
Première étape, vérifier l’état actuel. Les commandes getenforce et sestatus indiquent respectivement le mode courant et un état plus détaillé, incluant la politique chargée et les points de montage. Si le mode affiché est « Disabled », il faudra anticiper un réétiquetage complet avant de revenir en enforcing. Si le mode est déjà permissif ou enforcing, le socle est en place. À ce stade, installer les paquets policycoreutils, selinux-policy-targeted, setools-console, setroubleshoot-server et auditd constitue un minimum pour disposer des bons outils.
Vient ensuite le choix du mode de fonctionnement. Sur un serveur en production, il serait hasardeux de passer d’un coup en enforcing sans visibilité sur les refus potentiels. La pratique raisonnable consiste à travailler d’abord sur un environnement de préproduction configuré à l’identique, en mode permissif. On fait tourner l’application métier, on déclenche les cas d’usage habituels, puis on analyse les journaux d’audit SELinux. Les outils ausearch, sealert et audit2why permettent de comprendre quels accès seraient bloqués en enforcing et pourquoi.
Dans la plupart des cas, les ajustements se répartissent en trois lots. D’abord, l’étiquetage des chemins personnalisés avec semanage fcontext puis restorecon pour les rendre compatibles avec le domaine utilisé. Un document root déplacé sous /srv/webapp/public doit par exemple être mappé sur le type httpd_sys_content_t, tandis que les répertoires d’upload et de cache recevront httpd_sys_rw_content_t. Ensuite, la déclaration des ports non standard via semanage port, pour que SELinux considère un port 8080 comme un http_port_t légitime pour un service web. Enfin, l’activation ciblée de quelques booléens via setsebool -P, comme httpd_can_network_connect lorsqu’une application web dialogue avec des API externes.
Une fois ces fondations en place, le passage en mode enforcing peut se faire d’abord sur la préproduction, puis progressivement en production, idéalement pendant une fenêtre maîtrisée. Les refus qui subsistent sont souvent liés à des cas d’usage moins fréquents ou à des scripts d’administration qui manipulent des répertoires en dehors des chemins prévus. Là encore, la première réaction ne devrait pas être de désactiver SELinux, mais d’inspecter les journaux, de corriger les étiquettes ou d’ajouter le port manquant.
Pour fixer les idées, il est utile de comparer rapidement les trois modes dans un tableau, avec un prisme très opérationnel.
| Mode SELinux | Comportement | Usage typique | Risques principaux |
|---|---|---|---|
| Enforcing | Applique la politique et bloque les accès non autorisés, journalise les refus. | Production stabilisée, environnements sensibles, hébergement multi-clients. | Blocages si l’étiquetage et les booléens n’ont pas été préparés. |
| Permissif | N’applique pas les blocages, mais enregistre ce qui aurait été refusé. | Recette, préproduction, phases de montée de version ou d’intégration applicative. | Fausse impression de sécurité si on oublie de repasser en enforcing. |
| Disabled | Désactive totalement le contrôle d’accès SELinux, aucune journalisation MAC. | Dépannage exceptionnel, migration complexe avec faible tolérance à la panne. | Perte complète de la couche MAC, surface d’attaque nettement plus large. |
Ce tableau rappelle une évidence que certains audits de terrain confirment régulièrement : beaucoup de serveurs critiques restent bloqués en mode permissif pendant des années, parce que la phase de correction n’a jamais été planifiée. C’est souvent moins un problème technique qu’un manque de processus. Une fois que SELinux devient un item à part entière dans les checklists de mise en production, ces dérives disparaissent.
On retrouve la même logique sur des stacks plus modernes, avec des conteneurs orchestrés. Là, SELinux devient un allié pour empêcher qu’un worker compromis puisse monter un volume sensible au-delà de ce que l’orchestrateur prévoit. L’article sur la gestion des images Docker et des conteneurs illustre bien la manière dont les profils de sécurité hôte interagissent avec les workloads applicatifs. SELinux ne remplace évidemment pas un cluster Kubernetes bien conçu, mais il évite qu’une erreur isolée sur un pod déborde vers tout l’hôte.
Au final, une configuration SELinux propre suit le même schéma qu’un plan de câblage soigné : les chemins sont identifiés, les ports repérés, les usages documentés. Tout ce qui déroge à ce plan doit passer par une décision explicite, pas par une commande tapée à minuit sur une console d’astreinte.
Affiner la politique de sécurité : étiquetage, ports, booléens et audit SELinux
Une fois les bases posées, la vraie valeur de SELinux se gagne dans le réglage fin de la politique de sécurité autour des services métier. L’exemple du serveur web reste parlant, mais la même logique s’applique à une base de données, à un serveur NFS ou à une brique de supervision. Le trio gagnant reste le même : étiquettes persistantes, ports correctement associés et booléens strictement nécessaires.
Côté fichiers, l’outil central est semanage fcontext. Il permet de définir des règles d’étiquetage persistantes pour un chemin ou une arborescence. Par exemple, pour déclarer que tout ce qui se trouve sous /srv/webapp/public doit recevoir httpd_sys_content_t, on ajoute une entrée correspondante, puis on applique ces règles au système de fichiers avec restorecon. À partir de là, tout fichier installé ou restauré à cet emplacement héritera automatiquement du bon type. C’est ce mécanisme qui permet d’éviter les effets de bord après une restauration de sauvegarde ou le déploiement d’une nouvelle version applicative.
Les ports suivent la même approche. Chaque service surveillé par SELinux est associé à un ou plusieurs types de port, comme http_port_t pour le web ou mysqld_port_t pour une base MariaDB. Si l’on décide de faire écouter Apache sur 8080 au lieu de 80, le pare-feu n’est pas le seul élément concerné. Il faut aussi déclarer ce port 8080 comme http_port_t pour que le domaine httpd_t ait le droit de s’y lier. C’est le rôle de semanage port. Sans cette déclaration, le service refusera de démarrer en mode enforcing, même si les permissions Unix semblent correctes.
Reste le troisième levier, souvent sous-estimé : les booléens. Ces commutateurs activent ou désactivent des pans entiers de la politique sans avoir à réécrire des règles. Le booléen httpd_can_network_connect, par exemple, autorise les processus httpd à initier des connexions sortantes. Pratique pour des appels API, des accès Redis ou des webhooks, mais à manier avec parcimonie, car il ouvre une surface de sortie non négligeable. La bonne pratique consiste à activer uniquement les booléens qui correspondent à des besoins clairement identifiés et documentés, en oubliant les « on verra plus tard ».
Pour ne pas transformer le système en puzzle illisible, une démarche structurée peut être utile :
- recenser les services concernés (web, base, supervision, stockage réseau) et leurs chemins/ports spécifiques ;
- décider pour chaque service quels répertoires doivent être lisibles, lesquels doivent être inscriptibles, et sur quels ports ils doivent écouter ;
- mettre en place les règles semanage fcontext et semanage port correspondantes, puis appliquer restorecon ;
- identifier les booléens associés au service et n’en activer que le minimum nécessaire, avec setsebool -P ;
- surveiller les journaux d’audit SELinux pendant plusieurs jours d’exploitation, corriger les anomalies, puis geler la configuration.
Sur le terrain, la tentation d’utiliser directement chcon pour modifier l’étiquette d’un fichier est forte, car la syntaxe semble plus simple. Le problème est qu’un simple restorecon ultérieur effacera ces changements ad hoc pour réappliquer les règles persistantes. Beaucoup d’incidents tiennent à des chcon oubliés, appliqués dans l’urgence et écrasés lors d’une mise à jour. D’où une prise de position nette : pour tout ce qui doit tenir dans la durée, semanage fcontext + restorecon est la seule paire d’outils raisonnable.
La dernière brique, parfois vue comme magique, est audit2allow. L’outil génère des modules de politique à partir de journaux d’AVC, en créant des règles qui autorisent précisément ce qui a été refusé. Utilisé avec méthode, sur un périmètre bien compris, il permet de combler un manque réel dans une politique standard. Utilisé à l’aveugle, il produit des modules qui élargissent peu à peu les droits des domaines concernés, jusqu’à vider SELinux de sa substance. Sur une infrastructure qui doit respecter des exigences fortes de sécurité informatique, se contenter de charger systématiquement les modules générés par audit2allow revient à désactiver SELinux sans le dire.
Au fond, affiner la politique, c’est accepter un peu de friction au moment d’intégrer un nouveau composant, pour gagner de la prévisibilité ensuite. Chaque refus documenté et résolu proprement renforce la compréhension collective de l’architecture. Les serveurs deviennent moins « magiques », plus explicites, ce qui n’est pas un luxe dans des équipes où les rotations sont fréquentes.
Quand et comment désactiver SELinux sans mettre le feu à la production
Il reste un sujet que tout le monde aborde à un moment ou à un autre : la désactivation SELinux. Les forums regorgent de conseils simplistes du type « mettez SELINUX=disabled dans /etc/selinux/config et redémarrez ». Sur un environnement de test isolé, cela peut se défendre. Sur un serveur exposé ou une plateforme de production, c’est une décision lourde, qui doit être factuelle et temporaire.
Le premier cas justifiable concerne les migrations complexes, où l’on doit à la fois changer de distribution, de version de base de données et de schéma applicatif. Certaines équipes préfèrent concentrer les risques et désactiver SELinux le temps de stabiliser la pile, puis réactiver progressivement en traçant soigneusement les étapes. Cette approche suppose deux conditions rarement réunies : une documentation claire de l’état antérieur et une date cible pour le retour à un mode actif. Sans cela, disabled devient l’état permanent par inertie.
Le deuxième cas touche des applications propriétaires anciennes, sans support SELinux officiel, où la pile logicielle ne tolère tout simplement pas la présence d’un module MAC. Cela se rencontre encore sur des outils métiers livrés clé en main, parfois installés depuis des années sur des distributions figées. Là encore, désactiver SELinux sur un serveur dédié à cette application peut se concevoir, mais en gardant à l’esprit que ce serveur concentrera une partie du risque global. Un responsable sécurité sérieux demandera alors des compensations : segmentation réseau, durcissement supplémentaire des comptes, supervision plus agressive des journaux système.
Le troisième cas, malheureusement fréquent, est la réaction à chaud face à un incident. Un service critique tombe, l’équipe ne parvient pas à interpréter les journaux d’audit SELinux dans le feu de l’action, quelqu’un décide de passer en disabled « pour voir ». Le service repart, plus personne n’ose toucher à la configuration ensuite, et le serveur reste dans cet état pendant des années. Là, le problème n’est plus technique, il est organisationnel : absence de procédure de retour à la normale et de culture SELinux dans l’équipe.
Une alternative raisonnable consiste à combiner deux leviers. D’un côté, basculer en mode permissif global sur une fenêtre très courte, le temps de collecter des journaux exhaustifs dans /var/log/audit/audit.log. De l’autre, utiliser rapidement sealert et ausearch pour identifier les contextes problématiques et corriger via les outils classiques (fcontext, port, booléens). Une fois la situation stabilisée, repasser en mode enforcing et, si nécessaire, définir un domaine précis en permissif pour finir le diagnostic sans exposer le reste du système.
Au passage, l’expérience montre que les distributions centrées SELinux comme Rocky Linux gagnent à être installées avec leur configuration par défaut plutôt que dans des variantes « custom » qui bricolent les politiques. La documentation spécifique aux environnements stables, comme celle consacrée à Rocky Linux en contexte serveur, s’appuie justement sur ces profils validés par l’éditeur. Mieux vaut aligner son infrastructure sur ces bases connues que tenter de maintenir une variante isolée sur le long terme.
En définitive, la vraie question n’est pas « faut-il désactiver SELinux ? », mais « qu’est-ce que l’on perd et comment le compense-t-on si on le fait ? ». Une organisation qui ne sait pas répondre clairement à cette question a sans doute intérêt à revoir sa stratégie de durcissement plutôt que de s’en remettre à un simple paramètre dans /etc/selinux/config.
Comment savoir rapidement si SELinux bloque un service sur un serveur Linux ?
La première étape consiste à vérifier le mode avec getenforce, puis à consulter les journaux d’audit SELinux. Les refus se trouvent dans /var/log/audit/audit.log. La commande ausearch -m AVC -ts recent permet de filtrer les derniers événements. Pour une analyse plus lisible, sealert -a /var/log/audit/audit.log propose un résumé des refus et des pistes de correction. Tant que les refus concernent des types ou des ports évidents, la correction passe par restorecon, semanage fcontext ou semanage port plutôt que par une désactivation globale de SELinux.
Quel mode SELinux privilégier pour un serveur de production exposé à Internet ?
Pour un serveur applicatif exposé, le mode enforcing doit rester la référence. Il applique la politique de sécurité SELinux et limite l’impact d’une compromission, y compris en cas de faille zero-day. Le mode permissif sert surtout à diagnostiquer les applications avant leur mise en production, éventuellement en préproduction. Quant au mode disabled, il ne devrait être utilisé que de manière exceptionnelle et temporaire, par exemple lors d’une migration délicate ou d’un retour arrière d’urgence, avec un plan clair pour revenir ensuite en enforcing.
Quelle est la bonne pratique pour gérer les contextes de sécurité des fichiers applicatifs ?
Pour gérer durablement les contextes de sécurité, la méthode recommandée repose sur semanage fcontext et restorecon. On déclare d’abord les règles d’étiquetage persistantes pour les répertoires applicatifs avec semanage fcontext -a -t TYPE « CHEMIN(/.*)? », puis on applique ces règles avec restorecon -Rv CHEMIN. Cette approche résiste aux restaurations de sauvegarde, aux mises à jour et aux réétiquetages globaux. À l’inverse, chcon ne doit servir que pour des tests temporaires, car ses changements peuvent être perdus lors d’un restorecon ultérieur.
Faut-il générer systématiquement des modules avec audit2allow pour corriger les refus SELinux ?
Non. audit2allow doit rester un outil de dernier recours, réservé à des cas bien compris où la politique standard ne couvre pas un comportement légitime et documenté de l’application. Avant de générer un module, il faut vérifier que les étiquettes des fichiers sont correctes, que les ports utilisés ont le bon type et que les booléens pertinents sont en place. Générer des modules à la chaîne à partir de journaux bruts élargit progressivement les droits des domaines supervisés et réduit la valeur de la politique de sécurité SELinux.
SELinux a-t-il un impact sensible sur les performances des applications ?
Sur les charges de travail courantes (web, bases de données, services de messagerie), l’impact de SELinux reste en général faible, car les décisions de contrôle d’accès sont mises en cache par le noyau. Pour des scénarios très intensifs en I/O ou en appels système, des mesures ciblées peuvent naturellement s’imposer, mais dans la plupart des retours d’expérience, le surcoût observé se situe dans une fourchette tolérable pour un serveur moderne. En contrepartie, le gain de sécurité et de confinement lors d’un incident justifie largement cette légère surcharge.