# SELinux y AppArmor: el control de acceso obligatorio en Linux
- **Publicado el:** 2026-09-09
- **Categoría:** Noticias
- **Página original:** https://linuxgratis.com/articulos/selinux-y-apparmor
Qué son SELinux y AppArmor, cómo funciona el control de acceso obligatorio (MAC) en Linux y en qué se diferencian los dos grandes sistemas para confinar procesos.
---
Los permisos clásicos de Unix, el famoso `rwx` de usuario, grupo y otros, han protegido los sistemas Linux durante décadas. Pero tienen un límite estructural. Dependen de la buena voluntad del dueño de cada fichero y, peor aún, no detienen a un proceso que ya corre con privilegios. Si un servidor web comprometido se ejecuta como *root*, los permisos tradicionales no le impiden leer `/etc/shadow` ni escribir donde no debe. Para tapar ese agujero existe el **control de acceso obligatorio**, la segunda capa de seguridad que llevan integrada las distribuciones modernas.
## Qué es el control de acceso obligatorio (MAC)
El modelo habitual de Unix se llama control de acceso discrecional (DAC): "discrecional" porque cada usuario decide a su criterio quién accede a sus ficheros. El **control de acceso obligatorio** (MAC, *Mandatory Access Control*) le da la vuelta a esa lógica. Una política definida a nivel de sistema establece qué puede hacer cada proceso, y ni siquiera *root* puede saltársela sin cambiar antes esa política.
La diferencia es enorme. Con MAC, un proceso solo toca exactamente los recursos que la política le autoriza de forma explícita. Si un atacante se hace con un demonio, queda atrapado dentro de las reglas que confinan a ese demonio concreto, por mucho que técnicamente sea *root*. Confinar cada proceso a lo mínimo imprescindible es la base de los dos grandes sistemas MAC del mundo Linux: SELinux y AppArmor.
## SELinux: etiquetas y políticas heredadas de la NSA
El comando sestatus muestra el estado actual de SELinux y su política activa. · Imagen: Software: SELinux developersScreenshot: VulcanSphere / GPL · Wikimedia Commons
**SELinux** (Security-Enhanced Linux) nació en la Agencia de Seguridad Nacional estadounidense (NSA), que liberó la primera versión como software libre bajo licencia GPL el 22 de diciembre de 2000. El código entró en el kernel Linux principal con la versión 2.6.0-test3, en agosto de 2003, apoyándose en el marco de módulos de seguridad LSM (*Linux Security Modules*).
Su enfoque se basa en **etiquetas** (*labels*). SELinux asigna un contexto de seguridad a cada objeto del sistema: ficheros, procesos, puertos de red, dispositivos. La política decide qué etiquetas pueden interactuar con cuáles. Es un sistema de un detalle y una potencia poco comunes, capaz de aplicar *Type Enforcement*, control basado en roles (RBAC) y seguridad multinivel (MLS). Esa potencia tiene su contrapartida: una curva de aprendizaje empinada. Cuando algo no funciona, casi siempre es porque a un fichero le falta la etiqueta correcta.
SELinux viene activado por defecto y en modo *enforcing* en [Fedora](/fedora) y en [Red Hat Enterprise Linux](/rhel), y también en toda la familia de RHEL: [AlmaLinux](/almalinux), [Rocky Linux](/rocky-linux) y [CentOS Stream](/centos-stream). La política habitual, llamada *targeted*, confina los demonios más expuestos —servidores web, bases de datos, servicios de red— y deja relativamente libres los procesos de usuario. Es un equilibrio sensato entre seguridad y comodidad.
## AppArmor: rutas en lugar de etiquetas
AppArmor confina los programas mediante perfiles legibles basados en rutas del sistema de ficheros. · Imagen: Noah Davis / CC BY-SA 4.0 · Wikimedia Commons
**AppArmor** ofrece la misma protección MAC pero con otra filosofía: en vez de etiquetar cada objeto, define perfiles **basados en rutas** del sistema de ficheros. Un perfil dice, por ejemplo, que `/usr/sbin/nginx` puede leer cierto directorio, escribir en sus logs y abrir determinados puertos, y nada más. El perfil se asocia al programa por su ruta, y eso hace que los perfiles sean mucho más fáciles de leer y escribir que una política de SELinux.
Su historia se remonta a finales de los noventa, cuando se llamaba SubDomain dentro de la distribución Immunix. Novell compró aquella tecnología en 2005 y la rebautizó como AppArmor; desde la versión 2.6.36 del kernel forma parte del núcleo principal de Linux. Hoy es el sistema MAC por defecto en [Ubuntu](/ubuntu), [Debian](/debian) y [openSUSE](/opensuse), precisamente por lo sencillo que resulta. Crear o ajustar un perfil con herramientas como `aa-genprof` está al alcance incluso de administradores sin experiencia previa en seguridad avanzada.
## SELinux frente a AppArmor: cuándo elige cada uno
Aquí no hay ganador absoluto, sino dos compromisos distintos. SELinux apuesta por el control más exhaustivo posible: etiqueta todo el sistema y, bien configurado, ofrece un confinamiento difícil de superar, ideal para entornos que exigen certificaciones estrictas o aislamiento de alta seguridad. Lo pagas en complejidad y en un diagnóstico más laborioso.
AppArmor cede parte de ese detalle a cambio de claridad. Sus perfiles legibles, ligados a rutas concretas, se entienden de un vistazo y se mantienen con poco esfuerzo. Para muchos servidores y estaciones de trabajo, esa relación entre seguridad y simplicidad es justo lo que hace falta. Por eso cada distribución elige uno u otro según su público: la familia Red Hat prioriza el rigor con SELinux, mientras que las derivadas de Debian apuestan por la accesibilidad de AppArmor.
## Conviven con el resto de la seguridad del sistema
Conviene recordar que el MAC no sustituye a las demás capas, se suma a ellas. SELinux y AppArmor trabajan junto a los permisos clásicos, los *namespaces*, los *cgroups* y las *capabilities* del kernel para reforzar el aislamiento de contenedores y servicios. Ambos blindan bastante la seguridad de tecnologías como Docker o Podman, porque limitan lo que un contenedor comprometido podría hacer sobre el host.
El consejo práctico es claro: **no desactives el MAC de tu distribución**. La tentación de poner SELinux en *permissive* para que "deje de molestar" se entiende cuando algo falla, pero casi siempre esconde un problema de etiquetado que tiene solución. Aprender a leer los registros de auditoría y a ajustar políticas o perfiles compensa con creces. Donde un solo servicio comprometido puede tumbar una máquina entera, el control de acceso obligatorio es una de las mejores defensas que Linux pone, gratis, en tus manos.
