SELinux en producción — el workflow que de verdad funciona, y los denials AVC que seguimos encontrando

«Setenforce 0» no es una estrategia de seguridad. Sin embargo, es el «fix» más común que vemos para denials de SELinux en hosts de clientes. El razonamiento siempre es el mismo: una aplicación rompió, el mensaje de error mencionaba SELinux, alguien deshabilitó SELinux, la aplicación volvió a funcionar, y nadie regresó.

Este es el workflow de SELinux que usamos en cada host RHEL gestionado. La premisa: SELinux se queda en modo enforcing. La policy custom es pequeña y versionada. El debugging sigue un conjunto conocido de pasos, en orden.

Debugging de un denial AVC

# Paso 1 — ¿qué se denegó?
ausearch -m AVC -ts recent | grep denied
 
# Paso 2 — obtener la explicación legible por humanos
sealert -a /var/log/audit/audit.log
 
# Paso 3 — generar un módulo de policy candidato (revisar antes de aplicar)
ausearch -m AVC -ts recent | audit2allow -M my_app_policy
# LEE EL FICHERO my_app_policy.te. No lo apliques sin más.
 
# Paso 4 — si la policy es razonable, instalarla
semodule -i my_app_policy.pp

El paso 3 es el que la mayoría de equipos se saltan. audit2allow está encantado de generar una policy demasiado amplia. Revisa el fichero .te. Recorta lo que no debería estar. Luego aplica.

El artículo completo cubre:

• El workflow de debug de cinco pasos en orden (y qué hacer si el paso 4 no basta)
• La policy targeted — qué cubre y dónde extenderla
• Patrones de semanage fcontext para rutas de fichero no estándar
• Booleanos SELinux (getsebool -a | grep <service>) para los fixes fáciles
• Contextos de fichero que sobreviven a un restorecon
• La lista de booleanos monitoreados sobre los que alertamos (desactivar uno es una bandera roja)

Ejecutamos este workflow en cada host RHEL gestionado. SELinux se queda activo.