AppArmor ou SELinux : quel système MAC choisir sous Linux ?

Quand vous durcissez une machine Linux, vous finissez tôt ou tard devant un choix : AppArmor ou SELinux. Les deux sont des systèmes de contrôle d’accès obligatoire (MAC) intégrés au noyau Linux via le même cadre LSM (Linux Security Modules). Tous deux confinent un processus compromis pour qu’une faille ne puisse pas atteindre librement le reste de votre système. Mais leurs approches diffèrent profondément, et le bon choix dépend moins de « lequel est le plus puissant » que de ce que vous exécutez, de votre distribution et du temps que vous êtes prêt à consacrer à la politique de sécurité.

Ce guide les compare par conception, par coût de maintenance au quotidien et par modèle de menace — pour que vous décidiez au lieu de deviner.

Ce que fait réellement le contrôle d’accès obligatoire

Les permissions Linux classiques sont discrétionnaires : le propriétaire d’un fichier décide qui peut le lire ou l’écrire, et un processus s’exécute avec toutes les permissions de l’utilisateur qui l’a lancé. Si ce processus est compromis, l’attaquant hérite de ces permissions — vos fichiers, votre réseau, votre dossier personnel.

Le contrôle d’accès obligatoire ajoute une seconde couche que l’utilisateur ne peut pas contourner. Une politique centrale, appliquée par le noyau, décide de ce que chaque processus a le droit de faire, indépendamment du propriétaire du fichier. Un serveur web confiné par MAC peut se voir interdire tout sauf la lecture de sa racine documentaire et l’écoute sur le port 443 — et même si un attaquant le compromet, le noyau refuse tout ce qui sort de cette enveloppe.

AppArmor et SELinux assurent tous deux cette fonction. La différence réside dans la manière dont ils identifient ce qu’un processus a le droit de toucher.

La différence de conception fondamentale : chemins ou étiquettes

Cette seule distinction explique presque tous les compromis pratiques entre les deux.

