Maîtrisez SELinux facilement
Mise à jour :
La sécurité sous Linux ne se limite pas aux simples permissions classiques des fichiers et des utilisateurs. Pour aller plus loin, SELinux (Security-Enhanced Linux) ajoute une couche de contrôle d’accès obligatoire (MAC) qui s’applique à chaque action sur le système. Grâce à des politiques précises, même un processus compromis reste confiné dans un périmètre défini. Comprendre et utiliser SELinux permet donc de renforcer considérablement la sécurité, sans sacrifier la souplesse ni la performance.
Comprendre SELinux: principes de base
SELinux (Security-Enhanced Linux) est une extension de sécurité intégrée au noyau Linux, développée initialement par la NSA. Son objectif principal ? Ajouter une couche de sécurité supplémentaire aux traditionnels droits d’accès Unix, basés sur les permissions DAC (Discretionary Access Control).
Avec SELinux, on passe à un modèle plus strict : le MAC (Mandatory Access Control). Mais qu’est-ce que cela signifie concrètement ?
DAC vs. MAC
Dans le modèle DAC, un fichier appartient à un utilisateur et à un groupe, et ses droits sont définis par les classiques permissions rw-r—r—. Les processus qui tournent héritent des droits de l’utilisateur qui les lance. Résultat: si un service (par exemple Apache) est compromis, l’attaquant peut exploiter tout ce que l’utilisateur associé peut toucher.
Avec le MAC, c’est très différent: même si l’utilisateur a des droits, les politiques SELinux peuvent bloquer des actions en fonction de contextes précis. Chaque processus et chaque fichier est étiqueté avec un contexte de sécurité. Ces étiquettes sont ensuite croisées avec des règles strictes définies dans les politiques.
Pourquoi SELinux a-t-il été créé ?
L’idée derrière SELinux est simple: les administrateurs ont besoin de maîtriser finement ce qu’un processus peut ou ne peut pas faire, même si celui-ci s’exécute sous un utilisateur privilégié. Cela permet de limiter drastiquement l’impact d’une compromission.
Voici quelques exemples d’application:
- Un serveur web peut lire ses fichiers HTML, mais il ne pourra pas accéder à des fichiers systèmes, même si les permissions Unix semblent le permettre.
- Un serveur de base de données pourra écrire dans ses répertoires, mais jamais exécuter un binaire du système.
Points clés à retenir
- SELinux est activé au niveau du noyau, il agit comme un garde du corps qui intercepte toutes les actions sensibles.
- Il est conçu pour être modulaire: les règles peuvent s’adapter aux besoins spécifiques des services et des applications.
- La complexité est le revers de la médaille: mal configuré, SELinux peut bloquer des services légitimes, d’où l’importance de comprendre son fonctionnement avant de l’activer pleinement.
Les modes de fonctionnement de SELinux
SELinux peut fonctionner selon trois modes distincts, chacun offrant un niveau de contrôle et de rigueur différent. Comprendre ces modes est essentiel pour bien démarrer et éviter des blocages inattendus.
Enforcing (mode strict)
En mode enforcing, SELinux applique toutes les règles définies par ses politiques. Chaque action réalisée par un processus est vérifiée: si elle viole une règle, elle est bloquée et l’incident est consigné dans les logs.
Commandes utiles:
sudo getenforce
Cette commande affiche le mode actuel:
Enforcing
Pour passer en mode enforcing temporairement (jusqu’au prochain redémarrage).
sudo setenforce 1
Permissive (mode permissif)
Le mode permissive est un mode d’observation. SELinux continue à vérifier les règles et à enregistrer les violations, mais ne bloque rien. C’est idéal pour tester une configuration, identifier les problèmes potentiels et ajuster les politiques sans risquer d’interrompre les services.
Commandes utiles:
sudo setenforce 0
Pour passer temporairement en mode permissif:
sudo getenforcePermissive
Disabled (désactivé)
Enfin, en mode disabled, SELinux est complètement désactivé. Le système ignore toutes les règles, il n’y a ni vérification ni journalisation. Attention: ce mode est fortement déconseillé en production.
Pour changer le mode de façon permanente, il faut éditer le fichier:
/etc/selinux/config
Exemple de configuration:
SELINUX = enforcingSELINUXTYPE = targeted
Résumé des modes
Mode | Action |
---|---|
Enforcing | Applique et fait respecter les politiques |
Permissive | N’applique pas mais journalise les violations |
Disabled | Ignore totalement SELinux |
Bonnes pratiques
Pour commencer à utiliser SELinux sans risque:
- Activez-le en permissive pour observer le comportement.
- Analysez les logs et résolvez les problèmes détectés.
- Passez en enforcing une fois que tout est prêt.
Les contextes SELinux: comprendre les étiquettes de sécurité
Dans SELinux, chaque fichier, répertoire, processus, port réseau est associé à un contexte de sécurité. Ces contextes permettent au système de savoir qui peut faire quoi, au-delà des permissions classiques Unix.
Qu’est-ce qu’un contexte SELinux ?
Un contexte est une étiquette structurée ainsi:
utilisateur: rôle: type: niveau
Exemple pour un fichier:
unconfined_u: object_r: httpd_sys_content_t: s0
- unconfined_u : l’utilisateur SELinux (pas forcément lié à l’utilisateur Unix).
- object_r : le rôle, souvent
object_r
pour les fichiers. - httpd_sys_content_t: le type, la partie la plus importante, qui définit les règles d’accès.
- s0: le niveau (utilisé pour les politiques MLS, moins fréquent).
Pourquoi ces étiquettes sont-elles importantes ?
SELinux décide d’autoriser ou non une action en fonction des types. Par
exemple, un processus avec le type httpd_t
(Apache) pourra accéder aux
fichiers marqués httpd_sys_content_t
, mais pas à un fichier marqué
user_home_t
.
Même si les permissions Unix (rwx
) sont correctes, une étiquette incorrecte
bloquera l’accès.
Afficher les contextes
Pour voir les contextes associés à des fichiers:
ls -Z /var/www/html
-rw-r--r--. root root unconfined_u: object_r: httpd_sys_content_t: s0 index.html
Pour voir le contexte d’un processus:
ps -eZ | grep httpd
Modifier les étiquettes
Pour changer temporairement un type (non persistant):
chcon -t httpd_sys_content_t mon_fichier
Pour restaurer les étiquettes officielles (selon les politiques):
restorecon -v /var/www/html/mon_fichier
Exemple concret
Imaginons que vous placez une page web dans /opt/mon_site
. Par défaut, ce
répertoire aura un type incompatible (default_t
), et Apache ne pourra pas y
accéder, même avec les bonnes permissions Unix. Il faudra:
semanage fcontext -a -t httpd_sys_content_t "/opt/mon_site(/.*)?"restorecon -R /opt/mon_site
Gérer les politiques SELinux
Pour que SELinux fonctionne, il s’appuie sur un ensemble structuré de politiques. Ces politiques définissent les règles précises que chaque type de processus peut appliquer sur chaque type de fichier, de port ou de ressource. Bien comprendre leur gestion est essentiel pour adapter SELinux à vos besoins.
Types de politiques
Il existe deux grands types de politiques:
- targeted (ciblée) : seules certaines applications critiques (comme Apache, PostgreSQL, SSH) sont confinées.
- MLS (Multi-Level Security): utilisée dans des environnements à très haute sécurité, elle introduit des niveaux et catégories plus complexes.
Par défaut, sur la majorité des systèmes (Fedora, RHEL, Rocky Linux), c’est la politique targeted qui est active:
cat /etc/selinux/config
Vous y verrez:
SELINUXTYPE = targeted
Outils essentiels
Vérifier les politiques en place
Pour lister les ports, fichiers et paramètres connus de SELinux:
semanage port -lsemanage fcontext -lsemanage boolean -l
Modifier les étiquettes de fichiers
Pour définir (de façon persistante) le type attendu sur un chemin:
semanage fcontext -a -t httpd_sys_content_t "/opt/mon_site(/.*)?"restorecon -R /opt/mon_site
Modifier les ports associés
Si, par exemple, vous voulez qu’Apache écoute sur le port 8080:
semanage port -a -t http_port_t -p tcp 8080
Activer ou désactiver des options via les booléens SELinux
Les booléens permettent d’ajuster certaines règles à chaud. Exemple: permettre à Apache d’établir des connexions réseau sortantes :
setsebool -P httpd_can_network_connect on
Vous pouvez lister tous les booléens disponibles:
getsebool -a
Exemples pratiques
- Autoriser le partage Samba:
setsebool -P samba_export_all_ro on
- Vérifier si une règle spécifique est active:
getsebool samba_export_all_ro
Dépannage et résolution des problèmes courants
Même avec une bonne configuration, SELinux peut surprendre par ses blocages inattendus. Heureusement, il fournit des outils puissants pour diagnostiquer et résoudre ces problèmes. Voici comment les utiliser efficacement.
Identifier les erreurs
Les violations SELinux sont enregistrées dans les logs, principalement:
/var/log/audit/audit.log
Pour extraire les événements récents:
ausearch -m avc --success no
Vous pouvez aussi regarder rapidement avec:
dmesg | grep -i denied
Comprendre les messages
Un message SELinux typique ressemble à:
type = AVC msg = audit(1628765432.123:456): avc: denied { read } for pid = 1234 comm = "httpd" name = "index.html" dev = "sda1" ino = 5678 scontext = system_u:system_r:httpd_t:s0 tcontext = unconfined_u:object_r:user_home_t:s0 tclass = file
Il indique:
- le processus (
httpd_t
) qui a tenté l’action, - le fichier ciblé (
user_home_t
), - l’opération interdite (
read
).
Utiliser audit2why
Cet outil traduit les logs SELinux en explications compréhensibles:
cat /var/log/audit/audit.log | audit2why
Il vous indique pourquoi une action a été bloquée et souvent propose une solution, comme activer un booléen spécifique.
Générer des règles avec audit2allow
Si vous devez créer une exception personnalisée:
cat /var/log/audit/audit.log | audit2allow -M monmodulesemodule -i monmodule.pp
Attention: créez des modules uniquement si nécessaire, après avoir vérifié qu’il n’existe pas une solution plus simple (correction d’étiquettes, activation d’un booléen).
Bonnes pratiques de dépannage
- Vérifiez d’abord les logs avant de modifier quoi que ce soit.
- Utilisez
permissive
sur le domaine concerné pour tester sans désactiver SELinux globalement:
semanage permissive -a httpd_t
- Documentez vos changements pour pouvoir les maintenir facilement.
- Restaurez les contextes d’origine avant de penser à créer des exceptions:
restorecon -Rv /chemin/affecté
Atelier pratique: Déplacer le document root Nginx vers /data/html avec SELinux
Dans cet atelier, nous allons voir comment déplacer le document root de Nginx vers un répertoire personnalisé, par exemple /data/html, tout en restant compatible avec les restrictions SELinux.
Étape 1: Préparer l’environnement
Installez Nginx:
dnf install -y nginxsystemctl enable nginx --now
Vérifiez que le service fonctionne:
curl http: //localhost
Par défaut, Nginx sert les fichiers depuis:
/usr/share/nginx/html
Étape 2: Créer le nouveau répertoire
Nous voulons déplacer le document root vers, on commence par créer le répertoire:
mkdir -p /data/html
Créez-y une page de test:
echo "<h1>Test Nginx SELinux</h1>" > /data/html/index.html
Étape 3: Modifier la configuration Nginx
Éditez le fichier:
/etc/nginx/nginx.conf
Dans la section server
, changez:
root /usr/share/nginx/html;
par:
root /data/html;
Redémarrez Nginx:
systemctl restart nginx
Étape 4: Tester (sans SELinux)
Si SELinux est en mode permissif, vous devriez voir votre page avec cette commande:
curl http: //localhost<h1>Test Nginx SELinux</h1>
Mais en mode enforcing, vous obtiendrez probablement une erreur 403. Pourquoi ?
Étape 5: Vérifier les contextes SELinux
Affichez les étiquettes:
ls -Zd /usr/share/nginx/htmlsystem_u: object_r: httpd_sys_content_t: s0 /usr/share/nginx/html
ls -Zd /data/htmlunconfined_u: object_r: default_t: s0 /data/html
On voit que: :
/usr/share/nginx/html
→httpd_sys_content_t
/data/html
→default_t
Or, Nginx ne peut lire que les fichiers marqués httpd_sys_content_t
.
Étape 6: Corriger les étiquettes
Déclarez le nouveau chemin:
semanage fcontext -a -t httpd_sys_content_t "/data/html(/.*)?"
Appliquez les étiquettes:
restorecon -Rv /data/html
Étape 7: Autoriser les accès SELinux
Vérifiez que le booléen httpd_can_network_connect
est actif si votre site
utilise des connexions sortantes:
setsebool -P httpd_can_network_connect on
Étape 8: Redémarrer et tester
Relancez Nginx:
systemctl restart nginx
Testez à nouveau:
curl http: //localhost<h1>Test Nginx SELinux</h1>
Ca devrait fonctionner !
Vérifier les logs en cas de problème
Si vous rencontrez toujours des erreurs:
ausearch -m avc --success no | audit2why
Cela vous indiquera s’il faut faire un autre ajustement.
Lancez l’examen interactif
Pourquoi ce contrôle ?
Cet contrôle va vous permettre de valider vos connaissances sur le sujet abordé dans le guide. Il comporte des QCM, des questions vrai/faux et des réponses ouvertes à un mot.
🕒 Le chronomètre commence dès que vous cliquez sur Démarrer le test. Vous devrez terminer l’examen avant la fin du temps imparti.
🎯 Pour réussir, vous devez obtenir au moins 80% de bonnes réponses.
💡 Je ne fournis pas directement les réponses aux questions. Cependant, si certaines sont complexes, des pistes d’explication pourront être proposées dans le guide ou après l’examen.
Bonne chance ! 🚀
Conclusion
SELinux peut paraître intimidant au premier abord : ses contextes, ses politiques, ses commandes spécifiques et ses blocages mystérieux donnent l’impression d’un système complexe réservé aux experts. Mais ne vous découragez pas.
Avec de la pratique régulière, des tests sur un environnement de laboratoire, et un peu de patience, vous verrez que les mécanismes deviennent familiers. Petit à petit, vous saurez où chercher dans les logs, comment ajuster les contextes, activer un booléen, ou écrire un module personnalisé.
Certes, les débuts sont parfois frustrants, mais au bout de quelque temps, on s’en sort très bien. Et surtout : on prend conscience de la valeur ajoutée énorme qu’apporte SELinux en termes de sécurité.
Il existe aussi une alternative intéressante à connaître : AppArmor, utilisée principalement sur Ubuntu et SUSE. AppArmor est souvent plus simple à configurer, car il repose sur des profils attachés aux exécutables plutôt que sur des étiquettes de fichiers. Bien qu’il soit moins granulaire que SELinux, il peut convenir pour des déploiements plus légers ou des environnements où l’on recherche avant tout la simplicité.
Alors n’hésitez pas à expérimenter, à consulter la documentation, à suivre des tutoriels pratiques, et surtout à rester curieux : SELinux (ou AppArmor) deviendra vite un allié précieux dans la protection de vos systèmes Linux.