SELinux en production — le workflow qui marche réellement, et les denials AVC que nous trouvons sans cesse

« Setenforce 0 » n'est pas une stratégie de sécurité. C'est cependant le « fix » le plus courant que nous voyons pour les denials SELinux sur les hôtes clients. Le raisonnement est toujours le même : une application a cassé, le message d'erreur mentionnait SELinux, quelqu'un a désactivé SELinux, l'application s'est remise à marcher, et personne n'est revenu.

Voici le workflow SELinux que nous utilisons sur chaque hôte RHEL managé. La prémisse : SELinux reste en mode enforcing. La policy custom est petite et versionnée. Le debugging suit un set d'étapes connues, dans l'ordre.

Debugger un denial AVC

# Étape 1 — qu'est-ce qui a été refusé ?
ausearch -m AVC -ts recent | grep denied
 
# Étape 2 — obtenir l'explication lisible par un humain
sealert -a /var/log/audit/audit.log
 
# Étape 3 — générer un module de policy candidat (revoir avant d'appliquer)
ausearch -m AVC -ts recent | audit2allow -M my_app_policy
# LISEZ LE FICHIER my_app_policy.te. Ne l'appliquez pas juste comme ça.
 
# Étape 4 — si la policy est raisonnable, l'installer
semodule -i my_app_policy.pp

L'étape 3 est celle que la plupart des équipes sautent. audit2allow est tout content de générer une policy beaucoup trop large. Revoyez le fichier .te. Élaguez ce qui ne devrait pas y être. Puis appliquez.

L'article complet couvre :

• Le workflow de debug en cinq étapes dans l'ordre (et que faire si l'étape 4 ne suffit pas)
• La policy targeted — ce qu'elle couvre et où l'étendre
• Patterns semanage fcontext pour les chemins de fichiers non standards
• Booléens SELinux (getsebool -a | grep <service>) pour les fixes faciles
• Contextes de fichiers qui survivent à un restorecon
• La liste des booléens monitorés sur lesquels nous alertons (en désactiver un est un red flag)

Nous faisons tourner ce workflow sur chaque hôte RHEL managé. SELinux reste activé.