Qu’est-ce que SELinux et comment peut-il améliorer la sécurité sur les serveurs Linux ?

Lorsque la plupart des administrateurs système pensent au durcissement d’un serveur Linux, ils se concentrent sur les principes fondamentaux : maintenir les paquets à jour, configurer les règles de pare-feu et restreindre l’accès SSH. Ce sont toutes des étapes valides et nécessaires — mais elles laissent un écart important. L’un des mécanismes de sécurité les plus puissants et les plus sous-utilisés disponibles sur Linux est SELinux (Security-Enhanced Linux), un cadre de contrôle d’accès obligatoire au niveau du noyau conçu pour contenir les menaces avant qu’elles ne se transforment en compromis système complets.

Que vous exécutiez un environnement VPS Hosting, une application à fort trafic sur des Serveurs Dédiés, ou une plateforme Hébergement Web Partagé multi-locataire, SELinux peut être la couche décisive qui transforme une violation grave en incident contenu et récupérable.

Qu’est-ce que SELinux ?

SELinux est un module de sécurité du noyau Linux qui implémente le Contrôle d’Accès Obligatoire (MAC). Pour comprendre pourquoi cela importe, vous devez d’abord comprendre ce qu’il remplace — ou plutôt, ce qu’il augmente.

Le modèle de sécurité Linux traditionnel est basé sur le Contrôle d’Accès Discrétionnaire (DAC). Sous DAC, les permissions d’accès sont déterminées par la propriété des fichiers et l’appartenance au groupe. L’utilisateur root détient un pouvoir illimité sur l’ensemble du système. Si un attaquant obtient root, il obtient tout.

Sous le modèle MAC de SELinux, l’accès est régi par des politiques de sécurité à l’échelle du système qui sont appliquées au niveau du noyau. De manière critique, même l’utilisateur root est soumis à ces restrictions. Un processus s’exécutant en tant que root ne peut pas effectuer d’actions que sa politique SELinux ne permet pas explicitement.

SELinux a été développé à l’origine par la National Security Agency (NSA) en collaboration avec Red Hat et a été intégré au noyau Linux principal au début des années 2000. Aujourd’hui, c’est un composant standard des distributions Linux de classe entreprise, notamment RHEL, CentOS, Fedora, AlmaLinux et Rocky Linux.

Où la sécurité Linux traditionnelle est insuffisante

Le modèle de permissions UNIX classique a bien servi Linux pendant des décennies, mais il porte des faiblesses structurelles que les attaquants modernes exploitent régulièrement :

• Root est tout-puissant. Tout exploit qui escalade avec succès vers root donne à l’attaquant un accès illimité à l’ensemble du système — fichiers, bases de données, sockets réseau, et tout.
• Le compromis de service équivaut au compromis du système. Un module Apache vulnérable, un script PHP mal codé ou une application mal configurée peuvent être utilisés pour pivoter sur l’ensemble du serveur.
• Les vecteurs d’attaque modernes contournent complètement DAC. Les web shells, les exploits d’escalade de privilèges, les échappements de conteneurs et les attaques de la chaîne d’approvisionnement sont conçus pour fonctionner dans les limites des permissions traditionnelles tout en causant des dommages catastrophiques.

Scénario d’attaque réel

Considérez une vulnérabilité CMS courante qui permet à un attaquant de télécharger et d’exécuter un web shell.

Sans SELinux : L’attaquant lit config.php, extrait les identifiants de base de données, vide la base de données, se déplace latéralement vers d’autres sites hébergés et peut potentiellement obtenir un accès root complet. L’ensemble de la pile est compromis à partir d’un seul point d’entrée.

Avec SELinux : Le processus du serveur web Apache s’exécute dans le domaine httpd_t. La politique limite strictement ce que httpd_t peut accéder. Le web shell ne peut pas lire les fichiers en dehors du domaine de contenu désigné, ne peut pas ouvrir de connexions réseau non autorisées et ne peut pas toucher aux fichiers de configuration du système. La violation est contenue au niveau de la couche application.

