Seguridad Linux: SELinux, AppArmor y Políticas de Kernel 2025

Introducción a la Seguridad en el Kernel de Linux

La seguridad en Linux no es un lujo, es una necesidad. En entornos de producción, un fallo de seguridad puede traducirse en pérdida de datos, compromiso de sistemas críticos o exposición de información sensible. Aunque Linux es reconocido por su robustez, la complejidad de los servicios modernos y la creciente sofisticación de los ataques exigen capas adicionales de protección. Aquí es donde entran en juego SELinux y AppArmor, dos sistemas de control de acceso obligatorio (MAC) que operan directamente a nivel del kernel, junto con las políticas de seguridad del kernel que definen cómo se comporta el sistema ante amenazas.

Este artículo está diseñado para SysAdmins y profesionales de seguridad que buscan entender, implementar y optimizar estas herramientas. Abordaremos desde los fundamentos hasta ejemplos prácticos de configuración, todo en el contexto del hardening Linux. No solo explicaremos qué son, sino cómo usarlas para blindar tu infraestructura.

¿Qué es el Control de Acceso Obligatorio (MAC)?

Antes de profundizar en SELinux AppArmor, es crucial entender la diferencia entre el control de acceso discrecional (DAC) y el obligatorio (MAC). En el DAC tradicional de Linux, cada usuario o proceso decide los permisos de sus propios archivos (rwx). Esto es frágil: si un proceso malicioso obtiene privilegios de root, puede acceder a todo.

El MAC, en cambio, impone políticas globales que ni siquiera el root puede eludir sin la configuración adecuada. Tanto SELinux como AppArmor implementan MAC, pero con filosofías y enfoques distintos. Ambos operan como módulos de seguridad del kernel (LSM), añadiendo una capa de verificación en cada llamada al sistema.

SELinux: El Estándar en Entornos Empresariales

SELinux (Security-Enhanced Linux) fue desarrollado por la NSA y es el sistema MAC más potente y complejo. Se basa en etiquetas (contextos) para todos los objetos (archivos, procesos, puertos, etc.) y define reglas que especifican qué sujetos pueden acceder a qué objetos.

Arquitectura de SELinux

SELinux funciona con tres modos principales:

Enforcing: Las políticas se aplican estrictamente. Cualquier violación es bloqueada y registrada.
Permissive: Las violaciones se registran pero no se bloquean. Ideal para depurar políticas.
Disabled: SELinux está desactivado. No recomendado en producción.

Cada política contiene reglas basadas en tipos (Type Enforcement), roles (RBAC) y niveles de seguridad (MLS). Por ejemplo, un proceso httpd_t solo puede acceder a archivos etiquetados como httpd_sys_content_t.

Configuración básica de SELinux

Para comprobar el estado actual:

getenforce
sestatus

Para cambiar de modo temporalmente:

setenforce 0   # Permissive
setenforce 1   # Enforcing

Para hacerlo permanente, edita /etc/selinux/config:

SELINUX=enforcing
SELINUXTYPE=targeted

Ejemplo práctico: Permitir que Apache lea un directorio personalizado

Cuando SELinux bloquea el acceso, se registra en /var/log/audit/audit.log. Puedes usar audit2allow para generar políticas:

grep httpd /var/log/audit/audit.log | audit2allow -M my_httpd_policy
semodule -i my_httpd_policy.pp

[TIP] Usa sesearch para explorar reglas existentes: sesearch --allow -s httpd_t -c file -p read

Ventajas y desventajas de SELinux

Ventajas: Granularidad extrema, soporte en RHEL/CentOS/Fedora, ideal para entornos gubernamentales y financieros.
Desventajas: Curva de aprendizaje alta, puede romper aplicaciones mal configuradas, requiere mantenimiento constante.

AppArmor: Simplicidad y Eficacia

AppArmor (Application Armor) es la alternativa a SELinux, utilizada por defecto en distribuciones como Ubuntu, Debian y openSUSE. Su filosofía es "perfiles por aplicación". En lugar de etiquetar todo el sistema, se definen perfiles que describen qué recursos puede usar un programa específico.

Arquitectura de AppArmor

AppArmor también tiene modos:

Enforce: Las políticas se aplican.
Complain: Solo registra violaciones (modo aprendizaje).
Unconfined: Sin restricciones.

Los perfiles se almacenan en /etc/apparmor.d/ y tienen un formato legible. Por ejemplo, un perfil para ping podría verse así:

# /etc/apparmor.d/bin.ping
#include <tunables/global>

/bin/ping {
  #include <abstractions/base>
  #include <abstractions/nameservice>

  capability net_raw,
  network inet raw,
  /bin/ping mrix,
  /etc/modules.conf r,
}

Gestión de AppArmor

Comandos esenciales:

aa-status                    # Ver estado
aa-enforce /ruta/al/perfil  # Activar modo enforcing
aa-complain /ruta/al/perfil # Activar modo complain
aa-logprof                   # Analizar logs y generar perfiles

