Cerramos el módulo 4 con tres suposiciones colgando en el aire: que el UID 990 es meteora, que quien inicia sesión es quien dice ser, y que un proceso que corre como meteora hace lo que meteora haría. Las dos primeras las resolveremos en la siguiente lección. Esta se dedica entera a la tercera, que es la más incómoda de las tres, porque es la que sigue siendo falsa aunque todos los permisos estén perfectos.

Piénsalo así. meteo-api tiene exactamente los permisos que necesita: lee /var/lib/meteora/lecturas/*.dat, lee /etc/meteora/meteora.conf, escribe en /var/log/meteora/meteo-api.log. Ni uno más. Ahora imagina que alguien encuentra un fallo en el código que analiza las peticiones HTTP y consigue que el proceso ejecute instrucciones suyas. Ese atacante hereda el proceso entero, con sus permisos intactos. Y con esos permisos —los correctos, los mínimos, los que aprobó la revisión de seguridad— puede abrir un socket a Internet, leer las 17.280.000 líneas de datos del día, ejecutar /bin/sh, crear un proceso hijo que sobreviva al reinicio del servicio y montar /dev/md0 en otro sitio si el núcleo se lo permite. Los nueve bits no dijeron nada sobre nada de eso, porque los nueve bits solo hablan de ficheros.

Esta lección construye el marco conceptual que falta. Primero la teoría, que es sorprendentemente pequeña y explica todo lo demás: sujetos, objetos, derechos, dominios y la matriz de acceso. Después los ocho principios de diseño que en 1975 fijaron el vocabulario de la seguridad de sistemas y que siguen siendo la mejor lista de comprobación que existe. Después los cuatro modelos de control de acceso que verás nombrados en cualquier documento profesional —DAC, MAC, RBAC, ABAC—. Y por último los tres mecanismos con los que Linux implementa hoy esas ideas: capabilities, que trocean el poder de root; SELinux y AppArmor, que imponen reglas que ni root puede saltarse; y seccomp, que reduce el juego de llamadas al sistema que un proceso puede siquiera intentar. Al final tendrás la respuesta a la pregunta del párrafo anterior: qué se le pone delante a un meteo-api comprometido para que sus permisos correctos no basten.

1. Protección frente a seguridad: por qué la distinción importa
2. El modelo formal: sujetos, objetos, derechos y dominios de protección
3. La matriz de acceso y sus dos implementaciones reales
4. Los ocho principios de Saltzer y Schroeder, aplicados a Meteora
5. Modelos de control de acceso: DAC, MAC, RBAC y ABAC
6. El problema del "todo o nada" de root
7. Capabilities de Linux: trocear el poder de root
8. Control de acceso obligatorio: SELinux y AppArmor
9. Confinamiento y sandboxing: seccomp y la superficie de syscalls
10. Base de cómputo confiable y superficie de ataque
11. El problema del delegado confuso

En el lenguaje corriente son sinónimos. En sistemas operativos son dos cosas distintas y conviene separarlas desde el principio, porque determinan qué puedes esperar de un mecanismo.

La distinción no es académica; tiene una consecuencia práctica muy concreta. La protección se puede razonar y demostrar; la seguridad, no. Puedes afirmar con certeza que un proceso con UID 990 no puede escribir en un fichero root:root 0644, porque es una regla del núcleo. No puedes afirmar con la misma certeza que los datos de Meteora están seguros, porque eso depende de todo el sistema y de un adversario del que solo tienes hipótesis.

De ahí sale la regla de trabajo del módulo entero:

Un mecanismo de protección nunca es una solución de seguridad; es una capa. La seguridad se construye apilando capas independientes, de modo que el fallo de una no anule a las demás. Es lo que se llama defensa en profundidad.

Los permisos de 04-06 son una capa. Las capabilities son otra. AppArmor es otra. Seccomp otra. Ninguna es suficiente sola, y precisamente por eso ninguna es inútil.

Todo control de acceso, en cualquier sistema operativo, se describe con cuatro conceptos. Aprenderlos ahorra mucho tiempo después, porque cada mecanismo concreto no es más que una implementación particular de este esquema.

Sujeto. La entidad activa que quiere hacer algo. En Linux, el sujeto real es el proceso, no el usuario: el usuario es una etiqueta que el proceso lleva encima. Cuando el agregador abre un fichero, el sujeto es ese proceso concreto con su PID, su UID efectivo 990, sus grupos suplementarios, sus capabilities y su etiqueta de SELinux.

Objeto. La entidad pasiva sobre la que se actúa. En un sistema UNIX la lista es larga y no se limita a ficheros: ficheros y directorios, procesos (se les envían señales), sockets, segmentos de memoria compartida como /dev/shm/meteora-cache, dispositivos, semáforos, colas de mensajes, entradas de /proc, y hasta el propio reloj del sistema o la tabla de rutas.

Derecho de acceso. El permiso para ejecutar una operación concreta sobre un objeto concreto: leer, escribir, ejecutar, borrar, enviar una señal, montar, conectar. El conjunto de derechos depende del tipo de objeto.

Dominio de protección. Es el concepto que suele costar y el que más rendimiento da. Un dominio es el conjunto de pares (objeto, derechos) que un sujeto puede usar en un momento dado. Es decir: no "quién eres", sino "qué puedes hacer ahora mismo".

Lo importante es que un proceso cambia de dominio a lo largo de su vida, y esos cambios son la parte interesante de la seguridad. Recuerda el caso de passwd de 04-06: el proceso empieza en el dominio del usuario joan, y al hacer execve sobre un binario setuid salta al dominio de root. Eso es un cambio de dominio, y es exactamente donde se concentran los ataques: si consigues provocar un cambio de dominio que no estaba previsto, has escalado privilegios.

En Linux, un dominio se define de facto por la combinación de: UID y GID efectivos, grupos suplementarios, conjunto de capabilities, etiqueta de SELinux o perfil de AppArmor, filtro seccomp activo, límites de recursos y —desde el módulo 6— espacios de nombres. Todo lo que veremos a partir de aquí es una forma de hacer los dominios más pequeños y controlar mejor los saltos entre ellos.

Si pones los sujetos en filas y los objetos en columnas, obtienes la matriz de acceso, que es la representación completa y abstracta de la política de protección de un sistema:

La matriz es un modelo excelente para pensar y un desastre para implementar: con 500 usuarios y 200.000 ficheros tendría 100 millones de celdas, casi todas vacías. Ningún sistema real la almacena entera. Todos la trocean, y solo hay dos formas de trocear una matriz.

Por columnas: listas de control de acceso (ACL). Cada objeto guarda quién puede hacer qué con él. Es lo que hacen los nueve bits de UNIX (una ACL comprimida de tres entradas) y las ACL POSIX de 04-06 (una lista de verdad). La lista vive con el objeto, en su inodo.

Por filas: listas de capacidades (capability lists). Cada sujeto lleva encima una lista de "llaves", y cada llave nombra un objeto y los derechos sobre él. La llave viaja con el sujeto; el objeto no sabe quién la tiene.

Y aquí una revelación que ordena todo lo aprendido: los descriptores de fichero de 04-04 son capacidades. Cuando open() te devuelve el descriptor 3, el núcleo te ha entregado una llave: un testigo no falsificable —no puedes inventarte un descriptor válido— que concede unos derechos concretos sobre un objeto concreto. Por eso los permisos se comprueban en open() y no en read(): la comprobación ocurre al fabricar la llave, no al usarla. Y por eso un chmod 000 posterior no corta a quien ya la tiene. Es exactamente el comportamiento característico de un sistema de capacidades, y ahora ya sabes por qué es así.

La comparación completa:

Los dos riesgos característicos merecen un comentario, porque los verás en la vida real. En el mundo ACL, el problema es la acumulación: nadie retira permisos, la lista de acceso a una carpeta compartida acaba con treinta entradas y grupos anidados, y ya nadie sabe quién entra. En el mundo capacidades, el problema es la fuga: si meteo-api hereda por descuido un descriptor abierto de /etc/meteora/meteora.conf que su padre dejó abierto, tiene la llave aunque los permisos del fichero se lo prohibieran. Por eso execve cierra los descriptores marcados con FD_CLOEXEC, y por eso conviene abrir con O_CLOEXEC por defecto (04-04): es higiene de capacidades.

Un aviso de vocabulario, para que no te confundas más adelante: las capabilities de Linux del apartado 7 se llaman así por herencia histórica, pero no son capacidades en este sentido. No nombran un objeto concreto; son permisos globales de tipo "puede hacer X en todo el sistema". Es una desafortunada colisión de nombres que conviene tener presente.

En 1975, Jerome Saltzer y Michael Schroeder publicaron ocho principios de diseño de sistemas protegidos. Medio siglo después no ha hecho falta añadir ninguno, y la mayoría de los desastres de seguridad que leerás en las noticias son la violación de uno de ellos. Los recorremos uno a uno, con su aplicación exacta en meteo-01.

Cada sujeto debe operar con el conjunto mínimo de privilegios necesario para su tarea, y durante el mínimo tiempo.

Es el principio del que se derivan casi todos los demás. En Meteora se traduce en decisiones concretas que ya hemos tomado: meteora es una cuenta sin shell (nadie inicia sesión con ella), /etc/meteora/meteora.conf pertenece a root y el servicio solo lo lee, /usr/bin/meteo-api pertenece a root para que el servicio no pueda reescribir su propio binario, y meteo-api escucha en el 8080 para no necesitar privilegios de puerto bajo. Y el que veremos en el apartado 7: si tuviera que escuchar en el 443, la respuesta correcta es CAP_NET_BIND_SERVICE, no root.

La coletilla "y durante el mínimo tiempo" es la que más se olvida. Un proceso que necesita privilegio solo al arrancar debe soltarlo después: abrir el puerto, abrir los ficheros, y entonces bajar a UID 990 y descartar las capabilities. A partir de ese instante, un compromiso ya no las tiene.

El mecanismo de protección debe ser lo más pequeño y simple posible, para poder revisarlo exhaustivamente.

El código que no existe no tiene fallos, y el código que nadie entiende no se puede auditar. Es el argumento a favor de los nueve bits de UNIX frente a una ACL de treinta entradas heredadas: un mecanismo comprensible se verifica de un vistazo. En Meteora, aplicarlo significa preferir un perfil de AppArmor de cuarenta líneas que un equipo entero entiende a una política de SELinux de seiscientas que solo entiende quien la escribió —y que acabará en modo permisivo el día que estorbe—.

Lo permitido debe listarse explícitamente; todo lo demás se deniega. La base debe ser la falta de acceso, no su presencia.

La diferencia entre una lista negra ("prohíbe estas rutas") y una lista blanca ("permite solo estas") es que la primera falla en silencio ante todo lo que sus autores no imaginaron. Aplicado a Meteora, es lo que hace other::--- en los datos, lo que hace la política por defecto drop del cortafuegos que montaremos en 05-03, y lo que hace un perfil de AppArmor: enumera lo que meteo-api puede tocar y deniega el resto del sistema de ficheros, incluido lo que se instale mañana.

Todo acceso a todo objeto debe comprobarse, siempre, sin excepciones ni cachés que se puedan saltar.

Si el mecanismo comprueba el permiso la primera vez y luego confía, existe una ventana. Es el punto donde los descriptores de fichero de UNIX hacen una concesión deliberada: se comprueba en open() y no en cada read(), por rendimiento. La concesión está estudiada —la llave solo se entrega si el permiso existía— pero explica el efecto del chmod 000 que no corta a nadie. Y el ataque contra la mediación completa tiene nombre y ya lo conoces: TOCTOU (04-04), donde el atacante cambia el objeto entre la comprobación y el uso. La contramedida es siempre la misma: comprobar y actuar sobre el mismo descriptor, no sobre el mismo nombre.

La seguridad no debe depender del secreto del diseño, sino del secreto de las claves.

Es el principio de Kerckhoffs, y explica por qué el algoritmo de cifrado de contraseñas de /etc/shadow está publicado hasta el último detalle y aun así el sistema funciona. Su contrario es la seguridad por oscuridad: mover SSH al puerto 2222, ofuscar el código, esconder la URL de administración. No son inútiles como ruido —quitan escaneos automáticos de encima—, pero no son un control de seguridad, porque su valor desaparece en cuanto alguien mira. Regla operativa para Meteora: cambiar el puerto de SSH está bien; hacerlo en lugar de configurar claves públicas y fail2ban está mal.

Cuando sea posible, exigir dos condiciones independientes para conceder un acceso, en vez de una sola.

Dos llaves para lanzar el misil. Dos firmas para una transferencia. En Meteora, es la razón de que los registros tengan grupo adm y no meteora: administrar y ejecutar son dos privilegios distintos y no se los damos a la misma identidad. También es la razón de dividir el servicio en tres procesos (ingestor, agregador, meteo-api) en lugar de uno solo: comprometer el que habla con Internet no da lo que puede hacer el que escribe en disco. Y es lo que hace la autenticación en dos factores de 05-02.

Minimizar los mecanismos compartidos entre usuarios, porque cada recurso compartido es un canal potencial de fuga o de interferencia.

Todo lo que dos sujetos comparten es una vía por la que uno puede afectar o espiar al otro: un /tmp común, una base de datos común, una CPU con caché común —de ahí ataques como Spectre—, un segmento de memoria compartida. En Meteora, /dev/shm/meteora-cache es exactamente un mecanismo común entre los tres procesos, y por eso sus permisos y su tamaño importan tanto: es superficie compartida. La directiva PrivateTmp=yes de systemd (05-03) es este principio hecho configuración: cada servicio recibe su propio /tmp.

El mecanismo debe ser fácil de usar correctamente, o los usuarios lo esquivarán.

Es el principio más ignorado y el que más brechas causa. Una política que obliga a cambiar la contraseña cada 30 días produce Meteora2026! seguido de Meteora2026!!, y post-its. Un sudo que pide la contraseña cada treinta segundos produce un NOPASSWD: ALL. Un perfil de AppArmor que rompe el servicio cada vez que se despliega una versión produce aa-complain permanente. Un control que estorba se desactiva, y un control desactivado protege cero. Cuando diseñes seguridad para Meteora, pregúntate siempre cuál es el camino fácil, y asegúrate de que el camino fácil sea el seguro.

Con el vocabulario en la mano, ya se pueden nombrar los cuatro modelos que estructuran el control de acceso en cualquier sistema profesional.

La clave para entender por qué existe MAC está en la casilla "punto débil" de DAC, y merece un ejemplo concreto:

Con DAC, meteo-api corre como meteora y meteora es el dueño de los .dat. Si un atacante controla el proceso, puede hacer chmod o+r sobre los datos, o copiarlos a /tmp, o enviarlos por un socket. Tiene la discreción del dueño, porque es el dueño.

Con MAC, existe además una política del sistema que dice: "un proceso etiquetado meteo_api_t puede leer ficheros etiquetados meteora_data_t y nada más; no puede escribir en /tmp, no puede ejecutar /bin/sh, no puede abrir sockets salientes". Esa regla no la puede cambiar el proceso, ni siquiera si consigue UID 0, porque no la aplica el dueño del fichero sino el núcleo con su política cargada.

Esa es toda la diferencia, y es la razón por la que el módulo no termina en 04-06. En la práctica, un servidor Linux moderno combina los cuatro: DAC en los permisos de fichero, MAC en AppArmor o SELinux, RBAC en la organización de grupos y reglas de sudo, y ABAC en las políticas de la nube que lo rodean.

UNIX nació con un modelo de privilegio binario: UID 0 lo puede todo, cualquier otro UID no puede nada especial. El núcleo estaba lleno de comprobaciones de la forma if (uid == 0) permitir;. Es de una economía de mecanismo admirable, y es también un problema serio.

El problema se ve con un ejemplo cotidiano. ping necesita abrir un socket ICMP en bruto, algo que un usuario normal no puede hacer. La solución clásica fue hacerlo setuid root. Resultado: un programa que cualquiera puede ejecutar, que corre con todos los privilegios del sistema, cuando lo único que necesitaba era uno. Si ping tiene un fallo, el atacante no obtiene "la capacidad de mandar paquetes ICMP": obtiene la máquina entera. La desproporción entre el privilegio necesario y el privilegio concedido es de varios órdenes de magnitud, y es una violación de manual del principio de mínimo privilegio.

Multiplica eso por los quince o veinte binarios setuid de un sistema y tendrás la superficie de ataque histórica de UNIX. La solución de Linux desde 1998 es trocear el poder de root en piezas.

Linux divide los privilegios de root en unas cuarenta capabilities independientes. Cada comprobación del núcleo que antes decía "¿es UID 0?" ahora dice "¿tiene la capability tal?".

Las cuatro últimas están marcadas por una razón. CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE y CAP_DAC_OVERRIDE equivalen prácticamente a root, y hay que tratarlas como tal:

• CAP_SYS_MODULE: si puedes cargar un módulo, puedes ejecutar código en el núcleo. Es más que root.
• CAP_SYS_PTRACE: si puedes inspeccionar y modificar la memoria de otros procesos, puedes tomar el control de un proceso privilegiado.
• CAP_DAC_OVERRIDE: si te saltas todos los permisos de fichero, puedes reescribir /etc/shadow y /etc/sudoers.
• CAP_SYS_ADMIN: se convirtió en el cajón donde se metió todo lo que no encajaba en otra categoría, y hoy cubre montar sistemas de ficheros, manipular namespaces y mucho más. Concederla es, en la práctica, conceder root con pasos intermedios.

Cada proceso lleva varios conjuntos de capabilities. Los que hay que entender son estos:

La lógica de uso es sencilla y sigue el principio de mínimo privilegio en el tiempo: un servicio arranca con lo permitido, activa en el efectivo solo lo que necesita en el instante en que lo necesita, y vacía el limitador de todo lo demás para que ni él ni ninguno de sus hijos pueda recuperarlo nunca. Ese vaciado es lo que hace CapabilityBoundingSet= en una unidad de systemd (05-03).

Qué ha pasado exactamente. setcap escribe un atributo extendido security.capability en el inodo del binario —los xattr de 04-06—, y al ejecutarlo el núcleo le concede esa capability y solo esa. El proceso corre como UID 990, sin ningún privilegio de root, salvo la capacidad puntual de asociarse a un puerto bajo. Compáralo con la alternativa clásica —chmod u+s y root—: el privilegio concedido pasa de "todo el sistema" a "una operación". capsh --decode traduce la máscara hexadecimal de /proc/<pid>/status a nombres legibles, y CapBnd con todos los bits a uno indica que el limitador está intacto, algo que en un servicio bien configurado no debería ocurrir.

Hay una opción B mejor que la A, y conviene conocerla ya aunque la desarrollemos en 05-03: en lugar de marcar el fichero, se pide la capability en la unidad de systemd:

Es superior por tres razones. El binario del disco no queda marcado, así que copiarlo a otro sitio no arrastra privilegio. El limitador se reduce a esa única capability, de modo que ni el proceso ni sus hijos pueden obtener ninguna otra jamás. Y NoNewPrivileges=yes impide cualquier ganancia de privilegio posterior, incluido el efecto de cualquier binario setuid que el proceso ejecute.

Igual que la lista de binarios setuid de 04-06, la lista de binarios con capabilities es un inventario que hay que conocer y comparar periódicamente. Un binario con cap_dac_override o cap_sys_admin aparecido de la nada es una alarma tan roja como un setuid root nuevo, y llama menos la atención porque ls -l no lo muestra: no hay ninguna s que delate el privilegio. Solo aparece con getcap.

Volvamos al escenario del principio. meteo-api está comprometido, corre como meteora, y todos los permisos son correctos. Con DAC puede: leer todos los .dat, escribir en /tmp, ejecutar /bin/sh, abrir un socket a Internet y enviarse los datos. Nada de eso viola un solo bit de permiso.

El control de acceso obligatorio añade una segunda comprobación, después de la de DAC y completamente independiente de ella:

La propiedad clave está en el diagrama: hay que pasar las dos. DAC puede permitir y MAC denegar; MAC nunca concede lo que DAC deniega. Y la política de MAC la fija el administrador del sistema, no el dueño del fichero, así que un proceso con UID 0 tampoco se la salta.

Las dos implementaciones habituales en Linux:

Como meteo-01 es Debian, el ejemplo natural es AppArmor. Así se ve el esqueleto de un perfil para meteo-api —incompleto a propósito, porque escribir una política completa no es el objeto de esta lección—:

Lee el perfil con atención, porque cada línea es una decisión. Las reglas son una lista blanca: lo que no aparece está denegado, incluido cualquier fichero que se instale mañana —principio 3, valores por defecto seguros—. meteora.conf es r y no rw, de modo que el proceso no puede reescribir su propia configuración aunque los permisos DAC se estropeen algún día. El registro es aw (append), la versión MAC del chattr +a de 04-06. Y lo decisivo es lo que no hay: ninguna regla de ejecución. Un meteo-api comprometido no puede lanzar /bin/sh, ni curl, ni python3, porque AppArmor deniega el execve de todo lo que no esté listado. Eso rompe la mayoría de las cadenas de ataque automatizadas, que dan por hecho que tras el fallo hay una shell.

El flujo de trabajo realista para llegar a un perfil así, sin romper producción:

El orden importa y es la aplicación práctica del principio de aceptabilidad psicológica: se empieza en modo queja, que registra sin bloquear, se observa varios días con tráfico real —incluido el cierre de mes, la rotación de logs y el despliegue de una versión— y solo entonces se pasa a obligatorio. Un perfil escrito de golpe y activado en producción rompe el servicio, y un servicio roto por seguridad se desactiva en veinte minutos y no vuelve.

Queda una capa más, y es la más profunda. En 01-06 vimos que todo lo que un proceso puede pedirle al sistema pasa por una llamada al sistema: unas 350 en Linux x86-64. Esa es, literalmente, la superficie completa de interacción entre un programa y el núcleo.

Ahora hazte la pregunta: ¿cuántas de esas 350 necesita el ingestor? Recibe lecturas por un socket, las valida y las escribe en un fichero. Su lista real ronda las cuarenta: read, write, openat, close, accept4, recvfrom, fsync, clock_gettime, mmap, exit_group y poco más. Las 310 restantes —mount, ptrace, init_module, keyctl, bpf, kexec_load, execve…— no las usa jamás, pero están disponibles, y cada una es superficie de ataque: código del núcleo que un proceso comprometido puede intentar alcanzar, incluidos los fallos del propio núcleo.

seccomp (secure computing mode) resuelve eso permitiendo que un proceso renuncie voluntaria e irreversiblemente a un conjunto de llamadas al sistema. A partir de ese momento, cualquier intento de usarlas termina con EPERM, con SIGSYS o con la muerte del proceso, según se configure. La renuncia es irreversible —un proceso no puede quitarse su propio filtro— y se hereda por fork y execve, así que ninguna shell lanzada desde ahí escapa.

La estructura de este arranque es el patrón canónico de un servicio endurecido, y merece la pena memorizarla: primero se hace todo lo que requiere privilegio (abrir el socket, abrir los ficheros), después se sueltan los privilegios, y por último se instala el filtro. El orden no es negociable: instalar seccomp antes de abrir el socket haría fracasar el arranque. A partir de seccomp_load, aunque un atacante controle por completo el flujo de ejecución del proceso, no puede llamar a execve, y por tanto no consigue una shell; no puede llamar a ptrace, y por tanto no puede inyectarse en otro proceso; no puede montar nada. Ha heredado un proceso al que le falta la mitad del sistema operativo.

Ver el estado de seccomp de un proceso en marcha:

Y la buena noticia práctica: no hace falta escribir C para tener seccomp. Systemd expone listas predefinidas que cubren el 95 % de los casos, y las usaremos en 05-03:

La primera línea parte de un conjunto predefinido pensado para servicios; las siguientes, con ~, restan grupos enteros de llamadas peligrosas; y SystemCallArchitectures=native cierra un hueco clásico, el de invocar llamadas por la ABI de 32 bits para esquivar un filtro de 64.

Dos conceptos que ordenan todo lo anterior y te dan un criterio para decidir.

La base de cómputo confiable (TCB, trusted computing base) es el conjunto de componentes de los que depende la seguridad del sistema, y cuyo fallo la compromete. No es lo que "confías" en sentido coloquial: es lo que estás obligado a confiar porque no tienes forma de comprobarlo desde fuera. En meteo-01 la TCB incluye el firmware y el cargador de arranque, el núcleo de Linux con sus módulos y su política de MAC, los procesos que corren como root o con capabilities peligrosas, los binarios setuid, y también —esto sorprende— la infraestructura de actualización de paquetes y las claves con que se firman.

La regla de oro es directa: cuanto más pequeña es la TCB, más creíble es la seguridad del sistema, porque menos código hay que auditar y menos cosas pueden fallar. Es el principio 2 —economía del mecanismo— convertido en criterio de diseño, y es el argumento técnico a favor de los microkernels de 01-05: mover el controlador de red fuera del núcleo lo saca de la TCB, y un fallo suyo deja de ser una toma de control total.

La superficie de ataque es el conjunto de puntos por donde entra la entrada de un atacante. Para Meteora, enumerarla es un ejercicio de media hora que rinde muchísimo:

Cada mecanismo de esta lección ataca una fila distinta de esa tabla, y ninguno cubre dos. Eso es, exactamente, lo que significa defensa en profundidad.

Terminamos con un problema clásico de 1988 que explica una familia entera de vulnerabilidades y que, una vez lo entiendes, ves por todas partes.

El planteamiento original: un compilador que se ejecuta como servicio con privilegios propios. Además de compilar, lleva una contabilidad de uso en un fichero /var/lib/compilador/factura, sobre el que tiene permiso de escritura y los usuarios no. El compilador acepta un argumento: el nombre del fichero de salida.

Un usuario le pide compilar indicando como fichero de salida... /var/lib/compilador/factura. El compilador, obediente, escribe ahí. Y puede, porque él sí tiene permiso. El usuario acaba de destruir la contabilidad sin tener ningún permiso sobre ella.

El delegado confuso es un programa privilegiado al que se engaña para que use su propia autoridad en nombre de quien no la tiene. El programa no está comprometido: hace exactamente lo que le piden. El fallo está en que confunde dos autoridades: la suya y la de quien le pide.

Aplicado a Meteora, con un caso que podría escribir cualquiera:

Una petición con destino=../../../../etc/meteora/meteora.conf hace que meteo-api escriba con su propia autoridad en un sitio que el peticionario no controla. El proceso no ha sido comprometido: ha usado su permiso legítimo en nombre de un desconocido. Es la misma estructura que el CSRF en la web (el navegador es el delegado confuso, y sus cookies la autoridad), que el SSRF (el servidor es el delegado, y su posición dentro de la red la autoridad) y que muchos abusos de binarios setuid.

La versión correcta separa la autoridad de la petición:

Tres defensas, y cada una tapa un hueco distinto. La validación por lista blanca acepta solo la forma esperada, en vez de intentar enumerar lo prohibido —que siempre olvida algo, como ..%2f o una codificación exótica—. La resolución con realpath y la comprobación de prefijo neutraliza los .. y los enlaces simbólicos que apunten fuera, y se hace después de resolver, no antes. Y O_NOFOLLOW | O_EXCL cierra la ventana TOCTOU de 04-04: si el destino ya existe o es un enlace, la operación falla en vez de seguir el enlace a donde el atacante quiera. Por encima de las tres está el diseño: el perfil de AppArmor del apartado 8 solo permite escribir en rutas concretas, así que aunque las tres validaciones fallaran, el núcleo denegaría la escritura en /etc/meteora/. Cuatro capas independientes para un solo fallo: eso es defensa en profundidad aplicada de verdad.

Advertencia necesaria. Todo lo de esta lección se explica para defender sistemas propios. Cualquier prueba de seguridad —incluso una tan inocente como comprobar si un servicio valida bien un parámetro— debe hacerse exclusivamente sobre sistemas de tu propiedad o con autorización expresa y por escrito del responsable. Probar sobre sistemas ajenos sin permiso es un delito en la mayoría de jurisdicciones, con independencia de la intención. Y cuando una decisión de seguridad tenga implicaciones legales o regulatorias —datos personales, retención, notificación de brechas—, consúltala con un profesional de cumplimiento normativo o con asesoría jurídica.

Confundir "tiene los permisos correctos" con "está protegido". Los permisos limitan a qué ficheros llega un proceso. No dicen nada sobre a qué red se conecta, qué programas ejecuta o qué llamadas al sistema usa. Un meteo-api comprometido con permisos perfectos sigue pudiendo abrir una shell si nadie se lo impide.

Usar chmod u+s para resolver un problema de privilegio. Concede todos los privilegios del propietario cuando casi siempre hace falta uno. La alternativa correcta es una capability concreta —mejor aún, vía AmbientCapabilities en la unidad de systemd—, un grupo, o un socket con los permisos adecuados.

Creer que las capabilities de Linux son "capacidades" en el sentido teórico. No lo son: no nombran un objeto. CAP_DAC_OVERRIDE no es "puede leer este fichero", es "puede leer todos". Y precisamente por eso hay capabilities que equivalen a root: CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE y CAP_DAC_OVERRIDE.

Auditar solo los binarios setuid y olvidar getcap. Un binario con capabilities no muestra ninguna marca en ls -l. Si tu inventario de privilegio solo mira la s, tienes un punto ciego. Ejecuta también getcap -r /usr /bin /sbin y guarda la lista de referencia.

Escribir un perfil de MAC de golpe y activarlo en producción. Rompe el servicio, y un control que rompe el servicio se desactiva y no vuelve. Empieza siempre en modo queja o permisivo, observa varios días con carga real —incluyendo despliegues y rotación de logs— y solo entonces pon el modo obligatorio.

Poner el sistema en permissive o complain "temporalmente" para depurar. Ese "temporalmente" dura años. Si necesitas depurar, desactiva un solo perfil, anótalo con fecha y ponle un recordatorio.

Confiar en la seguridad por oscuridad. Cambiar el puerto de SSH reduce el ruido de los escaneos automáticos, y está bien. No es un control de seguridad, y no sustituye a las claves públicas ni al cortafuegos. Diseño abierto: la seguridad está en la clave, no en el secreto del diseño.

Consejo: ordena cualquier decisión de seguridad con la pregunta de los dominios. Ante cualquier componente, pregúntate: ¿cuál es su dominio de protección exacto?, ¿cuándo cambia de dominio?, y ¿qué pasa si un atacante hereda ese dominio entero? Las tres respuestas te llevan directamente a la lista de mecanismos que necesitas.

Construye la matriz de acceso completa de meteo-01 para los sujetos ingestor, agregador, meteo-api, nuria (analista) y carlos (administrador de sistemas), sobre los objetos /var/lib/meteora/lecturas/*.dat, /etc/meteora/meteora.conf, /etc/meteora/secrets.conf, /var/log/meteora/meteo-api.log, /dev/shm/meteora-cache y /run/meteora/lecturas.fifo. Después: (a) indica para cada celda no vacía con qué mecanismo concreto se implementa hoy (bits, ACL, grupo, capability); (b) señala qué celda sería imposible de expresar solo con los nueve bits y por qué; (c) explica qué cambia en la matriz si meteo-api resulta comprometido, y qué fila no cambia.

meteo-api debe escuchar en el puerto 443, leer los .dat y la configuración, y escribir en su registro. Nada más. Diseña la protección completa en tres capas independientes y, para cada una, escribe la configuración concreta y explica qué ataque concreto detiene esa capa y no las otras: (1) DAC, con propietarios y modos; (2) capabilities, decidiendo entre setcap sobre el fichero y AmbientCapabilities en la unidad, y justificando la elección; (3) MAC, con el esqueleto de un perfil de AppArmor. Termina indicando qué llamadas al sistema no debería poder usar y con qué directiva de systemd lo conseguirías.

Para cada una de estas cinco situaciones reales, di qué principio o principios de Saltzer y Schroeder se violan, qué ataque concreto lo aprovecha y cuál es la corrección:

1. Un script de despliegue ejecuta chmod -R 777 /var/lib/meteora "para que no dé problemas de permisos".
2. La política de la empresa obliga a cambiar la contraseña cada 30 días y prohíbe los gestores de contraseñas.
3. meteo-api corre como root "porque así seguro que funciona".
4. La API de administración no está documentada y está en /admin-x7f3, sin autenticación, "porque nadie la conocerá".
5. Los tres procesos de Meteora comparten /tmp y se pasan ficheros temporales con nombres predecibles como /tmp/meteora-cache-hoy.

Solución 1

La matriz (L = leer, E = escribir, A = añadir, X = ejecutar, — = sin acceso):

(a) Mecanismos. Las celdas de los tres procesos se implementan con DAC clásico: los tres corren con UID 990 y GID 990, y los ficheros son meteora:meteora 0640, salvo la configuración que es root:meteora 0640 —lectura por el grupo, escritura solo root—. La celda de nuria es una entrada de ACL POSIX (setfacl -m u:nuria:r) más su ACL por defecto para los ficheros futuros. La celda de carlos sobre los registros es pertenencia al grupo adm, y las demás son reglas de sudo (05-02), no acceso directo. Si meteo-api escuchara en el 443, aparecería una capability, CAP_NET_BIND_SERVICE, que no es una celda de esta matriz sino un privilegio global sobre el sistema: es justo la anomalía que comentábamos en el apartado 7.

(b) La celda imposible con nueve bits es la de nuria sobre los .dat. Los nueve bits solo expresan permisos para un usuario, un grupo y el resto; el usuario ya es meteora y el grupo también, así que la única forma de darle acceso a una cuarta identidad sería meterla en el grupo meteora —lo que le daría además meteora.conf y secrets.conf— o abrir other —lo que se lo daría a todo el sistema—. Es exactamente el desbordamiento del modelo de tres clases que motiva las ACL, y por eso hace falta una entrada nominal.

(c) Si meteo-api se compromete, su fila no cambia formalmente: el atacante hereda exactamente esos derechos. Y eso es lo grave, porque incluye secrets.conf con las claves de API, todos los .dat y meteora-cache. Pero el atacante obtiene además todo lo que la matriz no representa: ejecutar /bin/sh, abrir sockets salientes, escribir en /tmp, leer /etc/passwd, y persistir. La fila que no cambia es la de carlos: sus privilegios pasan por sudo y exigen una autenticación adicional que el atacante no tiene. Esa es la lección del ejercicio: la matriz de acceso describe DAC, y DAC no es toda la historia; para acotar lo que la matriz no ve hacen falta AppArmor y seccomp.

Solución 2

Capa 1 — DAC:

Qué detiene esta capa y no las otras: el acceso de otros usuarios y otros servicios del sistema a los datos de Meteora. Si mañana se instala otra aplicación con su propia cuenta de servicio, no podrá leer un solo .dat. Es la capa que separa inquilinos dentro de la misma máquina, y ni las capabilities ni AppArmor la sustituyen.

Capa 2 — capabilities. La elección correcta es AmbientCapabilities en la unidad, no setcap sobre el fichero:

Razones de la elección: con setcap, el privilegio queda grabado en el inodo del binario, de modo que cualquiera que lo ejecute lo obtiene y una copia del fichero podría arrastrarlo; con AmbientCapabilities, el privilegio lo concede systemd solo a este servicio, el binario del disco queda limpio, y CapabilityBoundingSet además impide para siempre que el proceso o sus hijos adquieran cualquier otra capability.

Qué detiene esta capa y no las otras: la escalada a root. Sin ella, la forma "fácil" de escuchar en el 443 sería correr como root o con setuid, y entonces un fallo en el análisis de peticiones daría el sistema entero. Con ella, el proceso comprometido no puede cargar módulos, ni montar, ni saltarse los permisos de fichero, ni depurar otros procesos. NoNewPrivileges=yes remata: aunque el proceso ejecutara un binario setuid, no ganaría privilegio.

Capa 3 — MAC (esquema de AppArmor):

Qué detiene esta capa y no las otras: el abuso de los permisos legítimos. DAC permite a meteora escribir en /tmp, leer /etc/passwd y ejecutar /bin/sh; las capabilities no dicen nada de eso porque no son privilegios de root. AppArmor lo deniega punto por punto, y sobre todo corta la obtención de una shell, que es el primer paso de casi cualquier cadena de ataque automatizada.

Llamadas al sistema que no debería poder usar: execve/execveat (nada que ejecutar), ptrace (nada que depurar), mount/umount2, init_module/finit_module/delete_module, kexec_load, keyctl, bpf, setuid/setgid tras el arranque, y unshare/setns. En systemd:

Las tres capas son independientes: si el perfil de AppArmor se descarga por error, DAC y las capabilities siguen ahí; si los permisos se estropean en un despliegue, AppArmor sigue denegando. Eso es lo que hace que la suma valga más que las partes.

Solución 3

1. chmod -R 777. Viola mínimo privilegio (concede a todo el sistema el máximo derecho posible), valores por defecto seguros (invierte la política: en vez de denegar por defecto, permite todo) y separación de privilegios (borra la distinción entre quien ejecuta el servicio y cualquier otro). El ataque: cualquier cuenta de la máquina —incluida la de otro servicio comprometido— puede modificar o borrar los datos, y los ficheros quedan además ejecutables, lo que habilita el vector "escribo un binario y espero a que alguien lo lance". Corrección: chmod -R u=rwX,g=rX,o= o separar por tipo con find -type d/-type f, y diagnosticar el permiso real con namei -l en vez de abrir de par en par.

2. Caducidad a 30 días sin gestor de contraseñas. Viola la aceptabilidad psicológica y, de rebote, el mínimo privilegio —porque produce contraseñas reutilizadas entre sistemas—. El resultado observable es Meteora2026! → Meteora2026!! → Meteora2026!!!, contraseñas apuntadas en post-its y en documentos compartidos, y reutilización entre servicios. Corrección alineada con las guías modernas: contraseñas largas en vez de complejas, sin caducidad periódica obligatoria, cambio solo ante indicio de compromiso, comprobación contra listas de contraseñas filtradas, y fomentar el gestor de contraseñas más segundo factor. Se detalla en Usuarios, Autenticación y Escalada de Privilegios.

3. meteo-api como root. Viola mínimo privilegio de la forma más directa posible, y también economía del mecanismo —toda la seguridad pasa a depender de que no haya un solo fallo en el código de la aplicación— y mínimo mecanismo común —comparte la identidad más poderosa con el resto del sistema—. El ataque: cualquier fallo de análisis de una petición HTTP se convierte en control total de la máquina, sin ningún paso intermedio. Corrección: User=meteora, la capability concreta si hace falta un puerto bajo, NoNewPrivileges=yes y confinamiento MAC.

4. La API en /admin-x7f3 sin autenticación. Viola el diseño abierto (la seguridad depende del secreto de la ruta, no de una credencial) y la mediación completa (hay un camino que no pasa por ninguna comprobación de acceso). El ataque no requiere adivinar nada: la ruta se filtra por los registros del proxy, por el historial del navegador, por una captura de pantalla en un ticket, por el Referer de una petición o por un escaneo de rutas. Corrección: autenticación real en ese punto —la ruta puede seguir siendo poco evidente, eso no molesta—, restricción por red de origen y registro de todos los accesos.

5. /tmp compartido con nombres predecibles. Viola el mínimo mecanismo común (los tres procesos comparten un recurso que además comparten con todo el sistema) y prepara un TOCTOU de manual: cualquier usuario puede crear /tmp/meteora-cache-hoy antes que Meteora, o sustituirlo por un enlace simbólico a otro fichero, provocando que el servicio escriba donde el atacante quiera —con la autoridad de meteora, lo que además lo convierte en un delegado confuso—. Corrección en tres frentes: PrivateTmp=yes en las unidades de systemd, de modo que cada servicio reciba su propio /tmp aislado; ficheros temporales con mkstemp() en lugar de nombres fijos; y para la comunicación real entre los procesos, los mecanismos de IPC del módulo 3 —el FIFO /run/meteora/lecturas.fifo y /dev/shm/meteora-cache, con permisos 0750 y 0660 en un directorio propio— en vez de ficheros sueltos en un directorio público.

La protección es el mecanismo interno con que el SO controla accesos; la seguridad es la propiedad global frente a un adversario. La primera se puede demostrar, la segunda solo se puede razonar con un modelo de amenazas, y de ahí la regla que gobierna todo el módulo: ningún mecanismo es una solución, todos son capas.

Todo control de acceso se describe con cuatro piezas: sujetos (procesos, no usuarios), objetos (ficheros, pero también sockets, procesos y memoria compartida), derechos y dominios de protección —el conjunto de pares (objeto, derechos) vigente ahora mismo—. Lo interesante son los cambios de dominio: el execve de un binario setuid es uno, y es donde se concentra la escalada de privilegios. Puestos en una tabla, sujetos y objetos forman la matriz de acceso, que ningún sistema almacena entera y todos trocean de una de dos maneras: por columnas son las ACL —la información vive en el objeto, se audita bien "¿quién accede a esto?" y se revoca fácil—; por filas son las capacidades —la llave vive en el sujeto, la comprobación es O(1), la delegación es natural y la revocación es difícil—. Los descriptores de fichero de UNIX son capacidades, y eso explica de una vez por qué el permiso se comprueba en open() y no en read().

Los ocho principios de Saltzer y Schroeder siguen siendo la mejor lista de comprobación que existe: mínimo privilegio (y durante el mínimo tiempo), economía del mecanismo, valores por defecto seguros, mediación completa —cuyo enemigo tiene nombre, TOCTOU—, diseño abierto frente a la seguridad por oscuridad, separación de privilegios, mínimo mecanismo común y aceptabilidad psicológica, el más ignorado y el que más brechas causa, porque un control que estorba se desactiva. Sobre ellos se construyen los cuatro modelos: DAC (decide el dueño; su punto débil es que un proceso comprometido hereda esa discreción), MAC (decide el administrador y ni root se la salta), RBAC (permisos a roles) y ABAC (reglas con atributos y contexto). Un servidor real los combina todos.

Y los tres mecanismos de Linux, cada uno atacando una superficie distinta. Las capabilities trocean el "todo o nada" de root en unas cuarenta piezas: CAP_NET_BIND_SERVICE deja a meteo-api escuchar en el 443 sin ser root, mientras que CAP_SYS_ADMIN, CAP_SYS_MODULE, CAP_SYS_PTRACE y CAP_DAC_OVERRIDE equivalen prácticamente a root y hay que tratarlas así; se conceden mejor con AmbientCapabilities que con setcap, y se auditan con getcap porque ls -l no las muestra. SELinux y AppArmor añaden una segunda comprobación obligatoria después de DAC —etiquetas frente a rutas— que convierte los permisos correctos en insuficientes para el atacante: un perfil sin reglas de ejecución impide que un meteo-api comprometido obtenga una shell. Y seccomp reduce la superficie más profunda de todas, de ~350 llamadas al sistema a las ~40 que el ingestor usa de verdad, con el patrón canónico de arranque: privilegio primero, soltar después, filtrar al final. Todo ello se ordena con dos ideas: hacer pequeña la TCB y enumerar la superficie de ataque. Y el delegado confuso recuerda que un programa privilegiado puede ser abusado sin estar comprometido, simplemente por confundir su autoridad con la de quien le pide algo.

Con esto tenemos el marco. Pero fíjate en que todo él descansa sobre una palabra que no hemos definido: identidad. Un dominio de protección se asigna a un sujeto, y el sujeto se identifica por un UID. Hemos hablado de meteora, de nuria y de carlos como si el sistema supiera quiénes son, cuando lo único que sabe el núcleo son los números 990, 1002 y 1001. ¿De dónde salen esos números? ¿Qué ocurre exactamente entre teclear una contraseña y tener una shell? ¿Cómo se guarda esa contraseña para que ni root pueda leerla? ¿Y cómo se sube de un dominio a otro de forma controlada y auditable, que es lo que hace sudo cincuenta veces al día?

Eso es Usuarios, Autenticación y Escalada de Privilegios, donde diseccionaremos /etc/passwd, /etc/shadow y /etc/group campo a campo, veremos cómo PAM encadena los módulos que deciden si entras, cómo funciona la autenticación por clave pública de SSH, y qué categorías de error de configuración convierten una cuenta normal en root sin que nadie se dé cuenta.