SELinux frente a AppArmor: comparación para servidores Linux
15 min de lectura - 21 de mayo de 2026

Comparación de SELinux y AppArmor para la seguridad de servidores Linux: Aprenda cómo funciona cada marco MAC, las diferencias clave y cuál elegir para su configuración de alojamiento.
SELinux frente a AppArmor: ¿qué marco MAC se adapta mejor a tu servidor?
Tanto SELinux como AppArmor aplican el control de acceso obligatorio (MAC) en Linux, restringiendo lo que pueden hacer los procesos incluso si obtienen privilegios de root. La diferencia radica en cómo lo hacen. SELinux asigna etiquetas persistentes a cada archivo y proceso. AppArmor, en cambio, utiliza reglas de ruta de archivos. Esa única elección de diseño determina todo lo demás: la complejidad, el nivel de seguridad y qué distribución incluye qué herramienta por defecto.
Cómo funciona SELinux
SELinux fue desarrollado originalmente por la NSA y viene incluido de forma predeterminada en RHEL, CentOS, Fedora y Rocky Linux. Etiqueta cada objeto del sistema, incluidos archivos, procesos, puertos y sockets, con un contexto de seguridad en el formato user:role:type:level. El type campo realiza la mayor parte del trabajo mediante un mecanismo denominado «Type Enforcement» (TE).
Por ejemplo, el servidor web Apache se ejecuta como httpd_t. Los archivos de contenido web tienen un tipo diferente. Si ninguna regla de la política permite explícitamente httpd_t el acceso a ese tipo de contenido, la solicitud es denegada. Se trata de un modelo de denegación por defecto. No se permite nada a menos que una regla indique lo contrario.
SELinux también es compatible con la seguridad multinivel (MLS) y la seguridad multicategoría (MCS), que clasifican los datos por nivel de confidencialidad y restringen el acceso en consecuencia. MCS es lo que proporciona a SELinux su sólido aislamiento de contenedores, manteniendo los contenedores separados entre sí y del host. Esto es importante en entornos de Kubernetes y OpenShift, donde los pods comparten un nodo.
La contrapartida es la complejidad. SELinux tiene una curva de aprendizaje pronunciada. Resolver los problemas de denegación de acceso implica leer registros de auditoría, comprender los contextos de seguridad y, en ocasiones, generar módulos de políticas personalizados con audit2allow. Para los equipos que no cuentan con personal de seguridad dedicado, esa sobrecarga es una realidad.
Cómo funciona AppArmor
AppArmor adopta un enfoque diferente. En lugar de etiquetar objetos, asigna perfiles de seguridad a las aplicaciones en función de sus rutas de archivo. Un perfil para /usr/sbin/nginx define qué directorios puede leer Nginx, a qué puertos puede conectarse y qué capacidades necesita. Los perfiles son archivos de texto sin formato almacenados en /etc/apparmor.d/.
AppArmor es el marco MAC predeterminado en Ubuntu, Debian y SUSE. Forma parte del núcleo de Linux desde la versión 2.6.36. Las aplicaciones sin perfil recurren a los permisos DAC estándar de Linux.
AppArmor se ejecuta en dos modos por perfil: Enforce (bloquea y registra las infracciones) y Complain (registra las infracciones sin bloquearlas). Esto hace que sea práctico implementar nuevos perfiles de forma gradual. Comience en modo Complain, revise los registros, endurezca el perfil y luego cambie a Enforce.
Herramientas como aa-genprof y aa-logprof ayudan a crear perfiles de forma interactiva observando lo que hace una aplicación y generando reglas a partir de su comportamiento. En comparación con los módulos de políticas de SELinux, la sintaxis es mucho más fácil de leer y editar a mano.
La desventaja es que las reglas basadas en rutas no siguen a los archivos cuando estos se mueven. Un enlace físico o un montaje vinculado pueden, en teoría, eludir una restricción basada en rutas. AppArmor tampoco cuenta con soporte nativo para MLS/MCS, por lo que puede aislar los contenedores del host, pero no entre sí, como hace SELinux.
Comparación lado a lado
| Característica | SELinux | AppArmor |
|---|---|---|
| Modelo de control de acceso | Basado en etiquetas (contextos de seguridad) | Basado en rutas (ubicaciones del sistema de archivos) |
| Postura predeterminada | Denegar todo | Permitir todo (restricciones por perfil) |
| Movimiento de archivos | Las etiquetas siguen al archivo | Seguridad vinculada a la ruta |
| Compatibilidad con MLS/MCS | Sí | No |
| Aislamiento de contenedores | De contenedor a contenedor y de contenedor a host | Solo de contenedor a host |
| Formato de la política | Módulos binarios compilados | Archivos de texto legibles por humanos |
| Distribuciones predeterminadas | RHEL, Fedora, CentOS, Rocky Linux | Ubuntu, Debian, SUSE |
| Curva de aprendizaje | Elevada | Moderada |
Configuración básica
SELinux
Comprueba el estado actual:
sestatus
getenforceInicie en modo permisivo para registrar las infracciones sin bloquear nada:
setenforce 0Utilice la política «targeted» para la mayoría de los servidores. Esta política restringe los servicios de alto riesgo, como los servidores web y las bases de datos, mientras deja todo lo demás sin restricciones. Haga que sea permanente en /etc/selinux/config:
SELINUX=enforcing
SELINUXTYPE=targetedInspecciona los contextos de seguridad de los archivos y procesos:
ls -Z /var/www/html
ps -eZ | grep httpdSi un servicio utiliza un puerto no estándar, actualice la política:
semanage port -a -t ssh_port_t -p tcp 9999Para aplicaciones personalizadas que generan denegaciones de acceso, crea un módulo de política a partir del registro de auditoría:
ausearch -m avc -ts recent | audit2allow -M my_custom_policy
semodule -i my_custom_policy.ppAppArmor
Compruebe qué perfiles están cargados:
sudo aa-statusInstala el paquete de utilidades si necesitas herramientas de gestión de perfiles:
sudo apt install apparmor-utilsGenera un perfil de forma interactiva mientras se ejecuta la aplicación:
sudo aa-genprof /path/to/binaryPerfeccione el perfil analizando los registros en busca de infracciones:
sudo aa-logprofCambia un perfil entre modos:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx
sudo aa-complain /etc/apparmor.d/usr.sbin.nginx¿Cuál deberías usar?
La respuesta práctica para la mayoría de los administradores: utiliza lo que venga con tu distribución. RHEL, CentOS, Fedora y Rocky Linux incluyen SELinux. Ubuntu, Debian y SUSE incluyen AppArmor. Ambos marcos cuentan con herramientas y políticas maduras para sus plataformas nativas. Cambiar a la opción no predeterminada en cualquier distribución supone más trabajo y reduce el soporte de la comunidad.
Más allá de eso, deja que tus requisitos decidan:
- Elige SELinux si necesitas cumplir con PCI DSS, HIPAA o DISA-STIG. Si ejecutas cargas de trabajo de contenedores multitenant en Kubernetes u OpenShift. Si necesitas aislamiento de contenedor a contenedor en hosts compartidos. Si tu entorno maneja datos clasificados o con niveles de confidencialidad.
- Elige AppArmor si utilizas Ubuntu o Debian y quieres protección MAC sin una curva de aprendizaje pronunciada. Si tu configuración es un servidor único o un pequeño clúster que ejecuta servicios web estándar. Si la rapidez de implementación es más importante que el control granular a nivel de etiquetas.
Ambos marcos añaden una sobrecarga mínima en tiempo de ejecución. SELinux almacena en caché las decisiones de acceso en su Access Vector Cache. La carga de políticas de AppArmor puede añadir un pequeño retraso al arrancar, pero tiene un impacto insignificante en tiempo de ejecución. Para la mayoría de las cargas de trabajo de alojamiento, ninguno de los dos supondrá un cuello de botella.
Si necesitas una base de alojamiento fiable con acceso root completo para configurar cualquiera de los dos marcos, los servidores dedicados o VPS de FDC te ofrecen el control necesario para configurar SELinux o AppArmor según lo requiera tu entorno.

Procesos zombis en Linux: Encontrar, Eliminar, Prevenir
Aprenda a identificar, eliminar y prevenir procesos zombis en Linux. Comandos, correcciones de código y consejos de supervisión para administradores de servidores.
15 min de lectura - 19 de mayo de 2026
Lista de comprobación para el refuerzo de servidores Linux
15 min de lectura - 8 de mayo de 2026