Ejemplo práctico: Crear un perfil para un script personalizado

Supongamos que tienes un script /opt/mi_script.sh que necesita acceso a /var/log/mi_app.log. Puedes generar un perfil con:

aa-genprof /opt/mi_script.sh

Esto inicia un asistente. Ejecuta el script en otra terminal y luego responde las preguntas en aa-genprof. Al final, tendrás un perfil personalizado.

[WARNING] No uses aa-complain en producción sin supervisión. Los logs pueden llenarse rápidamente.

Comparativa rápida: SELinux vs AppArmor

Característica	SELinux	AppArmor
Complejidad	Alta	Media
Granularidad	Muy alta (etiquetas)	Alta (perfiles por app)
Distribuciones	RHEL, CentOS, Fedora	Ubuntu, Debian, openSUSE
Curva de aprendizaje	Empinada	Suave
Mantenimiento	Requiere herramientas como `audit2allow`	Más intuitivo con `aa-logprof`

Políticas de Kernel: El Corazón del Hardening Linux

Más allá de SELinux y AppArmor, el kernel de Linux ofrece múltiples mecanismos de seguridad que forman parte del hardening Linux. Estos parámetros se configuran a través de sysctl y afectan a todo el sistema.

Principales parámetros de seguridad del kernel

Protección contra desbordamientos de búfer:

kernel.randomize_va_space = 2   # ASLR completo
kernel.exec-shield = 1          # Protección de ejecución

Restricción de enlaces simbólicos y hardlinks:

fs.protected_hardlinks = 1
fs.protected_symlinks = 1

Protección de memoria:

vm.mmap_min_addr = 65536        # Evita mapear direcciones bajas
kernel.kptr_restrict = 2        # Oculta direcciones del kernel

Redes y kernel:

net.ipv4.conf.all.rp_filter = 1         # Filtro de ruta inversa
net.ipv4.tcp_syncookies = 1             # Protección SYN flood
net.ipv4.conf.all.accept_redirects = 0  # Ignorar redirecciones ICMP

Cómo aplicar políticas de kernel

Edita /etc/sysctl.conf o añade archivos en /etc/sysctl.d/:

echo "kernel.randomize_va_space = 2" >> /etc/sysctl.d/99-security.conf
sysctl -p /etc/sysctl.d/99-security.conf

[INFO] Verifica siempre con sysctl -a | grep parametro que los cambios se hayan aplicado correctamente.

Integración con SELinux y AppArmor

Las políticas de kernel actúan como una base sobre la que se construyen SELinux y AppArmor. Por ejemplo, el ASLR del kernel complementa las restricciones de SELinux, dificultando la explotación de vulnerabilidades incluso si un proceso logra eludir el MAC.

Estrategia de Hardening Linux: Un Enfoque en Capas

Para un SysAdmin, la seguridad no es un producto, sino un proceso. Una estrategia efectiva combina:

Políticas de kernel: Configuración base del sistema.
SELinux o AppArmor: Control de acceso obligatorio.
Firewall (iptables/nftables): Filtrado de red.
Actualizaciones regulares: Parches de seguridad del kernel.
Monitorización: Logs de auditoría (auditd, SELinux logs, AppArmor logs).

Ejemplo de hardening completo en Ubuntu con AppArmor

# 1. Políticas de kernel
cat >> /etc/sysctl.d/99-hardening.conf << EOF
kernel.randomize_va_space = 2
fs.protected_hardlinks = 1
fs.protected_symlinks = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
EOF
sysctl -p /etc/sysctl.d/99-hardening.conf

# 2. Activar AppArmor para todos los perfiles
aa-enforce /etc/apparmor.d/*

# 3. Configurar firewall (ejemplo básico)
ufw default deny incoming
ufw allow ssh
ufw enable

# 4. Activar auditoría
apt install auditd
auditctl -e 1

Conclusión: ¿SELinux o AppArmor?

La elección entre SELinux AppArmor depende del entorno y la experiencia del equipo. En distribuciones empresariales como RHEL, SELinux es el estándar de facto. En Ubuntu o Debian, AppArmor ofrece una experiencia más amigable sin sacrificar seguridad.

Ambos sistemas, combinados con políticas de kernel sólidas, forman la base de un hardening Linux efectivo. Como SysAdmin, tu responsabilidad es entender las necesidades de tu infraestructura y aplicar estas herramientas de manera coherente. No se trata de activar todo sin criterio, sino de conocer qué proteges y cómo.

[WARNING] Nunca desactives SELinux o AppArmor en producción sin un plan de mitigación. Un sistema sin MAC es como una puerta abierta de par en par.

La seguridad en Linux es un viaje, no un destino. Sigue aprendiendo, audita tus configuraciones y mantente al día con las vulnerabilidades del kernel. Con las herramientas adecuadas y una mentalidad proactiva, tu infraestructura estará preparada para enfrentar las amenazas del mundo real.