SELinux vs AppArmor: Seguridad Avanzada en Linux 2025

Introducción: El Dilema de la Seguridad en Linux en 2025

La seguridad en Linux ha evolucionado desde ser una preocupación periférica hasta convertirse en el núcleo del diseño de sistemas modernos. Para cualquier sysadmin que opere en 2025, la pregunta no es si debe implementar un módulo de seguridad obligatorio, sino cuál y cómo hacerlo sin romper la funcionalidad del sistema. Dos gigantes dominan este campo: SELinux (Security-Enhanced Linux) y AppArmor. Ambos implementan controles de acceso obligatorio (MAC), pero lo hacen con filosofías y herramientas radicalmente diferentes. Este artículo profundiza en técnicas avanzadas, resolución de problemas comunes y estrategias de hardening que todo administrador debe dominar.

[INFO] Aunque SELinux es nativo de RHEL/CentOS/Fedora y AppArmor de Debian/Ubuntu/SUSE, ambos pueden instalarse en la mayoría de distribuciones. La elección suele depender del ecosistema y la experiencia del equipo.

## Fundamentos de Control de Acceso Obligatorio (MAC)

Antes de sumergirnos en configuraciones avanzadas, recordemos la diferencia clave entre DAC (Discretionary Access Control) y MAC. En un sistema Linux estándar, el usuario propietario de un archivo decide quién puede leerlo (DAC). Con MAC, una política central del sistema anula cualquier permiso del usuario. Esto significa que incluso si un proceso Apache es comprometido y se ejecuta como www-data, no podrá leer /etc/shadow a menos que la política SELinux o AppArmor lo permita explícitamente.

### ¿Por qué es crítico en 2025?

Con el aumento de ataques a la cadena de suministro, contenedores maliciosos y exploits de día cero, depender solo de parches y firewalls es insuficiente. Los módulos MAC actúan como una red de seguridad: limitan el daño que un atacante puede causar incluso si logra ejecución remota de código (RCE).

## SELinux Avanzado: Más Allá de `enforcing` y `permissive`

La mayoría de los administradores conocen los modos básicos de SELinux. Sin embargo, el verdadero poder reside en la personalización de políticas y el análisis de denegaciones.

### Políticas Personalizadas con `audit2allow`

Cuando SELinux bloquea una acción legítima, aparece un mensaje AVC (Access Vector Cache) en /var/log/audit/audit.log. La herramienta audit2allow convierte estos mensajes en módulos de política.

# Generar un módulo a partir de los últimos eventos de denegación
grep "denied" /var/log/audit/audit.log | audit2allow -M mi_personalizada
# Cargar el módulo
semodule -i mi_personalizada.pp

[WARNING] Usar audit2allow sin revisar puede crear políticas demasiado permisivas. Siempre inspecciona el archivo .te generado antes de compilarlo.

### Contextos de Archivos y Usuarios

SELinux etiqueta cada archivo, proceso y puerto con un contexto. El comando ls -Z revela esta información. Un error común es mover archivos usando cp en lugar de mv, ya que cp puede heredar el contexto del directorio destino, pero no siempre.

# Restaurar contextos de manera recursiva
restorecon -Rv /var/www/html
# Cambiar contexto manualmente
chcon -t httpd_sys_content_t /ruta/nuevo/archivo.html

### Booleans: El Interruptor Mágico

Los booleans son interruptores que activan o desactivan funcionalidades completas sin reescribir políticas. Por ejemplo, permitir que Apache se conecte a bases de datos:

# Listar booleanos relacionados con httpd
getsebool -a | grep httpd
# Activar la conexión a red para httpd
setsebool -P httpd_can_network_connect on

## AppArmor Avanzado: Perfiles y Aprendizaje Automático

AppArmor utiliza perfiles que definen lo que un programa puede hacer. A diferencia de SELinux, se basa en rutas de archivos, lo que lo hace más intuitivo pero potencialmente menos granular.

### Creación de Perfiles en Modo Aprendizaje

El modo "complain" (queja) permite que AppArmor registre todas las acciones de un programa sin bloquearlas. Esto es ideal para generar perfiles iniciales.

# Establecer un perfil en modo complain
aa-complain /usr/sbin/mysqld
# Ejecutar cargas de trabajo normales
# Luego generar el perfil a partir de los logs
aa-logprof
# Finalmente, ponerlo en modo enforce
aa-enforce /usr/sbin/mysqld

### Perfiles Anidados y Subperfiles

Para aplicaciones complejas como servidores web o bases de datos, se pueden crear perfiles para scripts hijos o procesos lanzados por el padre.

# Ejemplo de perfil para un script CGI
/var/www/cgi-bin/script.sh {
  /bin/bash rix,
  /var/www/cgi-bin/script.sh r,
  /tmp/ rw,
  /etc/passwd r,
}

[TIP] Usa aa-genprof para perfiles rápidos y aa-easyprof para aplicaciones empaquetadas en Snap o Flatpak.

