Seccomp: cómo Linux limita lo que un proceso puede pedir al kernel

Un proceso en Linux no puede abrir un fichero, crear un socket ni lanzar otro proceso por su cuenta. Para todo eso tiene que pedírselo al kernel mediante una llamada al sistema. Seccomp es el mecanismo del propio kernel que permite fijar de antemano qué llamadas acepta y qué ocurre con las que quedan fuera de la lista. La consecuencia práctica: aunque un atacante tome el control de un proceso, sigue obligado a pasar por esa aduana.

Aquí no se discute qué usuario ejecuta el proceso ni a qué ficheros tiene permiso, sino algo anterior: qué operaciones del kernel puede siquiera solicitar. Linux expone cientos de llamadas distintas y, por defecto, un proceso las tiene todas a mano, sujetas a los controles de permisos habituales. Entre ellas hay rutinas para montar sistemas de ficheros, cargar módulos del kernel, reiniciar la máquina o trazar otros procesos. Un servicio que solo lee y escribe ficheros no necesita ninguna de esas. Si con cinco llamadas le basta para hacer su trabajo, no hay razón para dejarle quinientas.

Modo estricto y modo filtro

Seccomp trabaja en dos modos. El estricto es el original y es brutal: el proceso solo puede invocar read, write, exit y el retorno de señal (sigreturn). Cualquier otra llamada lo mata. Sirve para casos muy concretos en los que una aplicación, pasado cierto punto, no necesita nada más.

El modo filtro es el que se usa de verdad. En lugar de una lista fija, el proceso —o el proceso padre que actúa en su nombre— instala una política propia donde se indica qué llamadas se permiten, cuáles se rechazan y qué pasa en cada caso. El kernel consulta esa política en cada intento de llamada y actúa según lo que diga: deja pasar, devuelve un error, genera una señal, mata el hilo o el proceso, o notifica al espacio de usuario cuando está soportado.

Qué mira el filtro

El filtro se apoya en BPF, el mismo conjunto de instrucciones que nació para el filtrado de paquetes de red y que el kernel reutiliza aquí porque sabe evaluarlo deprisa. Conviene ser exacto: no se trata de ejecutar programas eBPF con acceso completo al kernel. Seccomp-BPF usa un subconjunto restringido y lo aplica a los metadatos de la llamada. Puede inspeccionar el número de llamada, el identificador de arquitectura y determinados argumentos. No puede hacer entrada/salida, ni recorrer estructuras del kernel a su antojo, ni tomar decisiones por su cuenta. El alcance es deliberadamente estrecho.

Tampoco hay que esperar magia: seccomp no intercepta instrucciones arbitrarias en el espacio de usuario. Un proceso comprometido puede seguir ejecutando código en su propio espacio de direcciones, modificar sus datos y hacer cálculos. Lo único que queda acotado es el salto al kernel.

Ese salto, sin embargo, es donde el daño se vuelve real. Cuanto menos pueda pedirle un proceso al kernel, menos superficie queda para un atacante que ya controla ese proceso. Seccomp no sustituye al resto de controles, pero es la capa que decide qué puertas existen antes de preguntar quién puede abrirlas.