¿Cómo usar los sistemas de control de accesos SELinux y AppArmor?

Hasta ahora, los permisos de archivos (DAC, Control de Acceso Discrecional) dependen de que el propietario del proceso o archivo decida quién accede. Si un atacante compromete un proceso con privilegios, puede causar estragos.

16.1. Introducción: Más allá de los permisos tradicionales

Los sistemas de Control de Acceso Obligatorio (MAC) imponen políticas centrales que restringen lo que cada proceso puede hacer, independientemente del usuario que lo ejecute, esto confina a los servicios y aplicaciones en “jaulas” de permisos. Los dos más importantes en Linux son SELinux (Security-Enhanced Linux) y AppArmor.

• SELinux: creado por la NSA, adoptado por Red Hat (RHEL, CentOS, Fedora). Usa etiquetas de seguridad (contextos) en cada archivo, proceso y recurso, y políticas complejas que definen transiciones y accesos.
• AppArmor: desarrollado por Novell/Canonical, usado por Ubuntu y SUSE. Asigna perfiles a los programas que especifican rutas y capacidades permitidas. Es más sencillo de administrar.

Ambos pueden estar en modo permisivo (registrar violaciones) o enforcing (bloquear). En el examen LFCS, normalmente deberás demostrar la capacidad de comprobar el estado, cambiar modos, ajustar contextos/perfiles y solucionar problemas básicos.

16.2. ¿Qué diferencias existen entre DAC y MAC?

Ambos sistemas se superponen: un proceso debe cumplir los permisos DAC y las reglas MAC para acceder a un recurso.

Parte I: SELinux

16.3. Modos de SELinux

SELinux puede estar en uno de tres modos:

• Enforcing: aplica las políticas, bloquea y registra violaciones.
• Permissive: no bloquea, solo registra (útil para depurar).
• Disabled: SELinux desactivado completamente.

16.3.1. Verificar el estado actual

getenforce
# Enforcing / Permissive / Disabled

sestatus
# Muestra más detalle: modo actual, modo del archivo de configuración, política cargada, etc.

16.3.2. ¿Cómo cambiar de modo temporalmente?

Solo es posible cambiar entre Enforcing y Permissive en caliente; pasar a Disabled requiere reinicio y modificar configuración.

setenforce 1   # Enforcing
setenforce 0   # Permissive

Este cambio dura hasta el próximo reinicio.

16.3.3. Configuración persistente

El archivo /et​c/se​linux/co​nfig o /et​c/sys​config/se​linux (en RHEL) define el modo por defecto.

SELINUX=enforcing
SELINUXTYPE=targeted

• SELINUX: puede ser enforcing, permissive, disabled.
• SELINUXTYPE: tipo de política (normalmente targeted o mls).

Tras cambiar a disabled, se requiere reiniciar.

16.4. Contextos de seguridad

Cada archivo, directorio, proceso y recurso (puerto, etc.) tiene un contexto SELinux, que consta de 4 campos:

usuario:rol:tipo:nivel

Ejemplo: system_u:object_r:httpd_sys_content_t:s0

• usuario: identidad SELinux (ej. system_u, unconfined_u).
• rol: define qué tipos puede usar (ej. object_r para archivos, system_r para procesos).
• tipo: la parte más importante para las políticas; determina qué puede hacer (ej. httpd_sys_content_t para contenido web).
• nivel: usado en MLS/MCS; normalmente s0.

16.4.1. Ver contextos de archivos

ls -Z /var/www/html/index.html
# -rw-r--r--. root root system_u:object_r:httpd_sys_content_t:s0 index.html

Para procesos:

ps -eZ | grep httpd
# system_u:system_r:httpd_t:s0    1234 ?        00:00:01 httpd

16.4.2. Cambiar contextos temporales: chcon

chcon (change context) modifica el contexto de un archivo de forma temporal (no sobrevive a una re-etiquetación del sistema).

chcon -t httpd_sys_content_t /var/www/html/index.html

También se puede usar -R para recursivo.

16.4.3. Restaurar contextos por defecto: restorecon

Restaura los contextos según las reglas de la política.

restorecon -v /var/www/html/index.html
restorecon -Rv /var/www/html/

