SELinux et AppArmor : confiner Linux avec le MAC

Les permissions Linux standard sont discrétionnaires : le propriétaire d'un fichier décide qui peut le lire ou l'écrire, et un processus compromis exécuté sous un utilisateur hérite de tout ce que cet utilisateur peut atteindre. Le contrôle d'accès obligatoire (MAC) ajoute une seconde couche de politique, à l'échelle du système, que même root ne peut pas contourner facilement : un serveur web piraté reste confiné exactement à ce que sa politique autorise. Cet article couvre les deux implémentations de production — SELinux et AppArmor — et comment les garder actives plutôt que de les désactiver.

Ce que le MAC ajoute au DAC

Le contrôle d'accès discrétionnaire (DAC) — les bits rwx et la propriété classiques traités dans les permissions de système de fichiers — est décidé par objet, par son propriétaire. Le MAC applique au contraire une politique centrale définie par l'administrateur, indépendante de la propriété des fichiers. Si un attaquant détourne nginx, le DAC laisse ce processus lire tout ce que l'utilisateur nginx peut lire ; le MAC exige en plus que l'action corresponde à la politique du domaine httpd_t (SELinux) ou du profil /usr/sbin/nginx (AppArmor). La politique l'emporte : le confinement tient même face à une faille de niveau root dans le service confiné.

Deux implémentations dominent. SELinux (RHEL, Fedora, CentOS, Amazon Linux) étiquette chaque processus et fichier avec un contexte de sécurité et applique le type enforcement entre eux. AppArmor (Ubuntu, Debian, SUSE) attache des profils basés sur les chemins à des binaires individuels. Choisissez celui qui est natif à votre distribution plutôt que de le remplacer.

SELinux : le garder en enforcing

Vérifiez d'abord l'état courant :

getenforce          # Enforcing, Permissive ou Disabled
sestatus            # statut complet, politique et points de montage

Rendez le mode enforcing permanent dans la configuration, puis activez-le à chaud sans redémarrer :

# /etc/selinux/config
SELINUX=enforcing
SELINUXTYPE=targeted

setenforce 1        # passer en enforcing maintenant

Ne « réparez » jamais un service cassé avec setenforce 0 ni en mettant SELINUX=permissive. Cela désactive la protection globalement. Lisez plutôt le refus et ajustez la politique. Les refus SELinux apparaissent sous forme d'enregistrements AVC dans le journal d'audit :

ausearch -m AVC,USER_AVC -ts recent
sealert -a /var/log/audit/audit.log   # analyse lisible par un humain

La plupart des refus légitimes se résolvent de trois façons. Activez un booléen si le comportement est prévu par la politique :

getsebool -a | grep httpd
setsebool -P httpd_can_network_connect on   # -P persiste après redémarrage

Corrigez un fichier mal étiqueté avec le bon contexte :

semanage fcontext -a -t httpd_sys_content_t "/srv/web(/.*)?"
restorecon -Rv /srv/web

En dernier recours seulement, générez un module de politique ciblé à partir des refus réels :

ausearch -m AVC -ts recent | audit2allow -M monmodule
semodule -i monmodule.pp

Examinez toujours ce que propose audit2allow avant de le charger : autoriser aveuglément chaque refus annule l'intérêt du MAC.

AppArmor : profils et modes

AppArmor confine les binaires via des profils dans /etc/apparmor.d/. Vérifiez l'état :

aa-status           # profils chargés, comptes enforce vs complain

Chaque profil s'exécute en mode enforce (violations bloquées et journalisées) ou complain (violations journalisées seulement). Faites passer un profil d'un mode à l'autre :

aa-complain /etc/apparmor.d/usr.sbin.nginx   # journaliser pendant le réglage
aa-enforce  /etc/apparmor.d/usr.sbin.nginx   # bloquer une fois réglé

Exécutez le service en mode complain, sollicitez-le, puis affinez le profil de façon interactive à partir des événements journalisés :

aa-logprof          # parcourir les événements, accepter/refuser chaque règle

Installez les profils communautaires supplémentaires pour couvrir davantage de démons d'emblée :

apt install apparmor-profiles apparmor-profiles-extra apparmor-utils

Comme pour SELinux, la règle est la même : ne déchargez pas un profil pour faire fonctionner une application. Passez-le en complain, capturez ses besoins, encodez-les avec aa-logprof, puis remettez-le en enforce.

Conseils opérationnels

Traitez un refus comme un signal, pas comme une nuisance. Transmettez les événements AVC et AppArmor à votre pipeline comme décrit dans la journalisation et l'audit afin que les échecs de confinement soient visibles. Lorsque vous confinez les services systemd, le MAC se combine aux directives de sandboxing pour une défense en profondeur. La plupart des référentiels de sécurité des benchmarks de conformité exigent explicitement que le MAC soit installé et actif — le désactiver est une non-conformité garantie.

Vérifier

Confirmez que le MAC est actif et applique sa politique :

# SELinux
getenforce                              # doit afficher : Enforcing
grep '^SELINUX=' /etc/selinux/config    # doit être : SELINUX=enforcing

# AppArmor
aa-status --enforced                    # nombre de profils en mode enforce
systemctl is-active apparmor            # active

Si getenforce renvoie Permissive ou Disabled, ou si AppArmor signale zéro profil en enforce, votre couche MAC ne protège pas le système — corrigez la politique, n'abaissez pas le mode.