Selinux

7.3 SELinux y AppArmor: Control de Acceso Obligatorio (MAC)

---

Introducción

En el modelo tradicional de seguridad de Linux, basado en permisos UNIX (DAC, Discretionary Access Control), el propietario de un recurso decide quién puede acceder a él. Sin embargo, en entornos críticos esto no es suficiente: si un proceso es comprometido, puede acceder a todo lo que su usuario permita.

Aquí entran en juego SELinux y AppArmor, sistemas de Control de Acceso Obligatorio (MAC) que imponen políticas estrictas a nivel del kernel, limitando lo que los procesos pueden hacer independientemente de los permisos del usuario.

Para un Sysadmin, dominar estas tecnologías significa poder diseñar sistemas resilientes frente a intrusiones, incluso cuando una aplicación ha sido comprometida.

---

Objetivos de aprendizaje

Al finalizar este capítulo serás capaz de:

• Entender la diferencia entre DAC y MAC.
• Comprender la arquitectura de SELinux y AppArmor.
• Interpretar contextos y políticas de seguridad.
• Diagnosticar bloqueos de acceso causados por políticas.
• Gestionar y ajustar reglas de seguridad.
• Aplicar estos sistemas en entornos reales.

---

Conceptos Teóricos

1. DAC vs MAC

DAC (Discretionary Access Control)

• Basado en permisos tradicionales (chmod, chown).
• El usuario decide el acceso.

MAC (Mandatory Access Control)

• El sistema define políticas obligatorias.
• Ni siquiera root puede ignorarlas fácilmente.

Limitación de DAC

Un servicio comprometido puede acceder a cualquier recurso permitido al usuario, lo que amplifica el impacto de una brecha de seguridad.

---

2. SELinux (Security-Enhanced Linux)

SELinux es un sistema de seguridad desarrollado originalmente por la NSA.

Conceptos clave:

• Contextos de seguridad
• Tipos (types)
• Políticas

Ejemplo de contexto:

ls -Z /var/www

Output:

system_u:object_r:httpd_sys_content_t:s0 index.html

Componentes:

• user
• role
• type
• level

El elemento más importante es el type, que define lo que está permitido.

---

3. Modos de SELinux

getenforce

• Enforcing → bloquea accesos no permitidos
• Permissive → solo registra
• Disabled → desactivado

---

4. AppArmor

Alternativa más simple que SELinux.

Basado en:

• rutas de archivos (path-based)
• perfiles por aplicación

Ubicación:

/etc/apparmor.d/

---

5. Diferencias clave

Característica	SELinux	AppArmor
Modelo	basado en etiquetas	basado en rutas
Complejidad	alta	media
Flexibilidad	muy alta	moderada

---

Laboratorio Práctico

Escenario

Un servidor web (nginx) no puede acceder a un directorio personalizado /srv/app, aunque los permisos UNIX son correctos.

---

Parte 1: Diagnóstico con SELinux

---

Paso 1: Ver estado

getenforce

---

Paso 2: Comprobar contexto del directorio

ls -Zd /srv/app

Output incorrecto:

default_t

---

Paso 3: Comprobar logs

sudo journalctl | grep AVC

Ejemplo:

avc: denied { read } for pid=1234 comm="nginx"

---

Paso 4: Solucionar con contexto correcto

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

---

Explicación

• semanage → define política persistente
• restorecon → aplica contexto

---

Parte 2: Diagnóstico con AppArmor

---

Paso 1: Ver estado

sudo aa-status

---

Paso 2: Ver perfil de nginx

cat /etc/apparmor.d/usr.sbin.nginx

---

Paso 3: Logs de denegación

dmesg | grep apparmor

---

Paso 4: Ajustar perfil

sudo nano /etc/apparmor.d/usr.sbin.nginx

Añadir:

/srv/app/** r,

---

Paso 5: Recargar perfil

sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.nginx

---

Errores Comunes y Troubleshooting

1. Servicio funciona en permissive pero no en enforcing

-Causa:* política mal definida.

Solución:

sudo journalctl | grep denied

---

2. Se desactiva SELinux en lugar de arreglarlo

Mala práctica crítica

Desactivar SELinux elimina una capa de seguridad fundamental.

---

3. Contextos incorrectos tras copia de archivos

Solución:

restorecon -Rv /ruta

---

4. Problemas con AppArmor

Ver logs:

dmesg

---

5. Herramientas faltantes

Instalar:

sudo apt install policycoreutils

---

Buenas Prácticas (Nivel Senior)

1. Nunca desactivar SELinux en producción

Usar:

setenforce 0

solo para diagnóstico temporal.

---

2. Entender antes de modificar

• analizar logs
• identificar reglas implicadas

---

3. Usar herramientas auxiliares

audit2why
audit2allow

---

4. Aplicar mínimos privilegios

• limitar accesos por proceso
• reducir superficie de ataque

---

5. Versionar políticas

Guardar cambios en repositorio.

---

6. Testing previo

Entornos staging

Probar cambios antes de producción evita caídas de servicio.

---

7. Monitorización continua

Detectar anomalías en logs de seguridad.

---

8. Integración con hardening global

SELinux/AppArmor deben complementar:

• firewall
• SSH
• auditoría

---

Resumen y Siguiente Paso

Has aprendido a utilizar SELinux y AppArmor para implementar control de acceso obligatorio en Linux, entendiendo cómo los procesos pueden ser restringidos a nivel de kernel incluso si están comprometidos.

Este conocimiento eleva significativamente el nivel de seguridad de cualquier infraestructura Linux.

El siguiente paso es comenzar a trabajar con servicios reales en producción:

➡️ 8.1 Servidores Web (Nginx/Apache), donde aplicarás todo lo aprendido para desplegar aplicaciones seguras, eficientes y accesibles.