16.4.4. Definir contextos por defecto: semanage fcontext

Para que un cambio de contexto sea persistente, se debe registrar con semanage.

semanage fcontext -a -t httpd_sys_content_t "/web(/.*)?"

Luego aplicar con restorecon.

Este comando requiere el paquete policycoreutils-python-utils (o policycoreutils-python).

16.5. Booleans de SELinux

Los booleans permiten activar o desactivar características de la política sin recompilarla.

• Listar todos: getsebool -a
• Consultar uno: getsebool httpd_can_network_connect
• Cambiar temporalmente: setsebool httpd_can_network_connect on
• Cambiar persistentemente: setsebool -P httpd_can_network_connect on

Ejemplos útiles:

• httpd_can_network_connect: permite a Apache conectar a red (proxy inverso).
• named_write_master_zones: permite a BIND escribir sus zonas.
• nfs_export_all_rw: permite exportar NFS con escritura.

16.6. Gestión de puertos

SELinux restringe los puertos de red que pueden usar los servicios. Por ejemplo, Apache solo puede escuchar en puertos etiquetados como http_port_t (80, 81, 443, 488, 8008, etc.). Si se cambia a un puerto no estándar, hay que añadirlo.

• Listar puertos permitidos para un tipo: semanage port -l | grep http
• Añadir un puerto: semanage port -a -t http_port_t -p tcp 8080
• Eliminar: semanage port -d -t http_port_t -p tcp 8080

16.7. Solución de problemas

Cuando SELinux bloquea algo, se registra en el log de auditoría (/var/log/audit/audit.log o en el journal). Las herramientas de análisis son ausearch y sealert.

ausearch -m avc -ts recent
sealert -a /var/log/audit/audit.log

sealert (del paquete setroubleshoot-server) muestra mensajes amigables con sugerencias de solución, como permitir un boolean, cambiar contexto, etc.

Síntomas típicos:

• Servicio no arranca: revisar systemctl status, journalctl -xe, y los logs de auditoría.
• Apache no puede leer un directorio: verificar contexto (ls -Zd) y ajustar con chcon/semanage fcontext + restorecon.
• Nginx no puede conectar a backend: activar boolean httpd_can_network_connect.

16.8. Estados de SELinux y arranque

El arranque con SELinux disabled puede dejar archivos con contextos incorrectos. Al volver a enforcing, es necesario reetiquetar todo el sistema con:

touch /.autorelabel
reboot

O usar fixfiles -F onboot. Esto puede tardar.

Parte II: AppArmor

16.9. Fundamentos de AppArmor

AppArmor confina programas mediante perfiles que definen a qué archivos, capacidades, red, etc., puede acceder. Un perfil puede estar en dos modos:

• Enforce: aplica las restricciones y registra violaciones.
• Complain: no bloquea, solo registra (útil para depurar).

Los perfiles se almacenan en /et​c/app​armor.d​/ y se cargan en el kernel. El servicio app​armor se gestiona con syste​md.

16.10. Comprobación del estado

aa-status

Muestra cuántos perfiles están cargados, cuántos en enforce, cuántos en complain, y lista los procesos confinados. También se puede ver con sudo aa-status --json para procesamiento.

16.11. Gestión de perfiles

16.11.1. Cambiar modo de un perfil

Estos comandos recargan el perfil.

16.11.2. Deshabilitar un perfil

sudo aa-disable /etc/apparmor.d/usr.sbin.nginx

O usar apparmor_parser -R para descargar.

16.11.3. Cargar/recargar un perfil

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

