Maîtrisez SELinux facilement

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 getenforce
Permissive

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     = enforcing
SELINUXTYPE = 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

Glissez pour voir

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 -l
semanage fcontext -l
semanage 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 monmodule
semodule -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 nginx
systemctl 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/html
system_u: object_r: httpd_sys_content_t: s0 /usr/share/nginx/html

ls -Zd /data/html
unconfined_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.

Pour aller plus loin

Après avoir maîtrisé SELinux, complétez votre expertise avec ces guides :

• Audit de sécurité : Vérifiez vos configurations avec Lynis ou OpenSCAP.
• Référentiels : Appliquez les recommandations ANSSI-BP-028 ou les CIS Benchmarks.
• Services critiques : Consultez mes guides sur le durcissement SSH et la configuration PAM.
• Automatisation : Déployez vos configurations avec Ansible ou gérez-les avec Rudder.

Lancez l’examen interactif

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

10 questions

10 min.

80% requis

Informations

• Le chronomètre démarre au clic sur Démarrer
• Questions à choix multiples, vrai/faux et réponses courtes
• Vous pouvez naviguer entre les questions
• Les résultats détaillés sont affichés à la fin

Démarrer le quiz

Lance le quiz et démarre le chronomètre

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.

FAQ - Questions Fréquemment Posées

Qu'est-ce que SELinux ?

SELinux (Security-Enhanced Linux) est un module de sécurité intégré au noyau Linux qui implémente un contrôle d'accès obligatoire (MAC). Développé initialement par la NSA et Red Hat, il permet de définir des politiques de sécurité strictes pour contrôler les interactions entre les processus, les utilisateurs et les ressources du système.

Quels sont les modes de fonctionnement de SELinux ?

SELinux peut fonctionner dans trois modes : - Enforcing : applique strictement les politiques de sécurité, bloquant les accès non autorisés. - Permissive : n'applique pas les politiques mais enregistre les violations pour analyse. - Disabled : désactive complètement SELinux.

Quels sont les avantages de SELinux ?

SELinux offre une sécurité renforcée en contrôlant les interactions entre processus et ressources, réduisant ainsi les risques d'escalade de privilèges. Il permet une séparation stricte des services, limitant les dommages en cas de compromission.

Comment vérifier l'état de SELinux sur un système Linux ?

Utilisez la commande `sestatus` pour afficher l'état actuel de SELinux, ou `getenforce` pour connaître le mode actif (Enforcing, Permissive ou Disabled).

Comment modifier le mode de fonctionnement de SELinux ?

Pour changer temporairement le mode, utilisez `setenforce 0` (Permissive) ou `setenforce 1` (Enforcing). Pour un changement permanent, modifiez le fichier `/etc/selinux/config` en ajustant la ligne `SELINUX=`.

Qu'est-ce qu'un contexte SELinux ?

Un contexte SELinux est une étiquette de sécurité attribuée à chaque fichier, processus ou ressource, définissant les permissions d'accès selon les politiques en vigueur.

Comment afficher les contextes SELinux des fichiers ?

Utilisez la commande `ls -Z` pour afficher les contextes SELinux des fichiers et répertoires.

Comment changer le contexte SELinux d'un fichier ?

Utilisez la commande `chcon` pour modifier temporairement le contexte d'un fichier. Pour un changement permanent, utilisez `semanage fcontext` suivi de `restorecon`.

Qu'est-ce qu'un domaine SELinux ?

Un domaine SELinux est un ensemble de permissions attribuées à un processus, déterminant les actions qu'il peut effectuer sur le système.

Comment SELinux protège-t-il le système ?

SELinux applique des politiques de sécurité strictes qui limitent les interactions entre processus et ressources, empêchant ainsi des actions non autorisées même si un processus est compromis.

Qu'est-ce qu'une politique SELinux ?

Une politique SELinux est un ensemble de règles définissant les permissions d'accès entre les sujets (processus) et les objets (fichiers, ports, etc.) du système.

Comment SELinux interagit-il avec les permissions classiques de Linux ?

SELinux fonctionne en complément des permissions classiques (DAC). Une action doit être autorisée à la fois par les permissions classiques et par les politiques SELinux pour être exécutée.

Qu'est-ce qu'un Boolean SELinux ?

Un Boolean SELinux est une variable permettant d'activer ou de désactiver dynamiquement certaines fonctionnalités ou règles de la politique SELinux.

Comment lister les Booleans SELinux disponibles ?

Utilisez la commande `getsebool -a` pour afficher la liste de tous les Booleans SELinux et leur état actuel.

Comment modifier l'état d'un Boolean SELinux ?

Utilisez la commande `setsebool` pour changer l'état d'un Boolean. Par exemple, `setsebool httpd_enable_homedirs on` active l'accès aux répertoires personnels pour le serveur HTTP.

×

📖 Voir la documentation →