Políticas seccomp por categorías para confinar procesos sin privilegios
El trabajo parte del perfil por defecto de Docker, descarta las llamadas que exigen root y reparte el resto en familias inspiradas en pledge y en los filtros de systemd
Un desarrollador ha publicado un conjunto de políticas seccomp organizadas por categorías para confinar procesos que corren sin privilegios. El punto de partida es el perfil por defecto de Docker, retocado en tres direcciones: fuera las llamadas al sistema que exigen root, fuera las que apenas se usan y solo sirven para ampliar el fingerprinting de una aplicación de escritorio, y el resto repartido en familias.
De dónde salen las categorías
El reparto no es inventado. Sigue los conjuntos de filtros de seccomp de systemd y las promesas de pledge en OpenBSD, y así aparecen bloques para E/S básica, relojes, credenciales, descriptores de fichero, E/S sobre ficheros ya abiertos, sistema de ficheros, atributos del sistema de ficheros, bucle de eventos, E/S asíncrona y el runtime de C, con brk, mmap, futex o getrandom dentro.
Hay decisiones que se explican solas en los comentarios. ioctl entra en el bloque de E/S básica aunque no sea E/S en sentido estricto, porque glibc acaba usándolo para casi cualquier operación sobre ficheros, sockets o terminales y obliga a arrastrarlo a las demás categorías. Aparte quedan los bloques de compatibilidad, que existen porque hay código que no se puede recompilar: personality y arch_prctl para x86, remap_file_pages para binarios de 32 bits, name_to_handle_at porque systemd lo usa para obtener el identificador de un montaje, y modify_ldt para Wine.
Lo que se deja fuera
El bloque de depuración merece un párrafo aparte. Reúne ptrace, perf_event_open, process_vm_readv, kcmp y pidfd_getfd. Ya están detrás de ptrace_scope de YAMA o de capacidades como CAP_PERFMON, así que permitirlas no sería un desastre, pero solo sirven para inspeccionar procesos, hay mecanismos mejores para la comunicación entre procesos —memfd más seal más mmap da E/S sin copia— y varias han aparecido en CVE.
El autor también explicita qué no intenta resolver. pledge parte el acceso al sistema de ficheros en rpath, wpath, cpath y dpath; aquí no, porque ese grano fino le corresponde a Landlock. El lenguaje en que están escritas las políticas se compila a programas seccomp-BPF, y según el propio autor todavía no permite anotar reglas por arquitectura: le gustaría poder marcar arch_prctl como exclusivo de amd64 y que la regla solo entrara al compilar para esa arquitectura.
De la entrada solo se ha hecho circular el fichero de políticas. No hay cifras de sobrecarga, ni comparación medida con el perfil por defecto de Docker, ni demo. Como plantilla para quien tenga que endurecer un proceso sin privilegios y como argumento para partir el filtro en trozos en lugar de escribir una lista única, sirve. Para decidir si sustituye a lo que ya trae Docker, no hay con qué.
