Capabilities: por qué root es demasiado

1Por qué importa

Cada vez que un proceso corre como root "para una cosa", el alcance de cualquier fallo suyo es la máquina entera. Un servidor que corre como root y sufre una inyección de comandos no da al atacante "acceso al servidor": da root. La causa suele ser trivial —necesitaba escuchar en un puerto por debajo de 1024, o ajustar una prioridad, o abrir un socket especial— y para eso se le concedió todo. Es el opuesto exacto del mínimo privilegio.

Las capabilities existen para romper esa disyuntiva entre "root" y "nada". El poder de root no es una cosa indivisible: es un conjunto de permisos concretos que el kernel comprueba por separado. Reservar un puerto bajo es CAP_NET_BIND_SERVICE. Saltarse los permisos de archivo es CAP_DAC_OVERRIDE. Cambiar el dueño de un archivo es CAP_CHOWN. Si el proceso solo necesita una, se le da una y se le niegan las demás. El fallo, cuando ocurra, tendrá el alcance de esa única capability, no el de root. Esta es la herramienta con la que se convierte "corre como root" en "corre casi sin privilegios, salvo exactamente lo que necesita".

2Conceptos

3Explicación profunda

Históricamente, el kernel decidía si una operación privilegiada estaba permitida con una única pregunta: ¿el proceso tiene UID 0 (root)? Todo o nada. Las capabilities cambiaron esa pregunta por muchas preguntas pequeñas. Hoy hay unas cuarenta capabilities, y para cada operación privilegiada el kernel comprueba una en concreto. Reservar el puerto 80 no pregunta "¿eres root?", pregunta "¿tienes CAP_NET_BIND_SERVICE?". Ser root, en la práctica, no es más que tener todas las capabilities a la vez; darlas una a una es lo que permite el mínimo privilegio.

El ejemplo canónico es el puerto privilegiado. Por diseño, los puertos por debajo de 1024 solo los puede abrir un proceso con CAP_NET_BIND_SERVICE, porque escuchar en ellos es hacerse pasar por un servicio de sistema (un servidor en el 80 es "el web de la máquina"). La gente resuelve esto corriendo el servidor como root, que tiene esa capability... junto con todas las demás. La solución correcta es dar solo CAP_NET_BIND_SERVICE: el proceso escucha en el 80 sin ser root, y no puede leer archivos que no le tocan, ni montar, ni cambiar dueños. Si lo comprometen, el atacante gana la capacidad de abrir puertos bajos, que es casi nada, en lugar de root.

No todas las capabilities son igual de acotadas, y aquí está el matiz importante. CAP_NET_BIND_SERVICE hace una cosa. CAP_SYS_ADMIN, en cambio, es un cajón de sastre: agrupa tantas operaciones privilegiadas —montar sistemas de archivos, cambiar espacios de nombres, y decenas más— que concederla es casi tan peligroso como dar root completo, porque desde varias de esas operaciones se llega a root de todas formas. La regla práctica es doble: da la capability más pequeña que resuelva la tarea, y desconfía de CAP_SYS_ADMIN, CAP_DAC_OVERRIDE, CAP_SYS_PTRACE y CAP_SYS_MODULE, que abren caminos amplios.

Las capabilities también se ponen sobre binarios, y ahí sustituyen al SUID de forma más segura. En la lección de permisos viste que un binario SUID root corre con todo el poder de root, y que ese exceso es el problema. Con setcap 'cap_net_bind_service=+ep' /usr/bin/miservidor, el binario obtiene solo esa capability al ejecutarse, no root entero. Es la versión moderna y acotada de "necesita privilegios para una cosa": en vez de prestar toda la identidad de root (SUID), presta el permiso exacto. En contenedores, Docker expone lo mismo con cap_drop y cap_add: lo correcto es cap_drop: ALL y luego cap_add solo de lo que el servicio use.

4Ejemplo sencillo

# Un llavero maestro contra una sola llave

"Ser root" es entregar el LLAVERO MAESTRO del edificio para que
alguien pueda abrir UNA puerta. Si pierde el llavero (lo comprometen),
quien lo encuentre abre TODAS las puertas.

Una capability es entregar SOLO la llave de esa puerta. El del
puerto 80 recibe la llave "abrir puertas de recepcion" (CAP_NET_BIND_
SERVICE) y ninguna mas. Si la pierde, el que la encuentre abre la
recepcion... y se queda ahi. Ni el almacen, ni la caja fuerte.

Mismo trabajo hecho. Muchisimo menos que perder si algo sale mal.

5Ejemplo técnico

Algunas capabilities y para qué sirven, con su nivel de riesgo si se conceden de más:

Los comandos para leer y conceder capabilities. El primero mira las de un proceso; el segundo, las de un binario; el tercero pone la capability justa sobre un binario:

# capabilities del proceso con PID dado
getpcaps <pid>

# capabilities puestas sobre un binario (alternativa al SUID)
getcap /usr/bin/miservidor

# conceder SOLO la de puerto bajo a un binario, sin SUID root
setcap 'cap_net_bind_service=+ep' /usr/bin/miservidor

6Diagrama

flowchart LR
    R[servidor como root] --> B[escucha en :80]
    C[servidor + NET_BIND_SERVICE] --> B
    R --> XR[compromiso = root · toda la máquina]
    C --> XC[compromiso = solo puertos bajos]

7Código

En un contenedor, el mínimo privilegio con capabilities se escribe como cap_drop: ALL y luego el cap_add justo. El servicio corre sin ser root y sin ninguna capability salvo la que usa:

# docker-compose.yml — un servidor web en el puerto 80, sin root
services:
  web:
    image: mi-servidor
    user: "1000:1000"          # no root dentro del contenedor
    cap_drop:
      - ALL                    # quita TODAS las capabilities
    cap_add:
      - NET_BIND_SERVICE       # devuelve solo la del puerto bajo

Fuera de contenedores, la misma idea sobre el binario evita el SUID root. En vez de prestar toda la identidad de root, presta la capability exacta:

# en vez de: chmod u+s /usr/bin/miservidor  (SUID root: demasiado)
setcap 'cap_net_bind_service=+ep' /usr/bin/miservidor
getcap /usr/bin/miservidor     # verifica: solo cap_net_bind_service

La comprobación siempre es la misma: el servicio hace su tarea (escucha en el 80) y, si intentas con él una operación privilegiada distinta (leer /etc/shadow, por ejemplo), falla. Un mínimo privilegio que no se verifica es una suposición.

8Qué puede salir mal

9Cómo lo abusaría un atacante

10Cómo defenderlo

11Laboratorio

12Ejercicios

services:
  web:
    image: mi-servidor
    user: "1000:1000"
    cap_drop: [ALL]
    cap_add: [NET_BIND_SERVICE]

# 1) hace su tarea:
docker compose logs con-cap | grep "escuchando en el puerto 80"

# 2) NO puede otra operacion privilegiada (dentro del contenedor):
docker compose exec con-cap sh -c \
  'chown 0:0 /etc/hostname 2>&1 || echo "OK: sin CAP_CHOWN"'

13Preguntas de comprensión

14Reto adicional

15Resumen

16Mis notas

17Recursos