Zero Trust en Linux 2025: SELinux, AppArmor y Políticas

El cambio de paradigma en seguridad de redes ha llevado a las organizaciones a abandonar el modelo de confianza implícita (castillo y foso) para adoptar un enfoque más riguroso: Zero Trust. Este modelo se basa en el principio de "nunca confíes, siempre verifica". En el ecosistema Linux, implementar Zero Trust a nivel de sistema operativo implica dominar dos módulos de seguridad fundamentales: SELinux (Security-Enhanced Linux) y AppArmor. Este artículo desglosa cómo estas herramientas de control de acceso obligatorio (MAC) se convierten en los pilares de una arquitectura Zero Trust sólida.

Zero Trust y el Sistema Operativo: Más Allá del Perímetro

El modelo Zero Trust asume que la red ya está comprometida. No existe una "zona segura" interna. Cada solicitud de acceso, ya sea de un usuario, un servicio o un proceso, debe ser autenticada, autorizada y cifrada de forma continua. A nivel de Linux, esto se traduce en:

Microsegmentación de procesos: Cada aplicación o servicio debe ejecutarse con los permisos mínimos indispensables.
Control de acceso granular: No basta con los permisos tradicionales de Unix (Usuario/Grupo/Otros). Se necesitan políticas que restrinjan qué archivos puede leer un proceso, qué puertos de red puede abrir o qué capacidades del kernel puede usar.
Registro y auditoría continua: Cada denegación de acceso debe ser registrada y analizada para detectar comportamientos anómalos.

Aquí es donde entran SELinux y AppArmor. Ambos implementan Control de Acceso Obligatorio (MAC), un nivel de seguridad que ni siquiera el usuario root puede eludir sin modificar explícitamente la política. Esto contrasta con el DAC (Control de Acceso Discrecional), donde el propietario de un archivo decide los permisos. En un mundo Zero Trust, el DAC es insuficiente porque un proceso comprometido con privilegios de root puede causar daños catastróficos.

SELinux: El Estándar de Seguridad Integrado en el Kernel

Desarrollado por la NSA, SELinux es un módulo de seguridad del kernel de Linux que proporciona un mecanismo de políticas de seguridad flexibles y potentes. Opera etiquetando cada objeto (archivos, procesos, sockets, etc.) con un contexto de seguridad y aplicando reglas que definen las interacciones permitidas.

Arquitectura y Políticas

SELinux funciona con tres modos principales:

Enforcing: Las políticas se aplican estrictamente. Las violaciones se registran y bloquean.
Permissive: Las violaciones se registran pero no se bloquean. Es ideal para depurar y construir políticas.
Disabled: SELinux está apagado (no recomendado en producción).

La política por defecto en distribuciones como Red Hat Enterprise Linux y Fedora es targeted, que protege los servicios de red más críticos (Apache, Nginx, MySQL, SSH) dejando al resto de procesos en un dominio sin restricciones. Para un enfoque Zero Trust más riguroso, se puede optar por una política strict (o MLS - Multi-Level Security), donde todos los procesos están confinados.

[INFO] Para verificar el estado de SELinux en tu sistema, usa getenforce. Para ver el contexto de un archivo, usa ls -Z. Para un proceso, usa ps auxZ.

Ejemplo Práctico: Confinando un Servidor Web con SELinux

Supongamos que tienes un servidor Apache configurado para servir contenido desde /var/www/html. En un entorno Zero Trust, queremos asegurarnos de que Apache solo pueda leer archivos en ese directorio y no pueda, por ejemplo, leer /etc/shadow o escribir en /tmp.

Identificar el contexto: El proceso httpd normalmente se ejecuta en el dominio httpd_t. Los archivos en /var/www/html deben tener el tipo httpd_sys_content_t.
```
ls -Z /var/www/html
# Output esperado: system_u:object_r:httpd_sys_content_t:s0 index.html
```
Crear un puerto personalizado (opcional): Si Apache escucha en un puerto no estándar (ej. 8080), hay que etiquetarlo.
```
semanage port -a -t http_port_t -p tcp 8080
```

Generar una política personalizada (módulo): Si necesitas que Apache lea un archivo de configuración en una ubicación no estándar, debes crear un módulo de política.

# Supón que Apache necesita acceso a /opt/app/custom.conf
# 1. Poner SELinux en modo Permissive temporalmente
setenforce 0
# 2. Ejecutar la acción que falla
systemctl restart httpd
# 3. Generar el módulo a partir de los logs de denegación
ausearch -m avc -ts recent | audit2allow -M my_httpd_module
# 4. Cargar el módulo
semodule -i my_httpd_module.pp
# 5. Volver a Enforcing
setenforce 1

Este flujo de trabajo (Permissive -> Auditoría -> Generar Política -> Enforcing) es la esencia de construir un sistema Zero Trust con SELinux. No asumes nada; verificas y autorizas cada acceso.

AppArmor: Simplicidad y Perfiles por Aplicación

AppArmor es la alternativa a SELinux, preferida en distribuciones como Ubuntu, Debian y SUSE. Su filosofía es diferente: en lugar de etiquetar todo el sistema, se centra en perfiles de aplicación. Cada perfil define qué recursos (archivos, redes, capacidades) puede acceder un programa específico.

Perfiles y Modos

Al igual que SELinux, AppArmor tiene modos:

Enforce: Las políticas se aplican.
Complain (o Audit): Las violaciones se registran pero no se bloquean.
Unconfined: Sin perfil (equivalente a DAC estándar).

Los perfiles se almacenan en /etc/apparmor.d/ y se nombran siguiendo la ruta del ejecutable (ej. /etc/apparmor.d/usr.sbin.nginx).

