Guía completa de SELinux y AppArmor: cómo proteger aplicaciones y servicios sin complicarte la vida

SELinux y AppArmor son dos de las tecnologías más importantes para reforzar la seguridad de Linux. Ambas permiten limitar lo que pueden hacer aplicaciones y servicios, incluso si un atacante logra comprometer un proceso. En otras palabras: si Nginx, Apache, Samba, MySQL, un contenedor o una aplicación vulnerable cae en manos de un intruso, SELinux o AppArmor pueden impedir que ese proceso acceda a archivos, puertos, recursos o rutas que no debería tocar.

Estas tecnologías forman parte del ecosistema Linux Security Modules, una interfaz del kernel usada por extensiones de control obligatorio de acceso, como SELinux, AppArmor, Smack y TOMOYO. La documentación del kernel explica que los LSM permiten aplicar políticas de seguridad sobre procesos y recursos del sistema, más allá de los permisos tradicionales de usuario, grupo y otros.

1. Por qué necesitas SELinux o AppArmor

En Linux, los permisos clásicos son necesarios, pero no siempre suficientes. Si una aplicación web se ejecuta como usuario www-data o apache y un atacante explota una vulnerabilidad, podría intentar leer archivos, ejecutar comandos, escribir en directorios temporales o conectarse a otros servicios internos. SELinux y AppArmor reducen ese impacto mediante políticas de confinamiento.

Red Hat documenta SELinux como un mecanismo para impedir interacciones no autorizadas entre usuarios, procesos, archivos y dispositivos; además, explica que SELinux puede bloquear acciones incluso cuando los permisos tradicionales de Linux podrían permitirlas. Ubuntu, por su parte, describe AppArmor como una implementación de Linux Security Module que restringe capacidades y permisos de aplicaciones mediante perfiles por programa.

2. SELinux vs AppArmor: diferencia práctica

SELinux es muy potente y granular. Trabaja con etiquetas, tipos, contextos, dominios, políticas, booleans y reglas de acceso. Es común en Red Hat Enterprise Linux, Fedora, CentOS Stream, Rocky Linux y AlmaLinux. Su curva de aprendizaje suele ser mayor, pero ofrece un control muy profundo.

AppArmor suele ser más simple para empezar. Trabaja con perfiles asociados a rutas de ejecutables y reglas legibles que indican qué archivos, capacidades y recursos puede usar una aplicación. Es común en Ubuntu, Debian y SUSE. Ubuntu destaca que AppArmor usa perfiles por programa y que el paquete apparmor-utils incluye herramientas para cambiar modos, ver estado y crear perfiles.

3. Modos de funcionamiento: lo primero que debes revisar

Antes de modificar cualquier política, debes saber si SELinux o AppArmor están activos. En SELinux, los estados principales son Enforcing, Permissive y Disabled. Red Hat indica que getenforce muestra el modo actual y advierte que deshabilitar SELinux no solo evita aplicar la política, sino que también deja de etiquetar objetos persistentes, lo que dificulta volver a activarlo después.

getenforce
sestatus

En AppArmor, los perfiles pueden estar en modos como enforce o complain. En modo enforce se bloquean acciones no permitidas; en modo complain se permiten, pero se registran violaciones para que el administrador pueda ajustar el perfil. Debian y SUSE documentan el uso de aa-enforce y aa-complain para cambiar perfiles entre estos modos.

sudo aa-status
systemctl status apparmor

4. Regla de oro: no desactives, aprende a corregir

El error más común es ver un error de SELinux o AppArmor y desactivarlo todo. Eso puede “resolver” el problema momentáneamente, pero elimina una capa de defensa importante. Lo correcto es identificar qué se bloqueó, por qué se bloqueó y si la aplicación realmente necesita ese acceso.

Red Hat recomienda no usar audit2allow como primera opción ante una denegación de SELinux, porque muchas veces el problema real es una etiqueta incorrecta, un puerto sin contexto, un boolean mal configurado o un permiso tradicional de Linux mal aplicado.

5. SELinux en la práctica: comandos esenciales

SELinux trabaja con contextos. Cada proceso, archivo, puerto y recurso puede tener una etiqueta. Si una aplicación intenta acceder a un recurso con una etiqueta no permitida por su política, SELinux bloquea la acción.

ls -Z /var/www/html
ps auxZ | grep httpd
id -Z