Para cargar todos: sudo systemctl reload apparmor o sudo apparmor_parser -r /etc/apparmor.d/*.

16.11.4. Generar un perfil nuevo

Se puede usar aa-genprof (herramienta interactiva) o aa-autodep. No es imprescindible para LFCS, pero es bueno conocerlo.

16.12. Sintaxis de un perfil

Un perfil típico:

/us​r/sb​in/ng​inx {
  #include <abstractions/base>
  /et​c/ng​inx/** r,
  /v​ar/l​og/ng​inx/* w,
  /v​ar/ww​w/ht​ml/** r,
  capability net_bind_service,
  deny /et​c/sh​adow r,
}

• Las rutas con comodines (*, **) permiten especificar accesos.
• Permisos: r (lectura), w (escritura), x (ejecución), m (mmap), k (lock), l (link).
• capability permite capacidades específicas (ej. net_bind_service para puertos <1024).
• Se pueden usar #include para abstracciones comunes (red, base, etc.).

16.13. Solución de problemas

Las violaciones se registran en /var/log/syslog (Ubuntu) o /var/log/audit/audit.log (si auditd está activo). Buscar entradas con apparmor="DENIED".

grep apparmor /var/log/syslog | grep DENIED

O usar aa-logprof para analizar el log y proponer modificaciones al perfil (modo interactivo).

Flujo típico: poner el perfil en complain, ejecutar la aplicación para generar accesos, luego usar aa-logprof para actualizar el perfil con las reglas sugeridas y, finalmente, volver a enforce.

16.14. Cambiar el modo global de AppArmor

AppArmor no tiene un “disabled” global; se puede desactivar el servicio en el arranque o descargar todos los perfiles. Para deshabilitar temporalmente todos los perfiles:

sudo aa-teardown

Para recargar todos: sudo systemctl restart apparmor.

16.15. Comparación rápida entre SELinux y AppArmor

16.16. Ejercicios prácticos

SELinux (en un sistema con SELinux)

1. Verificar estado: Ejecuta getenforce y sestatus. Anota el modo actual.

2. Cambiar a permisivo temporalmente: setenforce 0 y verifica con getenforce. Vuelve a enforcing.

3. Contexto incorrecto de Apache: crea un archivo index.html en /var/www/html/ con echo "hola" > /var/www/html/test.html. Verifica su contexto con ls -Z. Si no es httpd_sys_content_t, usa chcon -t httpd_sys_content_t y luego restorecon para ver la diferencia. Cambia la ruta de DocumentRoot de Apache a /web (crea el directorio). Ajusta el contexto con semanage fcontext y restorecon. Comprueba que Apache puede leerlo.

4. Booleans: Lista todos los booleans con getsebool -a. Busca los relacionados con httpd. Activa httpd_can_network_connect de forma persistente y verifica.

5. Puerto no estándar: Configura Apache para escuchar en el puerto 8080 (editando httpd.conf). Intenta iniciar; fallará por SELinux. Consulta los logs con ausearch -m avc -ts recent. Añade el puerto con semanage port -a -t http_port_t -p tcp 8080. Reinicia Apache y verifica.

AppArmor (en un sistema con AppArmor)

1. Estado actual: Ejecuta sudo aa-status y anota perfiles en enforce/complain.

3. **Deshabilitar un perfil**: Deshabilita el perfil de `nginx` con `aa-disable`. Comprueba que el proceso queda sin confinar. Vuelve a habilitarlo con `apparmor_parser -r`.

5. Solución de problemas: Con un perfil en complain, genera una violación (ej. intenta acceder a un archivo no permitido). Busca en /var/log/syslog las líneas apparmor="DENIED". Si usas aa-logprof, intenta que proponga modificaciones.

16.17. Resumen y consejos para LFCS

• En el examen, podrías enfrentarte a cualquiera de los dos sistemas dependiendo de la distribución.
• Para SELinux: memoriza getenforce, setenforce, semanage fcontext, restorecon, getsebool, setsebool, semanage port. Entiende los contextos.
• Para AppArmor: conoce aa-status, aa-enforce, aa-complain, aa-disable, apparmor_parser, y la ubicación de perfiles.
• La resolución de problemas suele implicar revisar logs (ausearch, grep apparmor) y aplicar la solución sugerida (cambiar contexto, activar boolean, modificar perfil).
• Recuerda que estos sistemas añaden restricciones; a menudo el error “Permission denied” no se resuelve con chmod sino ajustando SELinux/AppArmor.
• Practica en ambos entornos, aunque te centres en uno. El conocimiento conceptual es transferible.

Con este capítulo has aprendido a controlar el acceso obligatorio, una capa de seguridad esencial. En el próximo tema nos adentraremos en las Listas de Control de Acceso (ACLs) y cuotas de disco, que complementan los permisos tradicionales y limitan el uso de almacenamiento.