C’est la proposition de valeur fondamentale de SELinux : la limitation des dommages par le confinement des processus.

Comment fonctionne SELinux : contextes de sécurité et application des politiques

SELinux fonctionne en attribuant un contexte de sécurité (label) à chaque processus, fichier, port et socket réseau du système. Les politiques définissent ensuite quels contextes sont autorisés à interagir les uns avec les autres. Le noyau applique ces règles à chaque tentative d’accès.

Un exemple concret

La politique SELinux permet à httpd_t de lire les fichiers étiquetés httpd_sys_content_t. Elle ne permet pas à httpd_t de lire shadow_t.

Si Apache — que ce soit légitimement ou en raison d’une exploitation — tente de lire /etc/shadow, le noyau refuse la demande et écrit une entrée de violation détaillée dans /var/log/audit/audit.log. L’attaque est bloquée et documentée simultanément.

Modes de fonctionnement de SELinux

SELinux fonctionne en trois modes distincts :

Vérification et définition du mode actuel

# Check current SELinux status
getenforce
sestatus

# Temporarily switch to permissive mode (no reboot required)
setenforce 0

# Switch back to enforcing mode
setenforce 1

Pour modifier le mode de manière permanente, modifiez /etc/selinux/config et définissez SELINUX=enforcing (ou permissive), puis redémarrez.

> Meilleure pratique : Déployez les nouveaux serveurs en mode Permissive d’abord. Examinez les journaux d’audit, identifiez tous les processus légitimes qui sont signalés, affinez vos politiques, puis passez à Enforcing pour la production. Cette approche prévient les interruptions opérationnelles tout en garantissant que vos politiques sont exactes.

Types de politiques SELinux

SELinux est livré avec plusieurs types de politiques adaptés à différents environnements :

Politique ciblée (par défaut et recommandée)

Applique les restrictions MAC uniquement aux services orientés réseau tels qu’Apache, Nginx, Postfix, Dovecot et DNS. Tous les autres processus s’exécutent dans un domaine non confiné. C’est le meilleur équilibre entre sécurité et convivialité pour la grande majorité des charges de travail VPS et serveurs dédiés.

Politique stricte

Applique MAC à tous les processus du système, y compris les sessions utilisateur. Fournit une sécurité maximale mais nécessite une gestion des politiques et une expertise opérationnelle beaucoup plus importantes.

MLS/MCS (Multi-Level Security / Multi-Category Security)

Types de politiques avancés conçus pour les environnements de classe gouvernementale, classifiés ou hautement réglementés où les données doivent être isolées sur plusieurs niveaux de sensibilité simultanément.

Pour la plupart des déploiements de serveurs de production, la Politique ciblée est le bon choix.

Pourquoi SELinux importe pour l’hébergement, DevOps et la conformité

SELinux offre des avantages de sécurité tangibles dans un large éventail de contextes opérationnels :

Isolation des processus

Chaque service confiné fonctionne dans son propre domaine de sécurité. Compromettre un service — par exemple, une application Web — ne donne pas accès à d’autres services s’exécutant sur le même hôte. Ceci est particulièrement précieux dans les environnements de serveurs multi-applications.

Application du principe du moindre privilège

SELinux applique le principe du moindre privilège au niveau du noyau. Les processus ne peuvent accéder que aux ressources dont ils ont explicitement besoin. Même si un attaquant obtient root dans un processus confiné, il ne peut pas dépasser les permissions définies par la politique.

Pistes d’audit et forensique

Chaque tentative d’accès refusée est enregistrée dans /var/log/audit/audit.log avec le contexte complet : le processus impliqué, la ressource qu’il a tenté d’accéder, les contextes de sécurité des deux, et un horodatage. Cela rend la forensique post-incident considérablement plus efficace.

Sécurité des conteneurs