Cuando mueves contenido web a una ruta no estándar, por ejemplo /srv/www, el problema no suele resolverse con chmod 777. Lo correcto es asignar el contexto adecuado y restaurarlo. Red Hat documenta el uso de semanage fcontext y restorecon para definir y aplicar contextos persistentes sobre archivos y directorios.

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

6. SELinux y puertos: el caso típico de Apache o Nginx en 8080

Otro caso común: configuras Apache, Nginx o una aplicación web en un puerto no estándar, como 8080 o 8443, y el servicio falla aunque el firewall esté abierto. En SELinux, no basta con que el puerto esté libre: también debe tener el tipo correcto.

Red Hat documenta que, si httpd necesita escuchar en un puerto no listado como http_port_t, se puede usar semanage port para asignar la etiqueta correcta.

sudo semanage port -l | grep http_port_t
sudo semanage port -a -t http_port_t -p tcp 8080

7. SELinux booleans: activar funciones sin romper la política

Los booleans son interruptores de política. Permiten habilitar comportamientos previstos sin escribir módulos personalizados. Por ejemplo, un servidor web que necesita conectarse a una base de datos remota puede requerir un boolean específico.

getsebool -a | grep httpd
sudo setsebool -P httpd_can_network_connect on

Red Hat indica que semanage boolean -l puede listar booleans con su significado, y recomienda revisar causas de denegación antes de generar reglas nuevas.

8. Cómo investigar errores de SELinux

Cuando SELinux bloquea algo, normalmente registra mensajes AVC. La ruta clásica es revisar audit.log, journalctl, ausearch, audit2why y, solo si corresponde, audit2allow.

sudo ausearch -m avc -ts recent
sudo journalctl | grep -i "avc:  denied"
sudo audit2why -a

El proyecto SELinux advierte que, ante problemas de política, primero se debe revisar si la causa real es un etiquetado incorrecto, un puerto mal etiquetado o una configuración que puede resolverse con semanage y restorecon, antes de generar reglas locales con audit2allow.

9. AppArmor en la práctica: comandos esenciales

AppArmor se administra mediante perfiles ubicados normalmente en /etc/apparmor.d/. Debian explica que los perfiles se almacenan allí y que contienen reglas de control de acceso sobre recursos que cada programa puede usar.

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

En Ubuntu, el paquete apparmor-utils proporciona utilidades para cambiar modos, consultar estado y crear perfiles. Ubuntu también documenta herramientas como aa-logprof para revisar eventos generados en modo complain y ajustar perfiles.

10. Cómo crear o ajustar un perfil AppArmor sin sufrir

La forma más segura de crear un perfil AppArmor es empezar en modo complain. En ese modo, la aplicación funciona, pero AppArmor registra lo que habría bloqueado. Luego puedes usar aa-logprof para convertir esos eventos en reglas revisadas.

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

# Usar la aplicación normalmente y generar actividad real

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

11. SELinux y AppArmor no reemplazan firewall, parches ni permisos

Una mala interpretación frecuente es creer que SELinux o AppArmor reemplazan otras medidas. No es así. Son una capa adicional. Debes seguir aplicando parches, usar firewall, configurar SSH correctamente, revisar usuarios, proteger backups y monitorear logs.

12. Cuándo elegir SELinux y cuándo AppArmor

En la práctica, la elección suele venir determinada por la distribución. Si usas RHEL, Rocky, AlmaLinux o Fedora, lo normal es trabajar con SELinux. Si usas Ubuntu, Debian o SUSE, lo habitual es AppArmor. No conviene pelearse con la distribución: usa la tecnología que ya viene integrada, documentada y mantenida por tu ecosistema.

13. Ejemplo práctico: servicio web con ruta personalizada

Supongamos que tu sitio web está en /srv/www y tu servidor no puede leer los archivos. Muchos administradores nuevos intentan resolverlo con permisos excesivos. El enfoque correcto depende del sistema.

14. Buenas prácticas para no complicarte la vida

15. Errores comunes que debes evitar

Preguntas clave

Recomendamos

En resumen

SELinux y AppArmor son capas esenciales para proteger aplicaciones y servicios en Linux. No sustituyen permisos, firewall, parches ni backups, pero agregan una defensa decisiva: limitar lo que una aplicación puede hacer incluso si fue comprometida.

La clave para no complicarte la vida es usar método: comprobar estado, leer logs, entender denegaciones, ajustar contextos o perfiles, probar en modo permissive o complain, documentar excepciones y volver siempre a enforcing o enforce. Un administrador que aprende SELinux o AppArmor deja de apagar la seguridad para resolver problemas y empieza a resolver problemas manteniendo la seguridad activa.