Planteamiento y contexto
Una herramienta de línea de comandos debe leer un conjunto pequeño de archivos de entrada, escribir en un directorio de salida designado y ejecutar plugins no confiables. El despliegue no puede otorgar privilegios adicionales, y el kernel podría exponer únicamente una ABI de Landlock más antigua. ¿Cómo diseñarías el sandbox, verificarías que las reglas funcionen y evitarías tratar un conjunto de reglas más estricto como prueba de que todo el sistema es seguro?
Esta pregunta encaja en roles de Linux, seguridad, sistemas de compilación y ejecución multiinquilino (multi-tenant). La señal evaluada es entender Landlock como un mecanismo de autorrestricción de procesos apilable y sin privilegios, no memorizar una estructura de C.
Qué está evaluando el entrevistador
- Si distingues entre dominios de reglas, tipos de reglas, derechos de acceso y alcance del proceso.
- Si sondeas la ABI del kernel antes de construir el conjunto de permisos soportado.
- Si sabes que los descriptores de archivo abiertos antes de la restricción necesitan una auditoría independiente.
- Si analizas fork, exec, hilos y la herencia en procesos hijos.
- Si el manejo de fallos, la observabilidad, el rollback y las pruebas forman parte del despliegue.
Preguntas para aclarar primero
- ¿Qué rutas necesitan capacidades de lectura, creación, eliminación, ejecución y red?
- ¿Puede un plugin hacer fork, exec, crear hilos o recibir descriptores de archivo heredados?
- ¿Cuál es la versión mínima del kernel y la degradación de seguridad aceptable?
- ¿Se abren logs, archivos de entrada, sockets o dispositivos antes de restringir el proceso?
- ¿Es el acceso a archivos el único límite, o también se requieren seccomp, contenedores o MAC?
Respuesta de treinta segundos
“Sondearía primero la ABI de Landlock, crearía un dominio de reglas, otorgaría únicamente acceso de lectura al árbol de entrada y acceso de creación/escritura al árbol de salida, y luego restringiría el proceso actual para que los descendientes hereden la política. Los descriptores de archivo abiertos antes de la restricción requieren una auditoría explícita porque podrían seguir siendo utilizables. Construiría el conjunto de permisos común más pequeño para ABIs más antiguas; si una capacidad de aislamiento obligatoria no está disponible, la herramienta se niega a ejecutarse o entra en un modo de solo lectura de bajo riesgo claramente registrado en lugar de ejecutarse silenciosamente sin sandbox.”
Análisis detallado paso a paso
Paso 1: Definir el modelo de amenazas y los derechos mínimos
Enumera lo que podría hacer un plugin: leer archivos del host, sobrescribir la salida, ejecutar otro programa, eliminar directorios, acceder a la red o abusar de descriptores heredados. Mapea cada acción con los derechos del sistema de archivos que soporta Landlock. Otorga únicamente las lecturas requeridas bajo el árbol de entrada y las escrituras o creaciones bajo el árbol de salida. Deja denegado cualquier derecho no otorgado en lugar de abrir la raíz y depender de comprobaciones a nivel de aplicación.
Paso 2: Sondear la ABI
Landlock añade derechos de acceso a lo largo de las versiones de su ABI. Al inicio, lee la ABI disponible y divide la política deseada en derechos obligatorios y opcionales. Añade derechos opcionales únicamente cuando estén soportados. Un derecho desconocido puede hacer que la creación de reglas falle, por lo que el constructor de políticas debe ser consciente de las capacidades (capability-aware). Registra la ABI detectada, la versión de la política y los derechos efectivos como campos estructurados.
Paso 3: Construir el dominio de reglas y vincular rutas
Crea un dominio de reglas, abre descriptores de directorio confiables durante el inicio y vincula reglas de ruta con los menores derechos necesarios para cada árbol. Abrir esos descriptores antes de que se ejecute el código del plugin evita que la configuración de la política resuelva rutas controladas por el atacante. Tras componer las reglas, restringe el proceso actual y prueba el comportamiento de herencia de los hilos y de las llamadas posteriores a exec.
Paso 4: Auditar recursos abiertos y herencia
Landlock restringe las solicitudes de acceso posteriores; los descriptores abiertos antes de la restricción aún podrían ser utilizables. Cierra los descriptores que no sean necesarios, marca los requeridos como recursos controlados y evita que se transmitan descriptores no relacionados. Revisa la entrada y salida estándar, logs, sockets, manejadores de directorio y descriptores suministrados a los plugins. Prueba fork, exec, hilos y procesos hijos por separado.
Paso 5: Definir fallos y defensa en profundidad
Landlock no restringe automáticamente cada llamada al sistema, operación de red o capacidad que el proceso ya posea. Añade seccomp, contenedores, espacios de nombres de usuario (user namespaces) o un MAC del sistema cuando el modelo de amenazas lo requiera. Si el dominio de reglas obligatorio no se puede crear, opta por el rechazo, un modo de solo lectura o una puerta de aprobación. Cada degradación debe emitir una alerta con su motivo; nunca debe ejecutar silenciosamente un plugin no confiable sin el límite de seguridad.
Paso 6: Verificar, observar y revertir (rollback)
Utiliza fixtures de CI para cubrir una matriz de permisos/denegaciones (allow/deny): las lecturas de entrada tienen éxito, las escrituras de salida tienen éxito, las lecturas fuera de los árboles permitidos fallan y las operaciones de eliminación o ejecución fallan según lo diseñado. Repite las comprobaciones en procesos hijos. Registra la ABI, el hash de la política, el recuento de operaciones denegadas y los motivos de salida. Durante un despliegue canary, mide las denegaciones falsas; cuando un plugin necesite otro derecho, actualiza la lista de permitidos y las pruebas en lugar de abrir su directorio padre. Un rollback puede deshabilitar el plugin o restaurar un ejecutor más antiguo manteniendo la alerta de fallo del sandbox.
Respuesta de ejemplo de alta calidad
Comenzaría con un inventario de permisos para las necesidades de archivos, ejecución y herencia del plugin, y luego sondearía la ABI de Landlock del kernel de destino. El dominio de reglas otorga lecturas en el árbol de entrada y creaciones y escrituras en el árbol de salida; los derechos opcionales se habilitan uno por uno, mientras que una capacidad obligatoria faltante hace que la ejecución no esté disponible. Antes de la restricción, cierro los descriptores innecesarios y audito los flujos estándar, logs, sockets y descriptores provistos por el plugin, para luego verificar el comportamiento de fork, exec, hilos e hijos.
Tras restringir el proceso, ejecutaría una matriz de allow/deny con el plugin real y registraría la ABI, la versión de la política, las operaciones denegadas y el motivo de la degradación. Landlock proporciona un límite apilable a nivel de sistema de archivos, no un sandbox completo de privilegios o red, por lo que aún podrían requerirse seccomp, contenedores, user namespaces o MAC. Si la política principal no se puede establecer, el ejecutor se niega o entra en un modo de solo lectura explícitamente alertado; nunca elude silenciosamente la política.
Errores comunes
- Tratar Landlock como aislamiento de privilegios → Restringe principalmente accesos controlados posteriores → combina controles según el modelo de amenazas.
- Ignorar las diferencias de ABI → Los nuevos derechos pueden ser desconocidos en kernels más antiguos → sondea y construye la política común más pequeña.
- Abrir todo antes de aplicar el sandbox → Los descriptores existentes pueden seguir siendo utilizables → cierra, audita y detén primero la herencia de descriptores no relacionados.
- Permitir un árbol padre y confiar en las comprobaciones de la aplicación → Un plugin puede recorrer más rutas → otorga derechos por árbol y por operación.
- Continuar silenciosamente tras un fallo de configuración → Los operadores no pueden ver que falta el aislamiento → rechaza, usa el modo de solo lectura o exige aprobación con una alerta.
- Probar solo el proceso principal → fork, exec e hilos cambian el límite → prueba cada ruta de herencia con casos de denegación.
Preguntas de seguimiento
¿Puede Landlock restringir un archivo que ya estaba abierto?
No debe tratarse como un mecanismo de cierre automático. Un descriptor abierto antes de la restricción puede seguir siendo utilizable, por lo que se deben cerrar los descriptores innecesarios antes de aplicar la política, controlar el paso de descriptores e incluir los manejadores retenidos en la auditoría y las pruebas.
¿Qué pasa si el kernel carece de un derecho de acceso solicitado?
Separa los derechos obligatorios de los opcionales. Sondea la ABI, añade los derechos opcionales soportados y rechaza el inicio o entra en un modo seguro explícitamente alertado cuando falte un derecho obligatorio. No ignores un fallo al crear reglas ni escribas derechos desconocidos en la regla.
¿Por qué añadir seccomp o un contenedor?
La fortaleza de Landlock radica en la autorrestricción a nivel de sistema de archivos y sin privilegios. No cubre cada llamada al sistema, ruta de red o política del host. Seccomp, user namespaces, contenedores y MAC pueden cubrir esos límites de llamadas, identidad y a nivel de sistema; el diseño combinado aún necesita pruebas de herencia y de rutas de fallo.