Desde Linux Darkcrizt  

Se planea portar el mecanismo de aislamiento pledge a Linux

Hace poco el autor de la biblioteca estándar Cosmopolitan C y la plataforma Redbean dio a conocer mediante un anunció, la implementación del mecanismo de aislamiento de pledge() para Linux.

Fue desarrollado originalmente por el proyecto OpenBSD y permite prohibir selectivamente que las aplicaciones accedan a las llamadas del sistema no utilizadas (se forma una especie de lista blanca de llamadas del sistema para la aplicación y se prohíben otras llamadas). A diferencia de los mecanismos de control de acceso syscall disponibles en Linux, como seccomp, el mecanismo de pledge está diseñado desde cero para que sea lo más fácil de usar posible.

La iniciativa fallida de aislar aplicaciones en el entorno base de OpenBSD utilizando el mecanismo systrace demostró que el aislamiento a nivel de llamadas de sistema individuales es demasiado complicado y requiere mucho tiempo.

Como alternativa, se propuso pledge, que permitía crear reglas de aislamiento sin entrar en detalles y manipular clases de acceso preparadas.

Por ejemplo, las clases que se ofrecen son stdio (entrada/salida), rpath (solo lectura de archivos), wpath (escritura de archivos), cpath (creación de archivos), tmppath (trabajo con archivos temporales), inet (sockets de red), unix (unix sockets), dns (resolución DNS), getpw (acceso de lectura a la base de datos del usuario), ioctl (llamada ioctl), proc (control de procesos), exec (procesos de inicio) e id (control de permisos).

Las reglas para trabajar con llamadas al sistema se especifican en forma de anotaciones que incluyen una lista de clases de llamadas al sistema permitidas y una matriz de rutas de archivos donde se permite el acceso. Después de compilar y ejecutar la aplicación modificada, el kernel asume el trabajo de monitorear el cumplimiento de las reglas especificadas.

Por separado, se está desarrollando la implementación de pledge para FreeBSD, que se distingue por la capacidad de aislar aplicaciones sin realizar cambios en su código, mientras que en OpenBSD la llamada de pledge tiene como objetivo una estrecha integración con el entorno base y la adición de anotaciones al código de cada uno.

Pledge es como la fruta prohibida que todos codiciamos cuando el jefe dice que debemos usar cosas como Linux. ¿Por qué eso importa? Es porque la pledge() en realidad hace que la seguridad sea comprensible. Linux nunca ha tenido realmente una capa de seguridad que los simples mortales puedan entender.

Los desarrolladores del port de pledge de Linux tomaron el ejemplo de FreeBSD y, en lugar de realizar cambios en el código, prepararon una utilidad adicional de pledge.com que le permite aplicar restricciones sin cambiar el código de la aplicación. Por ejemplo, para ejecutar la utilidad curl con acceso solo a las clases de llamada del sistema stdio, rpath, inet y threadstdio, simplemente ejecute «./pledge.com -p ‘stdio rpath inet thread’ curl http://example.com».

La utilidad funciona en todas las distribuciones de Linux desde RHEL6 y no requiere acceso de root. Adicionalmente, en base a la librería cosmopolitan, se proporciona una API para la gestión de restricciones en el código de los programas en lenguaje C, que permite, entre otras cosas, crear enclaves para restringir selectivamente el acceso en relación a determinadas funciones de la aplicación.

Ha habido algunos desarrolladores en el pasado que han intentado esto. No voy a dar nombres, porque la mayoría de estos proyectos nunca se completaron. Cuando se trata de SECOMP, los tutoriales en línea solo explican cómo incluir en la lista blanca las llamadas del sistema, por lo que la mayoría de las personas pierden interés antes de averiguar cómo filtrar los argumentos. Los proyectos que avanzaron también tuvieron descuidos como permitir el cambio de setuid/setgid/sticky bits. Por lo tanto, no se debe utilizar ninguna de las alternativas actuales. Creo que este esfuerzo nos acerca mucho más a tener pledge() que nunca.

La implementación no requiere cambios en el kernel: las restricciones de la utilidad se traducen en reglas SECCOMP BPF y se procesan utilizando el mecanismo de aislamiento de llamadas del sistema nativo de Linux. Por ejemplo, llamar a promise(«stdio rpath», 0) se convertirá en un filtro BPF

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.

Leave A Comment

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.