AppArmor vs SELinux en 2026: cómo elegir y empezar

Si ya tienes un firewall bien configurado (UFW o firewalld), SSH con ed25519 y fail2ban, te queda un hueco grande en la cadena de hardening: el control de acceso obligatorio. Cuando un servicio es comprometido, el atacante hereda los permisos del proceso. Si ese proceso corre como root, el atacante es root. Ahí entran AppArmor y SELinux: limitan lo que un proceso puede hacer aunque el proceso mismo esté comprometido.

En 2026 el tema importa más que nunca por tres razones:

– Los contenedores (Docker, Podman, LXC) son ya la unidad básica de despliegue. Los motores de contenedores delegan el aislamiento a AppArmor o SELinux para que un escape de contenedor no signifique compromiso del host.
– Las distribuciones modernas vienen con uno de los dos activo por defecto: Ubuntu/Debian/openSUSE con AppArmor, Fedora/RHEL/AlmaLinux/Rocky con SELinux. No puedes ignorar el tema sin saber qué te protege.
– Hay un tercer competidor creciendo (BPF-LSM), pero todavía es experimental fuera de Google. Para 2026 el duelo real es AppArmor contra SELinux.

Esta guía te explica qué es cada uno, cómo funciona por dentro, en qué se diferencian, y cómo dar los primeros pasos con el que venga en tu distro.

Qué es AppArmor y cómo funciona

AppArmor es un sistema de control de acceso obligatorio (MAC) ligado a rutas del filesystem. Cada proceso corre confinado por un perfil que dice “este binario puede leer estos archivos, escribir en estos otros, y hacer estas llamadas de red, y nada más”. El perfil es texto plano y se lee bien.

El modelo mental es simple: en lugar de preguntar “qué usuario quiere hacer esto” (eso es el control discrecional, DAC, el tradicional de Unix), AppArmor pregunta “¿este binario tiene permiso de hacer esto?”. La identidad importa menos que el binario concreto.

Cómo está implementado

AppArmor se monta como módulo del kernel LSM (Linux Security Modules). El LSM se carga en el arranque si la distro lo incluye compilado. Ubuntu y Debian activan AppArmor por defecto desde hace años; SUSE lo trae desde 2005. La política se guarda en /etc/apparmor.d/ y cada perfil está en un archivo de texto.

El kernel mantiene una máquina de estados por perfil: enforce (bloquea violaciones y las registra), complain (solo registra, no bloquea, útil para desarrollar perfiles nuevos), o unconfined (sin restricción). El modo complain es la mejor forma de crear perfiles sin romper nada.

Anatomía de un perfil

Un perfil típico para un servicio pequeño:

sudo cat /etc/apparmor.d/usr.sbin.nginx

