SELinux vs AppArmor : quel cadre MAC convient à votre serveur ?

SELinux et AppArmor appliquent tous deux le contrôle d'accès obligatoire (MAC) sous Linux, limitant les actions des processus même s'ils obtiennent les privilèges root. La différence réside dans la manière dont ils procèdent. SELinux attribue des étiquettes persistantes à chaque fichier et processus. AppArmor utilise quant à lui des règles de chemin d'accès aux fichiers. Ce choix de conception détermine tout le reste : la complexité, le niveau de sécurité et la distribution qui intègre par défaut tel ou tel outil.

Fonctionnement de SELinux

SELinux a été initialement développé par la NSA et est fourni par défaut sur RHEL, CentOS, Fedora et Rocky Linux. Il attribue à chaque objet du système, y compris les fichiers, les processus, les ports et les sockets, un contexte de sécurité au format user:role:type:level. Le type champ effectue l'essentiel du travail grâce à un mécanisme appelé « Type Enforcement » (TE).

Par exemple, le serveur web Apache s'exécute en tant que httpd_t. Les fichiers de contenu Web ont un type différent. Si aucune règle de politique n'autorise explicitement httpd_t d'accéder à ce type de contenu, la requête est refusée. Il s'agit d'un modèle de refus par défaut. Rien n'est autorisé à moins qu'une règle n'en dispose autrement.

SELinux prend également en charge la sécurité multiniveaux (MLS) et la sécurité multicatégories (MCS), qui classent les données par niveau de sensibilité et restreignent l'accès en conséquence. C'est le MCS qui confère à SELinux sa forte isolation des conteneurs, en les maintenant séparés les uns des autres et de l'hôte. Cela est important dans les environnements Kubernetes et OpenShift où les pods partagent un nœud.

Le revers de la médaille est la complexité. SELinux présente une courbe d'apprentissage abrupte. Le dépannage des refus d'accès implique de lire les journaux d'audit, de comprendre les contextes de sécurité et, parfois, de générer des modules de politique personnalisés avec audit2allow. Pour les équipes ne disposant pas de personnel dédié à la sécurité, cette charge de travail est bien réelle.

Fonctionnement d'AppArmor

AppArmor adopte une approche différente. Au lieu d'étiqueter les objets, il associe des profils de sécurité aux applications en fonction de leurs chemins d'accès. Un profil pour /usr/sbin/nginx définit les répertoires que Nginx peut lire, les ports auxquels il peut se lier et les capacités dont il a besoin. Les profils sont des fichiers en texte brut stockés dans /etc/apparmor.d/.

AppArmor est le framework MAC par défaut sur Ubuntu, Debian et SUSE. Il fait partie du noyau Linux depuis la version 2.6.36. Les applications sans profil se rabattent sur les permissions DAC Linux standard.

AppArmor fonctionne selon deux modes par profil : Enforce (bloque et consigne les violations) et Complain (consigne les violations sans les bloquer). Cela permet de déployer progressivement de nouveaux profils. Commencez en mode Complain, examinez les journaux, renforcez le profil, puis passez en mode Enforce.

Des outils tels que aa-genprof et aa-logprof permettent de créer des profils de manière interactive en observant le comportement d'une application et en générant des règles à partir de celui-ci. Par rapport aux modules de politique SELinux, la syntaxe est beaucoup plus facile à lire et à modifier manuellement.

L'inconvénient est que les règles basées sur les chemins d'accès ne suivent pas les fichiers lorsqu'ils sont déplacés. Un lien physique ou un montage lié peut, en théorie, contourner une restriction basée sur le chemin d'accès. AppArmor ne prend pas non plus en charge nativement les modèles MLS/MCS, ce qui lui permet d'isoler les conteneurs de l'hôte, mais pas les uns des autres comme le fait SELinux.

Comparaison côte à côte

Configuration de base

SELinux

Vérifiez l'état actuel :

sestatus
getenforce

Démarrez en mode Permissive pour consigner les violations sans rien bloquer :

setenforce 0

Utilisez la politique « targeted » pour la plupart des serveurs. Elle restreint les services à haut risque tels que les serveurs web et les bases de données tout en laissant le reste sans restriction. Rendez-la permanente dans /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

Inspectez les contextes de sécurité des fichiers et des processus :

ls -Z /var/www/html
ps -eZ | grep httpd

Si un service utilise un port non standard, mettez à jour la politique :

semanage port -a -t ssh_port_t -p tcp 9999

Pour les applications personnalisées générant des refus d'accès, créez un module de politique à partir du journal d'audit :

ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.pp

AppArmor

Vérifiez quels profils sont chargés :

sudo aa-status

Installez le paquet d'utilitaires si vous avez besoin d'outils de gestion des profils :

sudo apt install apparmor-utils

Générez un profil de manière interactive pendant l'exécution de l'application :

sudo aa-genprof /path/to/binary

Affinez le profil en analysant les journaux à la recherche d'infractions :

sudo aa-logprof

Faites basculer un profil d'un mode à l'autre :

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

Lequel choisir ?

La réponse pratique pour la plupart des administrateurs : utilisez ce qui est fourni avec votre distribution. RHEL, CentOS, Fedora et Rocky Linux sont livrés avec SELinux. Ubuntu, Debian et SUSE sont livrés avec AppArmor. Ces deux frameworks disposent d’outils et de politiques éprouvés pour leurs plateformes natives. Passer à l’option non par défaut sur n’importe quelle distribution ajoute du travail et réduit le soutien de la communauté.

Au-delà de cela, laissez vos besoins décider :

• Optez pour SELinux si vous devez vous conformer aux normes PCI DSS, HIPAA ou DISA-STIG. Si vous exécutez des charges de travail en conteneurs multi-locataires sur Kubernetes ou OpenShift. Si vous avez besoin d’une isolation de conteneur à conteneur sur des hôtes partagés. Si votre environnement traite des données classifiées ou à niveau de sensibilité.
• Choisissez AppArmor si vous utilisez Ubuntu ou Debian et souhaitez bénéficier d'une protection MAC sans courbe d'apprentissage trop raide. Si votre configuration consiste en un serveur unique ou un petit cluster exécutant des services web standard. Si la rapidité de déploiement prime sur un contrôle granulaire au niveau des étiquettes.

Ces deux frameworks n'ajoutent qu'une surcharge d'exécution minimale. SELinux met en cache les décisions d'accès dans son Access Vector Cache. Le chargement des politiques d'AppArmor peut entraîner un léger retard au démarrage, mais son impact est négligeable en cours d'exécution. Pour la plupart des charges de travail d'hébergement, aucun des deux ne constituera un goulot d'étranglement.

Si vous avez besoin d'une infrastructure d'hébergement fiable avec un accès root complet pour configurer l'un ou l'autre de ces frameworks, les serveurs dédiés ou VPS de FDC vous offrent le contrôle nécessaire pour configurer SELinux ou AppArmor selon les besoins de votre environnement.