SELinux empêche les conteneurs Docker et Podman de s’échapper de leurs limites et d’accéder aux ressources de l’hôte. C’est une couche de défense critique pour les charges de travail conteneurisées où les vulnérabilités d’échappement de conteneurs sont une classe d’attaque connue.

Conformité réglementaire

SELinux est un contrôle obligatoire dans plusieurs cadres de conformité, notamment PCI DSS, HIPAA et les normes de sécurité militaires/gouvernementales. L’exécution de SELinux en mode Enforcing avec une politique documentée est souvent une condition préalable pour réussir les audits de sécurité dans les industries réglementées.

Commandes SELinux essentielles pour les administrateurs système

Voici les commandes les plus couramment utilisées pour gérer SELinux dans les opérations quotidiennes :

Vérifier l’état de SELinux

getenforce
sestatus

Restaurer les contextes de fichiers après déplacement de fichiers Web

Lorsque les fichiers sont déplacés plutôt que copiés, ils peuvent conserver des labels de sécurité incorrects. Utilisez restorecon pour corriger cela :

restorecon -Rv /var/www/html

Lister les labels de sécurité des fichiers

ls -Z /var/www/html

Autoriser les connexions sortantes du service Web (par exemple, pour les appels API ou le proxying)

setsebool -P httpd_can_network_connect 1

Autoriser Apache à se connecter à une base de données

setsebool -P httpd_can_network_connect_db 1

Examiner les actions refusées récentes dans le journal d’audit

ausearch -m avc -ts recent

Générer un module de politique personnalisé à partir des refus d’audit

audit2allow -a -M my_custom_policy
semodule -i my_custom_policy.pp

> Important : Enquêtez toujours sur les refus d’audit avant de créer des règles d’autorisation. audit2allow est un outil puissant, mais permettre aveuglément tous les refus va à l’encontre de l’objectif de SELinux. Comprenez ce que chaque règle permet avant de l’appliquer.

Pièges courants de SELinux et comment les éviter

Désactiver SELinux au lieu de le corriger. L’erreur la plus courante que font les administrateurs est de désactiver définitivement SELinux lorsqu’ils rencontrent un refus. Cela supprime une couche entière de protection. À la place, utilisez audit2allow et setsebool pour résoudre des problèmes spécifiques tout en gardant SELinux actif.

Labels de fichiers incorrects après les déploiements manuels. Si vous déployez des fichiers d’application en les copiant à partir d’un emplacement non standard, ils peuvent hériter de labels incorrects. Exécutez toujours restorecon après les opérations de fichiers manuels dans les racines Web et les répertoires d’application.

Ne pas examiner les journaux en mode Permissive. Ignorer la phase Permissive et passer directement à Enforcing sur un serveur de production est une recette pour des pannes inattendues. Validez toujours les politiques par rapport au trafic réel avant de les appliquer.

SELinux et AlexHost : sécurité prête pour la production dès le départ

Les serveurs AlexHost exécutant des distributions Linux d’entreprise (AlmaLinux, Rocky Linux, CentOS) sont livrés avec SELinux disponible d’emblée. Que vous déployiez une pile d’application Web, un serveur de base de données ou un environnement de microservices conteneurisés, SELinux fournit la couche de contrôle d’accès fondamentale qui maintient vos charges de travail résilientes contre l’exploitation.

Si vous gérez votre serveur via un panneau de contrôle, les environnements VPS avec cPanel sont entièrement compatibles avec SELinux en mode Targeted, et cPanel lui-même est livré avec des configurations conscientes de SELinux pour ses services gérés.

Pour les équipes qui ont besoin d’un contrôle complet sur leur posture de sécurité — y compris les modules de politique SELinux personnalisés, les configurations MLS ou le durcissement axé sur la conformité — les Serveurs Dédiés fournissent l’isolation et l’accès root nécessaires pour implémenter et maintenir des politiques MAC de classe entreprise sans les contraintes de l’infrastructure partagée.

Conclusion

SELinux n’est pas simplement un compl