Diferencias Clave con SELinux

Característica	SELinux	AppArmor
Enfoque	Basado en etiquetas (labels)	Basado en rutas (pathnames)
Complejidad	Alta (políticas de tipo TE, RBAC, MLS)	Media (perfiles más legibles)
Gestión de archivos	Los archivos heredan el contexto del directorio padre	Se especifican rutas absolutas en el perfil
Soporte de distribución	RHEL, Fedora, CentOS, Rocky Linux	Ubuntu, Debian, OpenSUSE, SUSE Linux
Curva de aprendizaje	Empinada	Más suave

[TIP] Si tu organización usa Ubuntu, AppArmor es la opción nativa y más integrada. No intentes instalar SELinux en Ubuntu a menos que tengas una necesidad muy específica; la complejidad adicional rara vez vale la pena.

Ejemplo Práctico: Perfil AppArmor para Nginx

Vamos a crear un perfil básico para Nginx que solo permita leer archivos de /var/www/html y escribir logs en /var/log/nginx/.

Crear el perfil en modo complain:

# /etc/apparmor.d/usr.sbin.nginx
#include <tunables/global>

/usr/sbin/nginx {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  # Capacidades del sistema
  capability net_bind_service,
  capability setgid,
  capability setuid,

  # Red: escuchar en puerto 80 y 443
  network tcp,

  # Archivos de configuración
  /etc/nginx/** r,

  # Contenido web (solo lectura)
  /var/www/html/** r,

  # Logs (escritura y creación)
  /var/log/nginx/* w,
  /var/log/nginx/*.log w,

  # Archivos de PID y sockets
  /run/nginx.pid rw,
  /var/lib/nginx/** rwk,

  # Denegar todo lo demás implícitamente
  deny /** w,
}

Cargar el perfil y verificar:

apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx
aa-status | grep nginx
# Output esperado: /usr/sbin/nginx (enforce)

Probar el confinamiento: Si Nginx intenta leer un archivo fuera de /var/www/html, AppArmor lo bloqueará y registrará la denegación en /var/log/audit/audit.log o /var/log/syslog.

Estrategia Zero Trust Integrada: SELinux + AppArmor + Otras Capas

Ninguna herramienta por sí sola garantiza una seguridad absoluta. Una arquitectura Zero Trust en Linux debe combinar varias capas:

1. Endurecimiento del Kernel con sysctl

Ajusta parámetros del kernel para mitigar ataques comunes. Algunos ejemplos:

# /etc/sysctl.d/99-zero-trust.conf
# Deshabilitar el reenvío de paquetes (si no es router)
net.ipv4.ip_forward = 0
# Proteger contra ataques de envenenamiento ARP
net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
# Restringir la visibilidad de otros procesos
kernel.kptr_restrict = 2
kernel.dmesg_restrict = 1

2. Namespaces y Contenedores

Los contenedores (Docker, Podman) ya implementan un aislamiento basado en namespaces. Combínalos con perfiles de AppArmor o SELinux para un confinamiento adicional.

Con AppArmor: docker run --security-opt apparmor=my-custom-profile nginx
Con SELinux: docker run --security-opt label=type:container_t nginx

3. Auditoría Centralizada con Auditd

Tanto SELinux como AppArmor generan logs de denegación. Usa auditd para centralizarlos y enviarlos a un SIEM.

# /etc/audit/rules.d/audit.rules
# Registrar todas las denegaciones de SELinux
-w /var/log/audit/audit.log -p wa -k selinux_denials
# Monitorear cambios en binarios críticos
-w /usr/sbin/sshd -p x -k sshd_exec

4. Principio de Mínimo Privilegio (PoLP)

No solo en el sistema operativo, sino también en la configuración de la aplicación. Por ejemplo, en un servidor web:

El proceso no debe ejecutarse como root (usar User y Group en Apache/Nginx).
Los directorios de contenido deben ser propiedad de un usuario no privilegiado (ej. www-data).
Las políticas de SELinux/AppArmor deben ser lo más restrictivas posible, permitiendo solo las operaciones explícitamente necesarias.

Conclusión: ¿SELinux o AppArmor para tu Estrategia Zero Trust?

La elección entre SELinux y AppArmor depende en gran medida de tu distribución y la complejidad que estés dispuesto a gestionar.

Elige SELinux si: Trabajas en entornos RHEL/CentOS/Fedora, necesitas control de acceso multinivel (MLS) para datos clasificados, o tu equipo tiene experiencia en políticas TE (Type Enforcement). La granularidad de SELinux es superior, pero a costa de una mayor complejidad.
Elige AppArmor si: Usas Ubuntu/Debian, valoras la simplicidad y la legibilidad de los perfiles, o tu infraestructura es principalmente de contenedores. AppArmor es más fácil de aprender y mantener, lo que reduce el riesgo de errores humanos en la política.

[WARNING] No actives SELinux o AppArmor en un servidor de producción sin haberlo probado antes en un entorno de staging. Un perfil mal configurado puede denegar servicios esenciales y causar una caída del sistema. Usa siempre el modo Permissive (SELinux) o Complain (AppArmor) para auditar primero.

En última instancia, la seguridad Zero Trust con Linux no es un producto que se instala, sino una práctica que se adopta. SELinux y AppArmor son las herramientas que te permiten aplicar el principio de "confianza cero" a nivel de sistema operativo, microsegmentando procesos y garantizando que incluso si un atacante compromete una aplicación, no pueda moverse lateralmente por el sistema. Combinados con un endurecimiento del kernel, namespaces y auditoría continua, forman la base de una defensa robusta y moderna.