Namespaces, cgroups, seccomp y AppArmor

1Por qué importa

Reducir privilegio con capabilities es necesario, pero no basta. Un proceso con pocas capabilities todavía ve todos los demás procesos, puede consumir toda la memoria de la máquina, puede invocar cualquier syscall del kernel y puede tocar cualquier archivo que sus permisos le permitan. Cada una de esas cuatro cosas es una superficie distinta, y para cada una hay un mecanismo de confinamiento independiente. Confinar de verdad es usarlos juntos.

Esta es la defensa en profundidad aplicada a un solo proceso. Un fallo en el servicio no debe poder ver los secretos de otro proceso (namespaces), ni tumbar la máquina agotando memoria (cgroups), ni invocar la syscall que necesita un exploit del kernel (seccomp), ni leer un archivo que su política no contempla (AppArmor o SELinux). Ninguno de estos mecanismos evita el fallo de la aplicación; todos reducen lo que ese fallo alcanza. Y todos existen ya en el kernel: son exactamente las piezas con las que un contenedor está construido, aunque casi nadie las mira una a una.

2Conceptos

3Explicación profunda

Los namespaces controlan lo que un proceso ve. El kernel mantiene varios tipos, y cada uno aísla una clase de recurso. Con un PID namespace propio, un proceso solo ve los procesos de su namespace: para él, el resto de la máquina no existe, y no puede enviarles señales ni leer su /proc. Con un network namespace tiene su propia pila de red, sus interfaces y sus puertos, separados de los del host. Con un mount namespace tiene su propia vista del árbol de archivos, y puede ver un sistema de ficheros por completo distinto. El user namespace es el más sutil y el más potente para seguridad: permite que un proceso sea "root" dentro de su namespace mientras es un usuario sin privilegios fuera, de modo que su root no vale nada en el host. Los namespaces son la razón por la que un contenedor parece una máquina aparte sin serlo.

Los cgroups (control groups) controlan lo que un proceso consume. Agrupan procesos y les ponen límites: tanta CPU, tanta memoria, tanto ancho de banda de disco. Su valor de seguridad es contener el abuso de recursos, que es una forma de denegación de servicio: un proceso comprometido que intenta agotar la memoria de la máquina —para tumbarla o para provocar comportamientos raros bajo presión— choca con el límite de su cgroup y solo se perjudica a sí mismo. Sin cgroups, un solo proceso puede dejar sin recursos a todos los demás.

seccomp (secure computing) controla lo que un proceso le puede pedir al kernel. Toda interacción de un programa con el sistema pasa por una syscall: abrir un archivo, crear un proceso, montar, cambiar permisos. Un perfil seccomp es una lista blanca (o negra) de syscalls: las permitidas pasan, las prohibidas devuelven un error o matan el proceso. Esto importa muchísimo porque la superficie de ataque del kernel son sus syscalls: muchos exploits de escalada necesitan invocar una syscall concreta y rara. Un perfil que bloquea las syscalls que el servicio no usa —montar, cargar módulos, manipular namespaces— cierra esos exploits aunque el servicio tenga un fallo. Docker aplica por defecto un perfil seccomp que ya bloquea decenas de syscalls peligrosas; endurecerlo es acotarlo aún más a lo que el servicio usa.

AppArmor y SELinux añaden el cuarto eje: el control de acceso obligatorio (MAC). Los permisos de usuario que viste en la lección de permisos son control de acceso discrecional: el dueño de un archivo decide quién accede. El MAC pone por encima una política del sistema que el dueño no puede saltarse: aunque los permisos permitan a un proceso abrir un archivo, si la política de AppArmor de ese proceso no lo contempla, el acceso se deniega. Esto acota un servicio a un perfil explícito: "este proceso solo puede leer estos directorios, escribir en estos otros y abrir estos sockets". AppArmor lo hace por rutas y es más sencillo; SELinux lo hace por etiquetas y es más potente y más complejo. Los dos persiguen lo mismo: que un proceso comprometido, aunque tenga los permisos de usuario, no pueda salirse del guion que su política le fija.

4Ejemplo sencillo

# Un trabajador temporal en una oficina bien organizada

VISTA (namespaces): le dan un despacho desde el que no ve el resto de
la empresa. Para el, la oficina ES su despacho; no sabe que hay mas.

RECURSOS (cgroups): tiene un enchufe con un limite de consumo. Puede
trabajar, pero no puede fundir los plomos de todo el edificio.

PETICIONES (seccomp): solo puede pedir por una lista corta de
formularios. Si intenta pedir "las llaves del edificio", no hay
formulario para eso: la peticion se rechaza en recepcion.

POLITICA (AppArmor/SELinux): un reglamento firmado dice a que salas
puede entrar, aunque tuviera la tarjeta para mas. La tarjeta abre;
el reglamento decide.

5Ejemplo técnico

Los cuatro ejes, qué confinan y con qué se aplican en un contenedor:

Un fragmento de perfil seccomp que niega la familia chmod: por defecto permite todo, pero esa syscall devuelve error. Es la forma de cerrar una operación concreta a un proceso, aunque sus permisos se lo permitieran:

// seccomp: permitir todo salvo cambiar permisos
{
  "defaultAction": "SCMP_ACT_ALLOW",
  "syscalls": [
    { "names": ["chmod", "fchmod", "fchmodat"],
      "action": "SCMP_ACT_ERRNO" }
  ]
}

6Diagrama

flowchart LR
    P[proceso confinado] --> N[namespaces · qué ve]
    P --> C[cgroups · cuánto consume]
    P --> S[seccomp · qué syscalls]
    P --> A[AppArmor/SELinux · política]
    N & C & S & A --> D[daño de un compromiso · recortado]

7Código

En un compose, los cuatro ejes más las capabilities se declaran juntos. Este servicio corre sin root, con memoria y procesos limitados, un perfil seccomp propio, la raíz de solo lectura y sin posibilidad de ganar privilegios:

# docker-compose.yml — un servicio confinado en los cuatro ejes
services:
  web:
    image: mi-servidor
    user: "1000:1000"            # namespace de usuario: no root
    read_only: true                # mount: raíz de solo lectura
    mem_limit: 256m                # cgroup: tope de memoria
    pids_limit: 128                # cgroup: tope de procesos
    cap_drop: [ALL]                # capabilities: ninguna de más
    cap_add: [NET_BIND_SERVICE]    # solo la que usa
    security_opt:
      - no-new-privileges:true     # no puede escalar
      - seccomp=perfil.json        # seccomp: syscalls acotadas

Cada línea cierra un eje distinto, y el efecto se suma. Un atacante que comprometa este servicio se encuentra sin root, sin poder ver otros procesos, sin poder agotar la máquina, sin las syscalls que necesitaría para un exploit del kernel y con la raíz de solo lectura. El fallo sigue existiendo; su alcance es minúsculo.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

services:
  web:
    image: mi-servidor
    user: "1000:1000"
    read_only: true
    mem_limit: 256m
    pids_limit: 128
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
      - seccomp=perfil.json

# ambos deben fallar; el proceso sigue vivo
docker compose exec con-seccomp sh -c \
  'chmod 777 /etc/hostname 2>&1; unshare -U 2>&1; echo "servicio vivo"'

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos