Aller au contenu
Sécurité medium

SELinux ou AppArmor : choisir son contrôle d'accès obligatoire

6 min de lecture

Les permissions Unix classiques (rwx) ne suffisent pas : si un service tourne en root et qu'il est compromis, l'attaquant hérite de tous ses droits. Le contrôle d'accès obligatoire (MAC, Mandatory Access Control) ajoute une couche que même root ne peut pas contourner : chaque processus est confiné à ce dont il a besoin, et rien de plus. Sous Linux, deux implémentations se partagent le terrain : SELinux et AppArmor. Cette page explique le MAC une fois pour toutes, les compare, et vous aide à choisir sans vous tromper. La règle courte : on prend celui de sa distribution.

  • Distinguer le contrôle d'accès discrétionnaire (DAC) de l'obligatoire (MAC)
  • Comprendre ce qu'est un LSM (Linux Security Module)
  • Choisir entre SELinux et AppArmor selon votre distribution et vos besoins
  • Connaître les forces et les limites honnêtes de chacun

Le modèle historique d'Unix est le DAC (Discretionary Access Control) : un fichier appartient à un utilisateur et à un groupe, et son propriétaire décide des droits (rw-r--r--). Le défaut est dans le nom : le contrôle est à la discrétion de l'utilisateur, et un processus hérite de tous les droits du compte qui le lance. Un Apache compromis tournant sous un compte peut toucher tout ce que ce compte peut toucher.

Le MAC renverse la logique : une politique système, que l'utilisateur ne peut pas modifier, définit ce que chaque processus a le droit de faire. Même avec des permissions Unix permissives, l'action est refusée si la politique ne l'autorise pas. Un service confiné qui se fait pirater reste enfermé dans son périmètre : il ne lira pas /etc/shadow, n'ouvrira pas un shell, n'écrira pas hors de ses répertoires. C'est une défense en profondeur qui limite l'impact d'une compromission.

Techniquement, SELinux et AppArmor sont tous deux des LSM (Linux Security Modules), des greffons du noyau qui interceptent les opérations sensibles. On en active un seul comme MAC principal : ils ne se remplacent pas l'un l'autre selon l'humeur, c'est la distribution qui en impose un par défaut.

Dans 90 % des cas, le bon choix est celui que votre distribution active par défaut. Ne nagez pas à contre-courant : l'écosystème (politiques, profils, doc, outils) est construit autour de ce choix.

Votre distributionMAC natifGuide
RHEL, AlmaLinux, Rocky, Fedora, CentOSSELinux (enforcing par défaut)Comprendre et utiliser SELinux
Debian, UbuntuAppArmor (chargé par défaut)Comprendre et utiliser AppArmor
openSUSE / SLEAppArmor (par défaut, SELinux possible)AppArmor

Les deux poursuivent le même but mais avec des philosophies opposées. SELinux étiquette, AppArmor suit les chemins.

CritèreSELinuxAppArmor
ApprochePar étiquette (label) sur l'inodePar chemin de fichier (pathname)
UnitéContextes type + politique globaleUn profil par application
GranularitéTrès fine (Type Enforcement, MLS)Plus grossière, mais lisible
Courbe d'apprentissageRaide (contextes, booléens, AVC)Douce (profils en texte clair)
RobustesseForte : l'étiquette suit l'inodeLimite : un lien dur, un bind mount ou un binaire renommé peut contourner une règle de chemin
Couverture noyauPlus de hooks LSMMoins de hooks
DistributionsRHEL, Fedora, Rocky, AlmaDebian, Ubuntu, openSUSE
OrigineNSA + Red HatImmunix, puis SUSE/Canonical

En résumé : SELinux est plus strict et plus complet, au prix d'une complexité réelle. AppArmor est plus simple à lire et à écrire, mais son modèle par chemin a des angles morts. Aucun n'est « meilleur » dans l'absolu, ils répondent à des priorités différentes.

  • Vous administrez du RHEL/Rocky/Alma : restez sur SELinux, ne le désactivez pas. C'est l'attente des référentiels (CIS, ANSSI R46) et de tout l'outillage Red Hat.
  • Vous administrez du Debian/Ubuntu : utilisez AppArmor, et confinez en priorité vos services exposés (web, proxy) avec des profils dédiés.
  • Exigence de sécurité maximale (données classifiées, multi-niveaux) : SELinux avec sa politique MLS est le seul à couvrir ces besoins.
  • Vous voulez confiner vite un service précis sans tout réapprendre : un profil AppArmor se lit et s'écrit en quelques minutes.
  • Ne faites pas tourner les deux comme MAC principal : choisissez selon la distribution. Le confinement par service au niveau systemd (sandboxing) vient en complément, pas en remplacement.
  • Le MAC ajoute une couche que root ne contourne pas : il confine chaque processus
  • SELinux et AppArmor sont deux LSM : on en active un seul comme MAC principal
  • SELinux = par étiquette, strict et granulaire (RHEL/Rocky/Alma) ; AppArmor = par chemin, simple mais contournable (Debian/Ubuntu)
  • La bonne décision par défaut : le MAC natif de votre distribution
  • Le MAC se complète par le sandboxing systemd, il ne s'y substitue pas

Ce site vous est utile ?

Sachez que moins de 1% des lecteurs soutiennent ce site.

Je maintiens +700 guides gratuits, sans pub ni tracking. Un soutien, même symbolique, m'aide à couvrir l'hébergement et à garder ces ressources gratuites. Merci pour votre appui.

Le formulaire ne s'affiche pas ? Ouvrir Ko-fi dans un onglet.

Abonnez-vous et suivez mon actualité DevSecOps sur LinkedIn