SELinux Sans Peur: Politiques Personnalisees pour Services Critiques
De l'audit avec audit2allow aux modules de policy versionnes maintenus en production, sans tomber dans le permissive eternel.
A chaque fois qu'un service casse sur RHEL ou Rocky, le reflexe de l'astreinte est le meme: setenforce 0, probleme regle, ticket ferme. Six mois plus tard le cluster entier tourne en permissive, personne ne se rappelle pourquoi, et le rapport de conformite devient de la science-fiction. L'equipe Basilisk OffSec a passe les deux dernieres annees a demolir des environnements comme ca en red teams autorises, et la conclusion est cash: SELinux desactive raccourcit le chemin d'un RCE PHP-FPM jusqu'a root en moins de 90 secondes. Cet article ne vend pas de magie, il montre le workflow qu'on utilise pour livrer des modules .pp versionnes en production sans casser les deploiements.
Avant d'ecrire la moindre policy, il faut lire ce qui existe deja. La commande seinfo -t liste environ 5 000 types sur RHEL 9 standard, et sesearch --allow -s httpd_t montre exactement ce qu'Apache peut toucher. On commence chaque investigation avec ausearch -m AVC -ts recent qui tourne en parallele du service en mode permissive TEMPORAIRE, jamais le systeme entier. Utilise semanage permissive -a httpd_t pour isoler uniquement le domaine sous investigation. Ce pattern a sauve des audits complets qu'on decrit dans Hardening de Serveur Linux: CIS Benchmark Applique Sans Casser la Prod, ou CIS exige enforcing global mais permet des exceptions documentees par domaine.
audit2allow est une arme a double tranchant. Lancer ausearch -m AVC | audit2allow -M monmodule genere un .te qui compile et fonctionne, mais accorde frequemment des permissions absurdes comme allow httpd_t shadow_t:file read. Notre checklist interne exige que chaque .te passe par une revue manuelle avant semodule -i. Cherche les regles touchant shadow_t, etc_t, kernel_t ou self:capability sys_admin, ce sont des drapeaux rouges. Lors d'une investigation recente decrite partiellement dans DFIR sous Linux: Triage Vivant avec UAC et Velociraptor, un module genere a l'aveugle avait ouvert l'acces a /etc/sudoers et personne ne l'a remarque pendant huit mois.
Pour les nouveaux services, on prefere ecrire la policy depuis zero avec le langage macro de refpolicy. Un module typique a trois fichiers: monservice.te avec les regles, monservice.fc avec les file contexts et monservice.if avec les interfaces pour les autres domaines. Le make -f /usr/share/selinux/devel/Makefile genere le .pp que tu installes avec semodule -i. On versionne ces trois fichiers dans git aux cotes d'Ansible, et chaque PR lance checkmodule -M -m et sediff contre la baseline. Ce processus se connecte a ce qu'on montre dans Supply Chain Security: Signature Sigstore et SBOM Reels en CI/CD, ou le .pp finit signe avec Sigstore avant d'atteindre les nodes.
Les services qui ouvrent des sockets sur des ports non standard sont le cas le plus frequent de casse silencieuse. Postgres sur 5433 par exemple necessite semanage port -a -t postgresql_port_t -p tcp 5433, pas une nouvelle policy. Nginx servant des fichiers hors de /var/www veut semanage fcontext -a -t httpd_sys_content_t "/srv/app(/.*)?" suivi de restorecon -Rv /srv/app. Quatre-vingts pourcent des cas qu'on voit sont des file contexts et du port labeling, pas de la nouvelle policy. L'equipe qui comprend cette distinction economise des heures, et le sujet revient quand on parle de pivoting interne dans Nmap Avance: Scripts NSE pour Recon Interne dans un Lab Corporatif Simule.
La maintenance en production exige de l'observabilite. On configure setroubleshoot-server en mode silent qui forward les AVCs vers le SIEM via journald, avec des regles Sigma calibrees pour les denials inattendus. Quand un deploy casse, l'alerte arrive avant que l'utilisateur se plaigne. On lance aussi sealert -a /var/log/audit/audit.log chaque semaine en staging pour attraper la policy drift. Cette boucle de retour continu est exactement ce qu'on defend dans Purple Team en Pratique: Construire une Boucle de Feedback Red vs Blue: la red team trouve le chemin, la blue team ecrit la policy, et la policy entre dans la pipeline.
A retenir cote pratique: ne lance jamais setenforce 0 en production plus de 15 minutes. Utilise semanage permissive -a domaine_t pour isoler le probleme, capture les AVCs avec ausearch, relis audit2allow a la main, commit le .te dans git, signe le .pp et deploie via Ansible. Si tu ne peux pas justifier chaque allow rule en code review, la policy n'est pas prete. SELinux n'est pas un obstacle, c'est le dernier perimetre une fois que l'attaquant est deja dedans.