Perfile de sandboxing sin privilegios para bubblewrap
Muchas herramientas de tiempo de ejecución de contenedores, como systemd-nspawn, dockeretc., se centran en proporcionar infraestructura para administradores de sistemas y herramientas de orquestación (por ejemplo, Kubernetes) para ejecutar contenedores.
Estas herramientas no son adecuadas para dárselas a usuarios sin privilegios, porque es trivial convertir dicho acceso en un shell raíz con privilegios completos en el host.
Existeun sistema de aislamiento a nivel del kernel Linux llamado "user namespaces" espacios de nombres de usuario que intenta permitir que los usuarios sin privilegios utilicen las funciones del contenedor. Si bien se ha logrado un progreso significativo, todavía existen preocupaciones al respecto y no está disponible para usuarios sin privilegios en varias distribuciones de producción como CentOS / Red Hat Enterprise Linux 7, Debian Jessie, etc.
Consulte, por ejemplo, CVE-2016-3135, que es una vulnerabilidad de raíz local introducida por los usuarios. Esta publicación de marzo de 2016 tiene más discusión.
Bubblewrap podría verse como una implementación de conjunto de un subconjunto de espacios de nombres de usuario. Énfasis en el subconjunto - específicamente relevante para el CVE anterior, bubblewrap no permite el control sobre iptables.
El código original de bubblewrap existía antes de los espacios de nombres de usuario: hereda el código de xdg-app helper que, a su vez, se deriva de forma distante de linux-user-chroot .
Los mantenedores de esta herramienta creen que, incluso cuando se usa en combinación con el software típico instalado en esa distribución, no permite la escalada de privilegios. Sin embargo, puede aumentar la capacidad de un usuario que ha iniciado sesión para realizar ataques de denegación de servicio.
En particular, bubblewrap se utiliza PR_SET_NO_NEW_PRIVS para desactivar los binarios de setuid, que es la forma tradicional de salir de cosas como chroots.
Este programa puede ser compartido por todas las herramientas de contenedor que realizan operaciones no root, como:
Flatpak rpm-ostree sin privilegios bwrap-oci También nos gustaría que esto estuviera disponible en los clústeres de Kubernetes / OpenShift. Tener la capacidad de que los usuarios sin privilegios utilicen las funciones del contenedor facilitaría significativamente la realización de escenarios de depuración interactivos y similares.
bubblewrap funciona creando un espacio de nombres de montaje nuevo, completamente vacío, donde la raíz está en un tmpfs que es invisible para el host, y se limpiará automáticamente cuando finalice el último proceso. A continuación, puede utilizar las opciones de la línea de comandos para construir el sistema de archivos raíz y el entorno de proceso y el comando para ejecutar en el espacio de nombres.
Hay una secuencia de comandos de demostración más grande en el código fuente, pero aquí hay una versión reducida que ejecuta un nuevo shell reutilizando el archivo /usr.
bwrap --ro-bind /usr /usr --symlink usr/lib64 /lib64 --proc /proc --dev /dev --unshare-pid bash Este es un ejemplo incompleto, pero útil con fines ilustrativos. Más a menudo, en lugar de crear un contenedor utilizando el árbol del sistema de archivos del host, desea apuntar a un chroot. Allí, en lugar de crear el enlace simbólico lib64 -> usr/lib64en los tmpfs, es posible que ya lo haya creado en los rootfs de destino.
El objetivo de bubblewrap es ejecutar una aplicación en una caja de arena, donde tiene acceso restringido a partes del sistema operativo o datos del usuario, como el directorio de inicio.
bubblewrap siempre crea un nuevo espacio de nombres de montaje, y el usuario puede especificar exactamente qué partes del sistema de archivos deben estar visibles en la caja de arena. Cualquiera de estos directorios que especifique se montará nodevde forma predeterminada y se puede hacer de solo lectura.
Además, puede utilizar estas funciones del kernel:
Espacios de nombres de usuario ( CLONE_NEWUSER ): esto oculta todo menos el uid y gid actuales del sandbox. También puede cambiar cuál debería ser el valor de uid / gid en la caja de arena.
Espacios de nombres de IPC ( CLONE_NEWIPC ): la caja de arena obtendrá su propia copia de todas las diferentes formas de IPC, como la memoria compartida SysV y los semáforos.
Espacios de nombres PID ( CLONE_NEWPID ): el sandbox no verá ningún proceso fuera del sandbox. Además, bubblewrap ejecutará un pid1 trivial dentro de su contenedor para manejar los requisitos de cosechar niños en la caja de arena. Esto evita lo que ahora se conoce como el problema Docker pid 1 .
Espacios dehttp://linux.die.net/man/2/clone nombres de red ( CLONE_NEWNET ): el sandbox no verá la red. En su lugar, tendrá su propio espacio de nombres de red con solo un dispositivo de bucle invertido.
Espacio de nombres de UTS ( CLONE_NEWUTS ): la caja de arena tendrá su propio nombre de host.
Filtros seccomp: puede pasar filtros seccomp que limitan las llamadas al sistema que se pueden realizar en la zona de pruebas. Para obtener más información, consulte Seccomp .
Firejail es similar a Flatpak antes de que bubblewrap se dividiera en el sentido de que combina una herramienta setuid con muchas funciones de sandboxing específicas de escritorio. Por ejemplo, Firejail conoce Pulseaudio, mientras que bubblewrap no.
Los autores de bubblewrap creen que es mucho más fácil auditar un pequeño programa setuid y mantener características como el filtrado de Pulseaudio como un proceso sin privilegios, como ocurre ahora en Flatpak.
Además, @cgwalters piensa que tratar de incluir en la lista blanca las rutas de los archivos es una mala idea dadas las innumerables formas en que los usuarios tienen que manipular las rutas y las innumerables formas en que los administradores del sistema pueden configurar un sistema. El enfoque de bubblewrap es retener solo algunas capacidades específicas de Linux como CAP_SYS_ADMIN, pero siempre acceder al sistema de archivos como el uid de invocación. Esto cierra por completo los ataques TOCTTOU y demás .
Sandstorm.io requiere espacios de nombres de usuarios sin privilegios para configurar su caja de arena, aunque también podría adaptarse fácilmente para operar en un modo setuid. @cgwalters cree que su código es bastante bueno, pero aún podría tener sentido unificar en bubblewrap. Sin embargo, @kentonv (de Sandstorm) siente que si bien esto tiene sentido en principio, el costo de cambio supera los beneficios prácticos por ahora. Esta decisión podría reevaluarse en el futuro, pero hoy no se está aplicando activamente.
runC está trabajando actualmente en el soporte de contenedores sin raíz , sin necesidad setuidni ningún otro privilegio durante la instalación de runC (usando espacios de nombres de usuarios sin privilegios en lugar de setuid), creación y administración de contenedores. Sin embargo, el modo estándar de usar runC es similar a systemd nspawn en que está diseñado para ser invocado por root.
Los autores de bubblewrap creen que runc y systemd-nspawn no están diseñados para convertirse en setuid, y están lejos de admitir tal modo. Sin embargo, con contenedores sin raíz, runC podrá cumplir con ciertos casos de uso que admite bubblewrap (con el beneficio adicional de ser un tiempo de ejecución OCI completo y estandarizado).
binctr es solo una envoltura para runC, por lo que hereda todas sus compensaciones de diseño.