Se dio a conocer que se ha propuesto una implementación de un mecanismo de aislamiento de aplicaciones para FreeBSD, que recuerda a las llamadas al sistema plegde y develación desarrolladas por el proyecto OpenBSD.
El aislamiento en plegde se lleva a cabo prohibiendo el acceso a las llamadas del sistema que no se utilizan en la aplicación y desvelando mediante la apertura selectiva del acceso solo para ciertas rutas de archivo con las que la aplicación puede funcionar. Para la aplicación, se forma una especie de lista blanca de llamadas al sistema y rutas de archivos, y todas las demás llamadas y rutas están prohibidas.
La diferencia entre plegde y develado, desarrollado para FreeBSD, se reduce a proporcionar una capa adicional que permite aislar aplicaciones sin realizar cambios en su código o con cambios mínimos. Recuerde que en OpenBSD plegde y unlock tienen como objetivo una estrecha integración con el entorno base y se implementan añadiendo anotaciones especiales al código de cada aplicación.
Para simplificar la organización de la protección, los filtros le permiten evitar detalles a nivel de llamadas al sistema individuales y manipular las clases de llamadas al sistema (entrada/salida, lectura de archivos, escritura de archivos, sockets, ioctl, sysctl, inicio de procesos, etc.) . Las funciones de restricción de acceso se pueden llamar en el código de la aplicación a medida que se realizan ciertas acciones, por ejemplo, el acceso a los sockets y los archivos se pueden cerrar después de abrir los archivos necesarios y establecer una conexión de red.
El autor del port de plegde y develación para FreeBSD pretende brindar la capacidad de aislar aplicaciones arbitrarias, para lo cual se propone la utilidad curtain, que permite aplicar reglas definidas en un archivo separado a las aplicaciones. La configuración propuesta incluye un archivo con configuraciones básicas que definen las clases de llamadas al sistema y las rutas típicas de archivo específicas para ciertas aplicaciones (trabajo con sonido, redes, registro, etc.), así como un archivo con reglas de acceso para aplicaciones específicas.
La utilidad curtain se puede utilizar para aislar la mayoría de las utilidades, procesos de servidor, aplicaciones gráficas e incluso sesiones de escritorio completas que no han sido modificadas. Se admite compartir curtain con los mecanismos de aislamiento proporcionados por los subsistemas Jail y Capsicum.
También es posible organizar el aislamiento anidado, cuando las aplicaciones iniciadas heredan las reglas establecidas por la aplicación principal, complementándolas con restricciones separadas. Algunas operaciones del kernel (herramientas de depuración, POSIX/SysV IPC, PTY) están protegidas adicionalmente por un mecanismo de barrera que impide el acceso a los objetos del kernel creados por procesos que no sean el proceso actual o principal.
Un proceso puede configurar su propio aislamiento llamando a curtainctl o usando las funciones plegde() y unveil()proporcionadas por la biblioteca libcurtain, similares a las de OpenBSD. El sysctl ‘security.curtain.log_level’ se proporciona para realizar un seguimiento de los bloqueos mientras se ejecuta la aplicación.
El acceso a los protocolos X11 y Wayland se habilita por separado especificando las opciones «-X»/»-Y» y «-W» al iniciar la cortina, pero el soporte para aplicaciones gráficas aún no está lo suficientemente estabilizado y tiene una serie de problemas sin resolver ( los problemas aparecen principalmente cuando se usa X11, y el soporte de Wayland es mucho mejor). Los usuarios pueden agregar restricciones adicionales creando archivos de reglas locales (~/.curtain.conf). Por ejemplo,
La implementación incluye el módulo de kernel mac_curtain para control de acceso obligatorio (MAC), un conjunto de parches para el kernel de FreeBSD con la implementación de los controladores y filtros necesarios, la biblioteca libcurtain para usar plegde y funciones reveladas en aplicaciones, la utilidad de cortina, muestra archivos de configuración, un conjunto de pruebas y parches para algunos programas en el espacio del usuario (por ejemplo, para usar $TMPDIR para unificar el trabajo con archivos temporales). Siempre que sea posible, el autor pretende minimizar la cantidad de cambios que requieren la aplicación de parches al kernel y las aplicaciones.
Finalmente si estás interesado en conocer más al respecto, puedes consultar los detalles en el siguiente enlace.