AppArmor repose sur les chemins. Un profil nomme les chemins de fichiers réels auxquels un programme peut accéder. Une règle comme /etc/nginx/** r signifie « nginx peut lire tout ce qui se trouve sous /etc/nginx ». Cela correspond directement à la façon dont les administrateurs raisonnent déjà, ce qui rend les profils lisibles et rapides à écrire.

SELinux repose sur les étiquettes. Chaque fichier, processus, socket et port porte un contexte de sécurité (une étiquette) tel que httpd_sys_content_t. Les règles décrivent quelles étiquettes peuvent interagir entre elles — et non quels chemins. Le chemin /var/www/html/index.html est indifférent à SELinux ; ce qui compte, c’est l’étiquette qui lui est attachée.

La conséquence : si vous déplacez un fichier sous AppArmor, la règle s’applique toujours tant que le nouveau chemin est couvert. Sous SELinux, un fichier déplacé peut conserver ou perdre son étiquette selon la méthode employée (cp et mv ne se comportent pas pareil), ce qui est la source de confusion la plus fréquente du type « ça marchait jusqu’à ce que je copie le fichier ». En contrepartie, une politique par étiquettes est plus difficile à tromper : un attaquant ne peut pas contourner une règle en atteignant les mêmes données par un lien symbolique ou un chemin alternatif, car l’étiquette voyage avec l’objet.

Granularité et niveau d’assurance

SELinux est le plus fin des deux. Comme chaque objet est étiqueté, la politique peut exprimer des contrôles hors de portée d’AppArmor — sécurité multi-niveaux, application de types sur des centaines de domaines, et contraintes qui séparent, par exemple, deux applications web vivant toutes deux sous /var/www mais qui ne devraient jamais lire les données l’une de l’autre. C’est pourquoi SELinux est le défaut dans les environnements à exigences de sécurité formelles (RHEL, Fedora, déploiements d’origine gouvernementale) et pourquoi il a été développé à l’origine avec la National Security Agency américaine.

AppArmor est délibérément plus grossier. Il ne peut pas tout exprimer comme SELinux, mais pour l’objectif courant — confiner quelques services exposés au réseau et des navigateurs afin qu’une seule faille ne puisse pas rebondir — ce plafond importe rarement. La plupart des modèles de menace de poste de travail et de petit serveur sont pleinement couverts par l’expressivité d’AppArmor.

Une bonne façon de le formuler : SELinux offre un plafond plus haut ; AppArmor offre un plancher d’effort plus bas. Lequel l’emporte dépend entièrement de savoir si vous avez réellement besoin de ce plafond.

Le coût de maintenance dans la vraie vie

C’est là que le choix se décide généralement.

Avec AppArmor, les profils sont de courts fichiers texte que vous pouvez lire et modifier à la main. Les distributions qui l’adoptent par défaut (Ubuntu, Debian, openSUSE) fournissent des profils prêts à l’emploi, et vous pouvez en générer de nouveaux de façon interactive :

# Voir les profils chargés et leur mode
sudo aa-status

# Générer un profil pour une application en l'observant tourner
sudo aa-genprof /usr/bin/myapp

# Passer un profil en mode application
sudo aa-enforce /etc/apparmor.d/usr.bin.firefox

Un mode « complain » journalise les violations sans les bloquer, ce qui permet de développer un profil sur un système en production puis de le resserrer une fois que vous connaissez les besoins légitimes de l’application.

Avec SELinux, la politique est vaste et vous ne l’écrivez presque jamais de zéro — vous ajustez des booléens et réétiquetez des fichiers. Le point de friction, c’est le diagnostic des refus. Le mauvais réflexe est de lancer setenforce 0 pour le désactiver ; le bon est de lire le journal d’audit :

# Vérifier le mode actuel
getenforce

# Examiner les refus récents et obtenir une politique suggérée
sudo ausearch -m avc -ts recent | audit2allow -a

# Restaurer les bonnes étiquettes sur un chemin
sudo restorecon -Rv /var/www/html

audit2allow propose un module de politique qui autoriserait l’action refusée ; vous le relisez avant de l’appliquer pour comprendre pourquoi le refus s’est produit, plutôt que d’autoriser en bloc. Ce flux est puissant mais comporte une vraie courbe d’apprentissage, et c’est la principale raison pour laquelle les administrateurs désactivent SELinux au lieu de l’apprendre — ce qui supprime entièrement la protection.

Suivez le défaut de votre distribution

En pratique, la recommandation la plus solide est aussi la plus simple : utilisez le système MAC que votre distribution fournit et maintient.

Aller contre le défaut, c’est exécuter une configuration non supportée : les profils AppArmor pour les paquets de Fedora ne sont pas maintenus, et la politique SELinux pour l’agencement des paquets d’Ubuntu est incomplète. Vous héritez d’une charge de maintenance que la distribution ne vous aidera pas à porter. Sur une machine Fedora ou RHEL, laissez SELinux en mode Enforcing et apprenez audit2allow. Sur Ubuntu ou Debian, gardez AppArmor activé et assurez-vous que votre navigateur et vos services réseau tournent avec des profils en mode application.

C’est le même principe que celui qui guide le choix d’une distribution Linux sécurisée : la protection réellement maintenue vaut mieux que la protection théoriquement plus forte mais non supportée sur votre système.

La place du MAC dans une défense en couches

Ni AppArmor ni SELinux n’est une stratégie de sécurité complète. Le MAC confine des processus déjà en cours d’exécution ; il ne fait rien contre du code non fiable que vous choisissez d’exécuter, ni contre l’isolation de charges de travail entières les unes des autres. Pour isoler les applications du poste de travail, les outils de bac à sable comme Firejail et bubblewrap travaillent aux côtés du MAC plutôt que de le remplacer. Pour le durcissement système plus large — paramètres noyau, sysctl, démarrage vérifié — le MAC n’est qu’une couche du tableau d’ensemble du durcissement Linux, et il s’inscrit dans la comparaison plus vaste des modèles de sécurité Linux face à Windows.

À retenir : la question AppArmor-ou-SELinux est réelle mais étroite. Choisissez celui que votre distribution maintient, laissez-le en mode application, et consacrez le reste de vos efforts aux couches au-dessus et en dessous.

Questions fréquentes

SELinux est-il plus sûr qu’AppArmor ? SELinux peut exprimer une politique plus stricte et plus fine, donc en valeur absolue son plafond est plus haut. Mais la sécurité vient d’une politique réellement appliquée et maintenue. Un système AppArmor laissé en mode application vous protège davantage qu’un système SELinux que quelqu’un a désactivé parce que les refus étaient déroutants.

Puis-je utiliser les deux en même temps ? Non. AppArmor et SELinux sont tous deux des LSM « majeurs » et le noyau n’en charge qu’un comme système MAC principal. Vous en choisissez un par machine — en pratique, celui que votre distribution adopte par défaut.

Faut-il les désactiver un jour ? Presque jamais. Désactiver le MAC retire une couche qui limite l’étendue des dégâts d’un service compromis. En cas de refus, diagnostiquez-le (audit2allow pour SELinux, mode complain pour AppArmor) au lieu de tout couper.

Lequel est le plus simple pour un débutant ? AppArmor. Ses profils par chemins se lisent comme le système de fichiers que vous comprenez déjà, et Ubuntu et Debian fournissent des profils fonctionnels d’origine. SELinux récompense le temps investi à l’apprendre, mais ce temps est bien réel.