Vas a ver directivas como capability net_bind_service (permite al binario escuchar puertos por debajo de 1024), deny /etc/shadow r (niega lectura del archivo de contraseñas), y reglas de rutas como /var/www/** rwk (lectura, escritura y lock en /var/www). El lenguaje es declarativo, no procedural: listas lo permitido, todo lo demás está denegado por defecto.

Pros y contras de AppArmor

– Pros
– Sintaxis simple y perfiles cortos. Lo que haces en SELinux con 30 líneas, lo resuelves en 5 con AppArmor.
– Basado en rutas: si entiendes dónde están los archivos de un servicio, puedes escribir el perfil sin aprender un modelo de etiquetas nuevo.
– Modo complain para iterar sin romper nada en producción.
– Mejor integración con contenedores en Ubuntu y SUSE (snap, LXD).
– Contras
– El modelo basado en rutas es menos expresivo que el basado en etiquetas de SELinux. No puedes decir “este proceso solo puede leer archivos creados por procesos de tipo X”.
– No tiene MLS (Multi-Level Security) ni MCS (Multi-Category Security) real. Si tu aislamiento fuerte depende de separación de niveles (militares, gobierno), AppArmor no llega.
– Las políticas están atadas a rutas absolutas. Cambiar el directorio de instalación de un paquete rompe el perfil.

Qué es SELinux y cómo funciona

SELinux nació como un proyecto de la NSA en el año 2000, hoy mantenido por Red Hat. Su modelo es diferente al de AppArmor: usa etiquetas (labels) tanto en procesos como en archivos, y una política central que define cómo interactúan esas etiquetas.

En lugar de preguntarse “este binario quiere tocar este archivo”, SELinux pregunta “¿el tipo del proceso tiene permitido acceder al tipo del archivo, según las reglas de transición que aplican?”. Esa indirección permite modelar cosas que AppArmor no puede: MLS para separar datos por niveles de sensibilidad (top secret, secret, no clasificado), MCS para separar por categorías dentro del mismo nivel, y un modelo de roles para usuarios.

Cómo está implementado

SELinux viene en el kernel como módulo LSM. Fedora, RHEL, AlmaLinux, Rocky y CentOS lo activan por defecto en modo enforcing desde el primer boot. La política se compila con herramientas (checkpolicy, make policy) y se carga al inicio. Cada archivo del sistema tiene un contexto (etiqueta) almacenado en sus atributos extendidos. Cada proceso hereda un contexto cuando arranca.

El modo de operación es similar al de AppArmor: enforcing (bloquea y registra), permissive (solo registra), o disabled (no hace nada, no carga políticas). Pero hay un detalle importante: pasar de disabled a enforcing requiere que el sistema de archivos sea reetiquetado con restorecon -R /, porque si los archivos no tienen contexto SELinux, nada puede acceder a ellos.

Anatomía de un contexto

Un contexto SELinux se ve así: system_u:object_r:httpd_sys_content_t:s0. Cuatro campos separados por dos puntos:

– system_u: el usuario SELinux (no el usuario Unix).
– object_r: el rol.
– httpd_sys_content_t: el tipo (lo que más importa en la práctica).
– s0: el nivel MLS/MCS.

El tipo es lo que aparece en casi todas las reglas. Si quieres que Nginx sirva archivos en /var/www, esos archivos deben tener tipo httpd_sys_content_t. Si Nginx necesita escribir (uploads), el directorio debe ser httpd_sys_content_rw_t. Si quieres que Nginx se conecte a la red, el booleano httpd_can_network_connect debe estar en 1.

Pros y contras de SELinux

– Pros
– Modelo basado en etiquetas, expresivo. Permite reglas que AppArmor no puede expresar (MLS, MCS, separación entre contenedores).
– Mejor separación de contenedores. Red Hat usa SELinux como capa principal de aislamiento de pods en OpenShift; Kubernetes con CRI-O integra SELinux para multi-tenancy real.
– Política central compilada: imposible tener reglas contradictorias en dos archivos distintos.
– Mejor auditoría: cada denegación incluye contexto completo (qué proceso, con qué UID, intentando acceder a qué archivo con qué contexto).
– Contras
– Curva de aprendizaje alta. La primera vez que un servicio se rompe sin motivo evidente, sospechas de SELinux y aprendes a leer logs.
– Las herramientas de diagnóstico (audit2allow, sealert) tienen un costo cognitivo. Hay que entender qué te dicen antes de actuar.
– Cambiar un puerto no estándar requiere semanage port además del cambio en el archivo de configuración.
– En algunas distros (Debian) no está ni siquiera instalado por defecto.

Comparativa directa: AppArmor vs SELinux

Facilidad de uso

AppArmor gana por goleada si medimos tiempo hasta “primera política funcional”. En 15 minutos puedes tomar un binario, ejecutar aa-genprof, ejercitarlo manualmente, y tener un perfil en modo enforce. SELinux suele exigir 30 minutos solo para entender por qué un servicio que ayer funcionaba hoy no arranca.

La diferencia viene del modelo. AppArmor perfila binarios específicos; SELinux perfila tipos que pueden aplicarse a múltiples binarios y directorios. La expresividad de SELinux implica más conceptos para aprender antes de ser productivo.

Rendimiento

Ambos son módulos LSM que se enganchan en el mismo punto del kernel (las decisiones de acceso a archivos y capacidades). La diferencia en overhead es marginal en hardware moderno: el paper “A Comparative Analysis of Linux Mandatory Access Control” (ACM 2023) midió menos del 1% de diferencia entre los dos en cargas típicas (servidor web, base de datos, compilación).

Hay un caso donde AppArmor puede ser ligeramente más rápido: las decisiones basadas en rutas hacen una sola búsqueda en la tabla de inodo del filesystem. SELinux hace búsqueda del tipo en los atributos extendidos del archivo, y esa lectura adicional puede medirse en archivos muy pequeños accedidos millones de veces por segundo (escenario de build server con miles de archivos).

En resumen: para el 99% de servidores, ninguno de los dos va a ser tu cuello de botella. Si ves una caída de performance, no mires acá primero.

Soporte de distribución

| Distribución | MAC por defecto | Estado |
|—|—|—|
| Ubuntu 24.04+ | AppArmor | Activo en modo enforce |
| Debian 12+ | AppArmor | Disponible, no siempre activo |
| openSUSE Leap/Tumbleweed | AppArmor | Activo, elección en instalación |
| Fedora 42+ | SELinux | Activo en modo enforce |
| RHEL 9/10 | SELinux | Activo en modo enforce |
| AlmaLinux 9/10 | SELinux | Activo en modo enforce |
| Rocky Linux 9/10 | SELinux | Activo en modo enforce |
| Arch Linux | Ninguno por defecto | AppArmor instalable, SELinux requiere AUR |

Si eliges distro según el MAC que trae, no tienes que hacer nada extra. Peleas contra el default solo si tienes una razón concreta.

Casos de uso ideales

– AppArmor es la elección natural para: servidores Ubuntu/Debian en stacks LAMP o Node, contenedores LXD/snap, workstations donde necesitas aislar binarios específicos (navegador, lector PDF), entornos de home lab.
– SELinux es la elección natural para: infraestructura empresarial basada en RHEL, clusters Kubernetes/OpenShift con multi-tenancy, entornos con requisitos regulatorios (FIPS, Common Criteria, MLS para datos clasificados), sistemas donde necesitas separación fuerte entre procesos del mismo usuario.

¿Cuál elegir? Árbol de decisión

1. ¿Tu distro ya viene con uno activo? Si sí, quédate con ese. Peleas contra el default solo si tienes una razón concreta.
2. ¿Necesitas MLS/MCS o separación de contenedores estricta? Si sí, SELinux. AppArmor no llega.
3. ¿Tu equipo tiene experiencia con SELinux? Si no, AppArmor. La productividad inicial es mucho mayor.
4. ¿El binario que quieres confinar tiene perfil oficial en /etc/apparmor.d/? Si sí, AppArmor es tres clics.
5. ¿Estás desplegando Kubernetes/OpenShift? Si sí, SELinux. Los operadores esperan contexto SELinux para multi-tenancy.
6. ¿Home lab Ubuntu/Debian y quieres aprender MAC? Si sí, AppArmor. La documentación es más accesible y los errores son más fáciles de depurar.

En la práctica, el 80% de los servidores Linux en 2026 usan el MAC que vino con su distro y nunca tocan la configuración. El otro 20% son entornos Red Hat donde SELinux es política corporativa no negociable. El 1% restante es gente que necesita MLS real.

Tutorial práctico: cómo empezar

Paso 1: Descubre qué MAC tienes activo

El primer paso en cualquier servidor es saber qué tienes. Si no sabes, no puedes auditarlo.

En Debian/Ubuntu/openSUSE:

sudo aa-status

Te lista los perfiles cargados con su modo (enforce/complain/unconfined). Si ves perfiles como usr.sbin.nginx, usr.sbin.sshd, snap.firefox.firefox, AppArmor está activo.

En Fedora/RHEL/AlmaLinux/Rocky:

getenforce
sestatus

getenforce devuelve Enforcing, Permissive o Disabled. sestatus te da además el modo desde el último boot y la política cargada.

Si ninguno responde, probablemente no tienes ninguno de los dos activos. Ubuntu y Debian suelen traer AppArmor pero no siempre enforcing; Fedora siempre trae SELinux enforcing. Para servidores recién aprovisionados, asumir el default de la distro.

Paso 2: Crear un perfil AppArmor básico

Este ejemplo confina un script Python que lee un directorio específico. Útil cuando tienes un servicio custom sin perfil oficial.

Instala las herramientas:

sudo apt update
sudo apt install apparmor-utils

Copia el script a una ruta conocida. Supongamos /opt/miapp/miapp.py.

Lanza el generador de perfiles. aa-genprof te pone en un shell donde ejecutas tu aplicación y cada acceso a archivos o red que haga queda registrado:

sudo aa-genprof /opt/miapp/miapp.py

En la sesión interactiva, ejecuta tu aplicación y ejercita todos los flujos (leer config, escribir logs, abrir el puerto, leer la base). Al salir con F (Finish), aa-genprof genera el perfil en /etc/apparmor.d/opt.miapp.miapp.py.

Actívalo primero en modo complain para verificar que no rompe nada en producción:

sudo aa-complain /opt/miapp/miapp.py

Mantenlo en complain una semana, mira /var/log/audit/audit.log (o journalctl -k -g audit), y cuando veas que no hay más accesos “raros”, pásalo a enforce:

sudo aa-enforce /opt/miapp/miapp.py

A partir de acá, cualquier acceso fuera del perfil es bloqueado y registrado. Si tu app rompe, lo vas a ver en los logs y puedes ajustar el perfil con aa-logprof.

Paso 3: Setear un contexto SELinux básico

Este ejemplo aplica el contexto correcto a un directorio que vas a servir con Nginx. El default de Fedora hace que /var/www/html tenga el contexto httpd_sys_content_t, pero si sirves desde otro directorio (común en WordPress, Nextcloud, apps custom), hay que setearlo manualmente.

Lista el contexto actual:

ls -lZ /srv/webapp/

El flag -Z muestra el contexto SELinux junto al dueño y permisos Unix. Si ves unconfined_u:object_r:default_t:s0, ese directorio no tiene un tipo que Nginx pueda leer.

Agrega la regla de contexto permanente (sobrevive a reetiquetados):

sudo semanage fcontext -a -t httpd_sys_content_t '/srv/webapp(/.*)?'

El (/.*)? es la expresión regular estándar para “esta ruta y todo lo que contenga”. Aplícala al filesystem ahora:

sudo restorecon -R -v /srv/webapp/

-R es recursivo, -v muestra cada cambio. Después de esto, Nginx puede leer los archivos.

Si tu aplicación también necesita escribir (uploads, cache):

sudo semanage fcontext -a -t httpd_sys_content_rw_t '/srv/webapp/uploads(/.*)?'
sudo restorecon -R -v /srv/webapp/uploads/

El sufijo _rw_t es lo que habilita lectura más escritura. Si dejas solo _t, tu app va a poder leer pero no escribir, y vas a ver denegaciones con SELinux en enforcing.

Para verificar que todo quedó bien:

ls -lZ /srv/webapp/
sudo audit2why < /var/log/audit/audit.log

audit2why lee las denegaciones recientes y te explica en lenguaje natural qué regla faltó. Si sigues viendo denegaciones AVC después de un arreglo, audit2why es el primer comando que corres.

Paso 4: Solución rápida de problemas cuando algo se rompe

En AppArmor:

sudo aa-status | grep complain
dmesg | grep -i audit

Los perfiles en modo complain registran accesos sin bloquear. Si tu app se comporta raro y sospechas que es AppArmor, pásala temporalmente a complain y compara. Si en complain funciona y en enforce no, sabes que es un tema de permisos del perfil.

En SELinux:

sudo ausearch -m AVC -ts recent
sudo sealert -a /var/log/audit/audit.log

ausearch filtra solo denegaciones SELinux (los AVC, Access Vector Cache). sealert es el que te da el diagnóstico en lenguaje natural con la sugerencia de arreglo. Si sealert no está, instálalo con sudo dnf install setroubleshoot.

En ambos casos, el antipatrón es desactivar el MAC. Si la app se rompe, el problema casi siempre es un permiso específico que falta agregar al perfil o contexto, no una falla del MAC. Desactivar el MAC para “arreglar” algo es como sacarte el cinturón porque te aprieta.

Tendencias 2026 y hacia dónde va todo esto

Tres movimientos que vale la pena seguir:

– BPF-LSM: el kernel permite adjuntar programas BPF al subsistema LSM desde la versión 5.7. Esto abre la puerta a un MAC totalmente programable sin recompilar políticas. Google lo usa internamente. Todavía no es algo para el sysadmin promedio, pero en 2027-2028 va a empezar a llegar a las distros.
– MAC nativo de contenedores: el aislamiento entre pods en Kubernetes ya pasa por SELinux (RHEL/OpenShift) y por AppArmor (Ubuntu/k3s, y como opción en algunos managed clusters), aunque EKS y GKE históricamente han priorizado gVisor y seccomp. La conversación “AppArmor vs SELinux” se está moviendo a “cuál es mejor para nuestro orquestador”.
– Perfiles generados automáticamente: herramientas como bane (para AppArmor) y udica (para SELinux) generan perfiles a partir del comportamiento observado. No son perfectas pero bajan la barrera de entrada para adoptar MAC sin contratar un especialista.

La conclusión honesta: si tu distro trae uno de los dos activo, déjalo activo. La diferencia entre elegir conscientemente y dejar el default es marginal en la práctica. Lo que importa es que estés en modo enforcing y que sepas leer los logs cuando algo se rompe.

Conclusión

AppArmor y SELinux resuelven el mismo problema con filosofías diferentes. AppArmor es más rápido de aprender y suficiente para el 90% de los casos. SELinux es más expresivo y necesario cuando tienes requisitos estrictos de aislamiento. Ninguno es obsoleto en 2026; los dos siguen siendo mantenidos activamente y ganando perfiles oficiales con cada release de las distros.

Lo que no puedes hacer es ignorar el tema. Un firewall te protege del tráfico que no quieres recibir. SSH con claves te protege del acceso por contraseña. Pero si un servicio se compromete, lo único que evita que el atacante haga lo que quiera con tu servidor es el MAC. Y eso vale oro.

Empieza con aa-status o getenforce, según tu distro. A partir de ahí, el resto es práctica.

Lee también: UFW vs firewalld: cuál usar según tu distribución Linux 2026 para ver la capa de firewall que va antes del MAC, Fail2ban: protege tu servidor SSH contra ataques de fuerza bruta para la detención de intrusos, y eBPF en Linux: guía práctica de observabilidad y seguridad con bpftrace si querés ir un paso más allá con la observabilidad del kernel.

---

Preguntas frecuentes

Lee también

• Guía Fedora 44: Novedades, Instalación y Upgrade para Sysadmins Linux
• Configura VLANs en Linux con nmcli: Guía paso a paso para sysadmins
• Protege tu SSH: Guía esencial para configurar Fail2ban en Linux
• Guía Definitiva: Configura Kubernetes con kubeadm en Ubuntu para Sysadmins Linux
• Configura Prometheus y Grafana: Guía DevOps para SysAdmins Linux