Inko integra una API de sandboxing multiplataforma que cabe en unas pocas líneas
El lenguaje de Yorick Peterse envuelve Landlock, Seatbelt, Capsicum y pledge/unveil en una interfaz común. En FreeBSD el sandbox queda desactivado.
Inko, el lenguaje con seguridad de memoria como objetivo que desarrolla Yorick Peterse, ha integrado una API de sandboxing multiplataforma. Permite restringir lo que puede hacer una aplicación con unas pocas líneas de código, sin depender de cómo se ejecute el programa. El autor ya la ha aplicado a su propio servidor estático.
Envolver lo que ya ofrece el sistema
Por debajo la API no inventa nada. Se apoya en los mecanismos que ya traen los sistemas operativos: Landlock en Linux, Seatbelt a través de sandbox_init en macOS, Capsicum en FreeBSD y pledge/unveil en OpenBSD. El trabajo de Inko es envolverlos en una interfaz común y absorber las diferencias entre plataformas. Un ejemplo que cita el propio autor: en macOS permitir ejecutar un fichero es trivial, pero con Landlock hay que declarar además reglas para el intérprete ELF (/lib64/ld-linux-x86-64.so.2 en la mayoría de los casos) y para las bibliotecas compartidas que no estén en la ruta habitual.
La prueba la ha hecho con shost, su servidor de ficheros estáticos escrito en Inko. Importa std.sandbox y con media docena de llamadas declara qué directorios se pueden leer (los certificados TLS si están activos y los ficheros a servir) y a qué puerto TCP se puede hacer bind. Todo lo demás queda denegado. Aunque shost ya corre dentro de un contenedor Podman con capacidades recortadas y volumen de solo lectura, el autor argumenta que la API es tan barata de usar que no hay motivo para no hacerlo.
La excepción de FreeBSD
En FreeBSD el sandbox no hace nada. Peterse lo justifica: Capsicum no es un conjunto de reglas que se aplican al arrancar, sino que obliga a cambiar la estructura del programa. Una vez se llama a cap_enter ya no se pueden abrir recursos con open; hay que abrirlos antes, o abrir directorios por adelantado y usar openat relativo a ellos, y en algunos casos tirar de libcasper. En un programa pequeño se lleva, en uno grande implica reescribir bastante. El autor añade que openat tampoco está exento de problemas. El resultado es que no se puede aprovechar Capsicum salvo que se adapte el código específicamente a FreeBSD.
El propio autor cierra con la idea que da sentido a la pieza: el valor de una característica de seguridad no está en lo que puede hacer, sino en lo fácil que resulta usarla. Y reconoce que su opinión puede estar sesgada, porque la API la escribió él.
Para quien mantiene servicios en producción, la propuesta es interesante por dónde se coloca: no sustituye al aislamiento por contenedores, lo complementa desde dentro del proceso. Que sea portátil salvo en FreeBSD es la limitación a tener en cuenta si esa plataforma está en el parque.
