- Landlock es una API de seguridad de Linux que permite que una aplicación declare explícitamente los recursos a los que puede acceder para realizar su propio sandboxing a nivel del kernel.
- Es más simple que SELinux o AppArmor y puede crear y aplicar políticas en tiempo de ejecución sin permisos de administrador.
- Las políticas se definen como una lista de permisos explícita (allowlist) para archivos, directorios y puertos, y mediante restricciones jerárquicas permiten reforzar la seguridad de forma gradual.
- Existen bindings para Rust, Go, Haskell, entre otros, lo que permite implementar control de acceso granular en distintos entornos como aplicaciones GUI, servidores y procesos de escritorio.
- En el ecosistema de seguridad de Linux, se perfila como una herramienta de sandboxing sin privilegios, práctica y sencilla, que podría convertirse en un componente clave para fortalecer la seguridad de escritorio en el futuro.
Visión general de Landlock
- Landlock es una API que permite a las aplicaciones de Linux declarar explícitamente los recursos a los que pueden acceder
- Es similar al concepto de
unveil() y pledge() de OpenBSD y sigue el principio de “permitir solo los recursos necesarios y bloquear el resto”.
- Proporciona una capa de defensa amigable para desarrolladores más fácil de comprender e integrar que los mecanismos de seguridad de Linux existentes.
- Su objetivo es promover el uso de Landlock al definir de forma explícita el acceso permitido.
Cómo funciona
- Está implementado como Linux Security Module (LSM) y está disponible desde Linux 5.13.
- A diferencia de SELinux o AppArmor, aplica una restricción transitoria por proceso.
- La política se crea en tiempo de ejecución, se aplica solo al hilo actual y a los procesos hijos, y desaparece cuando el proceso termina.
- Componentes de la política
- Handled accesses: categorías de operaciones a restringir (p. ej., lectura/escritura de sistema de archivos)
- Access grants: lista explícita de objetos permitidos
- Política de ejemplo
/home/user de solo lectura/tmp de lectura/escritura- permitir
bind al puerto 2222
- Al invocar
landlock_restrict_self(), el hilo y los procesos hijos entran en un ámbito de restricción permanente
- La restricción es irrevocable, y pueden superponerse hasta un máximo de 16 capas (layer)
- Las capas inferiores pueden reducir aún más el acceso, pero los permisos eliminados en una capa superior no pueden recuperarse
- Es posible usarlo de forma no privilegiada (unprivileged), incluso para que aplicaciones comunes auto-sandboxeen.
- Gracias al versionado de ABI, funciona en el mayor rango posible incluso en kernels antiguos.
- Al ser un Stackable LSM, puede combinarse con SELinux o AppArmor.
Motivos de uso
- Adecuado para aplicaciones con patrones de acceso a archivos predecibles
- Ej.: un servidor web limitado para acceder solo a
/var/www/html y /tmp.
- No requiere intervención administrativa ni configuración global del sistema; la política se puede definir directamente en el código.
- Puede usarse sin escalamiento de privilegios, integrándose fácilmente con la mayoría de programas.
- Existen bindings para Rust, Go, Haskell y varios proyectos de wrapper con estilo
unveil.
- Aunque aún no hay una biblioteca C oficial, se pueden usar varias implementaciones no oficiales.
- En el ejemplo de Rust,
/usr, /etc, /dev se configuran como solo lectura y /home, /tmp con lectura/escritura.
Situación y necesidad de sandboxing en Linux
- Con el aumento del uso de Linux también aumenta el malware dirigido al escritorio.
- La seguridad relativa de Linux proviene de su participación de mercado y barreras técnicas, no de una seguridad estructural inherente.
- Problemas en distribuciones comunes
- Posibilidad de ejecutar binarios no confiables
- Posibilidad de ejecutar scripts directamente desde internet
- Uso de sudo sin contraseña
- Aplicaciones comunes pueden acceder a archivos sensibles dentro de
$HOME
- Posibilidad de espiar pulsaciones de teclado en entornos X11
- Posibilidad de hacer bind en puertos arbitrarios
Limitaciones de las herramientas de seguridad existentes
- Containerization (Docker, Podman): adecuado para aislamiento de servicios, pero no para apps de escritorio; existen casos de debilitamiento del aislamiento con la opción
--privileged.
- Flatpak / Snap: adecuado para apps GUI, pero con permisos excesivos; poco adecuado para herramientas CLI.
- Firejail: requiere perfiles por app y una llamada explícita en cada ejecución.
Mecanismos existentes desde la perspectiva del desarrollador
- seccomp: potente, pero la configuración es compleja y el enfoque de lista negra es vulnerable.
- SELinux: potente, pero complejo y requiere políticas administrativas; muchos sistemas vienen deshabilitados por defecto.
- AppArmor: más simple que SELinux, pero aún requiere perfiles de administrador y está deshabilitado en algunas distribuciones.
Resumen de las ventajas de Landlock
- Sin privilegios, centrado en la aplicación, fácil de integrar y bloqueo por defecto (deny-by-default).
- Soporte amplio desde Linux 5.13, con mantenimiento de compatibilidad hacia atrás y hacia adelante.
- No es perfecto, pero cubre un hueco como una herramienta de sandboxing simple e independiente, sin privilegios.
Aplicabilidad de Landlock
- En procesos demonio de alto privilegio de ejecución prolongada, Landlock puede limitar el alcance de acceso.
- Lector de PDF, visor de imágenes, navegador web, procesador de texto, entre otros, pueden restringirse para que solo accedan a archivos abiertos.
- Servidores FTP/HTTP pueden configurarse para acceder solo a los archivos necesarios.
- Ej.: aunque nginx se ejecute como root, si un atacante obtiene una shell no podrá acceder a archivos fuera de la política.
- Si se introduce una propuesta de Supervisor, sería posible implementar en el escritorio Linux un sistema de permisos similar a Android.
- Combinado con un sistema de permisos de GUI y de almacenamiento de permisos, se podría lograr una experiencia de usuario más segura.
Funcionalidades en desarrollo de Landlock
- Supervise Mode: decisión interactiva en espacio de usuario para permitir o denegar acceso, similar al prompt de permisos de Android.
- Socket Restrictions: control fino sobre tipos de socket y puertos que puede usar un proceso.
- LANDLOCK_RESTRICT_SELF_TSYNC: propaga la restricción a todos los hilos dentro de un proceso.
- LANDLOCK_ADD_RULE_QUIET: suprime mensajes de registro de auditoría para ciertos objetos.
- LANDLOCK_ADD_RULE_NO_INHERIT: evita que los permisos del directorio padre se hereden hacia abajo, afinando el control del sistema de archivos.
Resumen
- Landlock es un mecanismo de sandboxing de bloqueo por defecto simple y sin privilegios.
- Es fácil de entender e integrar, y tiene un gran potencial para mejorar la seguridad de escritorio y aplicaciones en Linux.
- Los desarrolladores pueden reforzar el nivel de seguridad al aplicar Landlock directamente en sus aplicaciones.
1 comentarios
Comentarios en Hacker News
Escribí un programa simple en C para permitir la recepción solo en un puerto específico y bloquear todas las demás conexiones de red
Tomé como referencia el
sandboxer.cde ejemplo, y controlé solo la red sin tocar las restricciones de acceso a archivosEn
dmesgaparecen las conexiones bloqueadas, probablemente gracias a la función de auditoríaEsta herramienta funciona en modo de usuario sin privilegios y también funciona bien dentro de contenedores sin configurar un firewall
Aun así, no creo que sea adecuada para bloquear por completo programas maliciosos
Si ves el issue #28 y este hilo de correos relacionado, hay un problema: las reglas del sandbox no pueden hacer referencia a directorios que no existen
Por ejemplo, si agregas una regla cuando
~/.sshtodavía no existe, aunque el directorio se cree después, el acceso no quedará bloqueadoEs decir, eso puede crear una brecha de seguridad
Ejecutarlos con el mínimo de privilegios es bastante complicado
“Microlandia” no funciona, pero otros juegos hechos con Unity sí corren bien
Espero que aparezcan más herramientas basadas en Landlock para que este tipo de trabajo sea más fácil
Parece que los CRI quieren definir su propia interfaz, pero inevitablemente siempre irán detrás del soporte del kernel
No creo que la mayoría de la gente de infraestructura vaya a mantener políticas de sandbox por aplicación
Me parece más realista que las propias aplicaciones usen Landlock
explica que si el runtime simplemente deja pasar la syscall, aparece el problema de tener que confiar en que la app se bloquee a sí misma
Internamente usamos una API parecida para la gestión de procesos críticos
Este tipo de investigación será de gran ayuda también en industrias reguladas
Si es una función del kernel, lo normal sería que primero existiera una API en C, así que me pregunto por qué no la hay
libc no es más que una capa encima, y todavía hay muchas syscalls que existen sin wrapper en libc
También podrías crear los headers tú mismo y llamarla con la macro
_syscallNPuedes usar un wrapper simple como landbox,
y Rust o Go también pueden exponer C FFI
Con el ejemplo sandboxer.c del kernel basta como referencia
No es lo mismo que Landlock, pero se puede usar de forma complementaria
/sysProbablemente sea por el principio de no privilegio
También me pregunto si se puede bloquear la syscall de Landlock con seccomp
Si una política vieja de seccomp no incluye el número de Landlock, ¿no podría terminar lanzando SIGSYS?
Las API basadas en sistema de archivos tienen muchos footguns, y para el control de acceso basado en dirfd una syscall encaja mejor
Un filtro seccomp bien escrito devuelve -ENOSYS para que simplemente parezca “no compatible”
Landlock solo restringe aún más los permisos existentes; no otorga permisos nuevos
Me estoy preparando para dejar Mac y pasarme por completo a Linux, y me pregunto qué tanto puede ayudar Landlock contra el malware
Por ejemplo, quisiera crear un entorno que rechace automáticamente el acceso a
~/.sshTambién quisiera saber si con esto se puede hacer un lanzador de aplicaciones
Sirve para que la propia app restrinja los permisos que no necesita y así un atacante no pueda tomar el control del sistema
~/.ssh, necesitas un modelo MAC como AppArmor o SELinuxLandlock es útil cuando la app se restringe a sí misma o a sus procesos hijos
Por ejemplo, que npm limite scripts post-install solo al directorio de build
Es una API para que la usen directamente los desarrolladores de apps, similar a pledge de OpenBSD
Pero como el ecosistema Linux está muy fragmentado, su adopción será lenta
Mientras tanto, lo más realista es usarlo en forma de wrapper o launcher
Al final, solo es efectivo cuando el programa conoce sus propios permisos
La app define una whitelist de los recursos que necesita al inicio y bloquea el resto
No es para defenderse de programas maliciosos, sino para la protección de su propio proceso
La librería estándar ya tiene syscalls, ¿de verdad hace falta una biblioteca aparte?
La documentación de man7 también existe
Me pregunto si lo que realmente quieren decir es que hace falta una capa de abstracción
sí sorprende que glibc todavía no ofrezca la interfaz de Landlock
Probablemente sea por temas de compatibilidad con sistemas que no son Linux