### Cacheo y Rendimiento

AppArmor almacena en caché los perfiles compilados en /etc/apparmor.d/cache/. Si modificas un perfil y no ves cambios, limpia la caché:

systemctl restart apparmor
# O manualmente
rm -rf /etc/apparmor.d/cache/*
apparmor_parser -r /etc/apparmor.d/*

## Estrategias de Hardening Combinadas

Un sysadmin experto no elige solo una herramienta; las combina. Aquí hay un stack de seguridad recomendado para 2025:

MAC primario: AppArmor para aplicaciones web (por su facilidad de perfilado).
MAC secundario: SELinux para servicios críticos del sistema (SSH, cron, systemd).
Refuerzo adicional:
- Seccomp (filtro de llamadas al sistema) para contenedores Docker.
- Capabilities de Linux (eliminar CAP_SYS_ADMIN de contenedores).
- LSM stacking (cargar múltiples módulos LSM, aunque SELinux y AppArmor no son compatibles simultáneamente).

### Ejemplo: Hardening de un Servidor Web con Nginx y PHP-FPM

Supongamos que usamos Ubuntu (AppArmor por defecto) pero queremos aplicar restricciones adicionales.

# 1. Perfil AppArmor para PHP-FPM
# /etc/apparmor.d/php-fpm
/usr/sbin/php-fpm* {
  /etc/php/** r,
  /var/run/php/** rw,
  /var/www/html/** r,
  /tmp/ rw,
  /proc/ r,
  deny /bin/bash x,
  deny /usr/bin/python x,
}

# 2. Reforzar Nginx con systemd
# Añadir en /etc/systemd/system/nginx.service.d/override.conf
[Service]
CapabilityBoundingSet=CAP_NET_BIND_SERVICE CAP_NET_RAW
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true

## Resolución de Problemas Comunes

### SELinux: Aplicación no inicia tras cambio de contexto

Síntoma: Apache no puede leer archivos en /srv/nuevo-sitio.
Diagnóstico: sealert -l * o revisar ausearch -m avc -ts recent.
Solución: Restaurar contextos o modificar la política.

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

### AppArmor: Perfil no se aplica

Síntoma: aa-status muestra el perfil en modo "complain" pero no en "enforce".
Solución: Verificar que el binario coincida exactamente con la ruta del perfil. AppArmor es sensible a enlaces simbólicos.

# Forzar la recarga
apparmor_parser -r /etc/apparmor.d/usr.bin.mysqld

[WARNING] Nunca copies perfiles entre distribuciones diferentes. Las rutas de los binarios y las bibliotecas pueden variar, causando fallos silenciosos.

## Automatización con Ansible y Puppet

En entornos con cientos de servidores, la gestión manual es inviable. Aquí hay un playbook de Ansible para SELinux:

- name: Configurar SELinux en servidores web
  hosts: webservers
  tasks:
    - name: Asegurar que SELinux está en enforcing
      selinux:
        policy: targeted
        state: enforcing
    - name: Activar booleans para Apache
      seboolean:
        name: "{{ item }}"
        state: yes
        persistent: yes
      loop:
        - httpd_can_network_connect
        - httpd_enable_homedirs
    - name: Restaurar contextos en /var/www
      command: restorecon -Rv /var/www

Para AppArmor, Puppet tiene el módulo puppetlabs/apparmor que permite gestionar perfiles como recursos.

## El Futuro: eBPF y Políticas Dinámicas

En 2025, eBPF (extended Berkeley Packet Filter) está revolucionando la seguridad. Herramientas como Falco o Tetragon permiten monitorear y bloquear llamadas al sistema en tiempo real sin modificar el kernel. Aunque SELinux y AppArmor seguirán siendo esenciales para el control de acceso estático, la tendencia es hacia políticas adaptativas que aprenden del comportamiento normal del sistema.

[INFO] Las políticas de SELinux y AppArmor son estáticas: se definen antes de la ejecución. eBPF permite políticas reactivas que cambian según el contexto (ej: bloquear escrituras en /tmp si el proceso no es de confianza).

## Conclusión

Dominar SELinux y AppArmor ya no es opcional para un sysadmin en 2025. La clave está en entender sus diferencias filosóficas: SELinux ofrece un control granular basado en etiquetas, mientras que AppArmor prioriza la facilidad de uso con perfiles basados en rutas. Ambos son pilares del hardening moderno.

Recomendación final: Elige SELinux si trabajas en entornos RHEL/CentOS con aplicaciones críticas que requieren un aislamiento fino. Elige AppArmor si buscas una curva de aprendizaje suave y rapidez en la creación de perfiles para aplicaciones web. Pero en ambos casos, automatiza, monitorea y nunca confíes en el modo permisivo como solución permanente.

La seguridad no es un producto, es un proceso. Y en Linux, ese proceso comienza con SELinux o AppArmor.