containers/bubblewrapHerramienta de sandboxing de bajo nivel sin privilegios utilizada por Flatpak y proyectos similares
Muchas herramientas de tiempo de ejecución de contenedores, como systemd-nspawn, docker,
etc., se centran en proporcionar infraestructura para administradores de sistemas y
herramientas de orquestación (p. ej. 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 root con privilegios completos en el host.
Existe una función en el kernel de Linux llamada espacios de nombres de usuario que permite a los usuarios sin privilegios usar funciones de contenedores. Bubblewrap las usa para construir la sandbox, lo que permite a cualquier usuario usar la herramienta.
Históricamente, bubblewrap también admitía un modo setuid para sistemas donde no se admitían los espacios de nombres de usuario sin privilegios. Sin embargo, esto se ha eliminado.
El código original de bubblewrap existía antes de los espacios de nombres de usuario; hereda código de xdg-app helper que a su vez deriva lejanamente de linux-user-chroot.
Los mantenedores de esta herramienta creen que no permite la escalada de privilegios, ni siquiera cuando se usa en combinación con el software típico instalado en esa distribución. Sin embargo, puede aumentar la capacidad de un usuario con sesión iniciada para realizar ataques de denegación de servicio.
En particular, bubblewrap usa PR_SET_NO_NEW_PRIVS para desactivar
los binarios setuid, que es la forma tradicional de salir de cosas
como los chroots.
bubblewrap es una herramienta para construir entornos sandbox. bubblewrap no es una sandbox completa y lista para usar con una política de seguridad específica.
Algunos de los casos de uso de bubblewrap quieren un límite de seguridad entre la sandbox y el sistema real; otros casos de uso quieren la capacidad de cambiar el diseño del sistema de archivos para los procesos dentro de la sandbox, pero no pretenden ser un límite de seguridad. Como resultado, el nivel de protección entre los procesos confinados en la sandbox y el sistema host está enteramente determinado por los argumentos pasados a bubblewrap.
Cualquier programa que construya los argumentos de línea de comandos para bubblewrap (a menudo un framework más grande como Flatpak, libgnome-desktop, sandwine o un script ad-hoc) es responsable de definir su propio modelo de seguridad, y de elegir los argumentos de línea de comandos de bubblewrap adecuados para implementar ese modelo de seguridad.
Algunos aspectos de la seguridad de la sandbox que requieren especial atención se describen en la sección Limitaciones a continuación.
Este programa puede ser compartido por todas las herramientas de contenedores que realizan operaciones sin root, como:
También nos gustaría que estuviera disponible en clústeres de Kubernetes/OpenShift. Tener la capacidad de que los usuarios sin privilegios usen funciones de contenedores haría significativamente más fáciles los escenarios de depuración interactiva y similares.
bubblewrap está disponible en los repositorios de paquetes de la mayoría de las distribuciones Linux y se puede instalar desde allí.
Si necesitas compilar bubblewrap desde el código fuente, puedes hacerlo con meson:
meson _builddir
meson compile -C _builddir
meson test -C _builddir
meson install -C _builddir
bubblewrap funciona creando un espacio de nombres de montaje nuevo y completamente vacío, donde la raíz está en un tmpfs que es invisible desde el host, y que se limpiará automáticamente cuando salga el último proceso. Luego puedes usar opciones de línea de comandos para construir el sistema de archivos raíz, el entorno del proceso y el comando a ejecutar en el espacio de nombres.
Hay un script de demostración más completo en el
código fuente, pero aquí hay una versión recortada que ejecuta
un nuevo shell reutilizando el /usr del host.
bwrap \
--ro-bind /usr /usr \
--symlink usr/lib64 /lib64 \
--proc /proc \
--dev /dev \
--unshare-pid \
--new-session \
bash
Este es un ejemplo incompleto, pero útil con fines ilustrativos.
Más a menudo, en lugar de crear un contenedor usando el árbol del sistema de archivos del
host, querrás apuntar a un chroot. Allí, en lugar de crear el enlace simbólico
lib64 -> usr/lib64 en el tmpfs, es posible que ya lo hayas creado en el rootfs de destino.
El objetivo de bubblewrap es ejecutar una aplicación en una sandbox, donde tenga acceso restringido a partes del sistema operativo o a datos de usuario, como el directorio personal.
bubblewrap siempre crea un nuevo espacio de nombres de montaje, y el usuario puede especificar
exactamente qué partes del sistema de archivos deben ser visibles en la sandbox.
Cualquier directorio de este tipo que especifiques se monta nodev por defecto, y puede hacerse de solo lectura.
Además, puedes usar estas funciones del kernel:
Espacios de nombres de usuario (CLONE_NEWUSER): Esto oculta todo excepto el uid y gid actuales de la sandbox. También puedes cambiar el valor que deben tener uid/gid dentro de la sandbox.
Espacios de nombres IPC (CLONE_NEWIPC): La sandbox 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): La sandbox no verá ningún proceso fuera de ella. Además, bubblewrap ejecutará un pid1 trivial dentro de tu contenedor para manejar los requisitos de recolección de procesos hijos en la sandbox. Esto evita lo que ahora se conoce como el problema del pid 1 de Docker.
Espacios de nombres de red (CLONE_NEWNET): La sandbox no verá la red. En su lugar, tendrá su propio espacio de nombres de red con solo un dispositivo de loopback.
Espacio de nombres UTS (CLONE_NEWUTS): La sandbox tendrá su propio nombre de host.
Filtros seccomp: Puedes pasar filtros seccomp que limiten qué syscalls se pueden realizar en la sandbox. Para más información, consulta Seccomp.
Como se señaló en la sección Seguridad de la sandbox anterior, el nivel de protección entre los procesos confinados en la sandbox y el sistema host está enteramente determinado por los argumentos pasados a bubblewrap. Aquí se señalan algunos aspectos que requieren especial cuidado.
Si no estás filtrando los comandos TIOCSTI con filtros seccomp,
se necesita el argumento --new-session para proteger contra la ejecución de comandos
fuera de la sandbox
(véase CVE-2017-5226).
Todo lo montado dentro de la sandbox puede usarse potencialmente para escalar privilegios. Por ejemplo, si vinculas un socket D-Bus dentro de la sandbox, se puede usar para ejecutar comandos a través de systemd. Puedes usar xdg-dbus-proxy para filtrar la comunicación D-Bus.
Algunas aplicaciones despliegan sus propios mecanismos de sandboxing, y estos pueden verse restringidos por las limitaciones impuestas por el sandboxing de bubblewrap. Por ejemplo, algunos navegadores web que configuran sus procesos hijos mediante seccomp para que no tengan acceso al sistema de archivos. Si limitas las syscalls y no permites la syscall seccomp, un navegador no puede aplicar estas restricciones. Del mismo modo, si estas reglas se compilan en un archivo que no está disponible en la sandbox, el navegador no puede cargar estas reglas desde ese archivo y no puede aplicar estas restricciones.
Firejail es similar a Flatpak antes de que bubblewrap se separara, en el sentido de que combina una herramienta setuid con muchas funciones de sandboxing específicas del escritorio. Por ejemplo, Firejail conoce Pulseaudio, mientras que bubblewrap no.
Los autores de bubblewrap creen que es mucho más fácil auditar un programa setuid pequeño, y mantener funciones como el filtrado de Pulseaudio como un proceso sin privilegios, como ocurre ahora en Flatpak.
Además, @cgwalters piensa que intentar
incluir en lista blanca rutas de archivo
es una mala idea dadas las innumerables formas en que los usuarios pueden manipular rutas,
y las innumerables formas en que los administradores de sistemas pueden configurar un
sistema. El enfoque de bubblewrap es conservar solo unas pocas capacidades Linux
específicas, como CAP_SYS_ADMIN, pero acceder siempre al sistema de archivos
como el uid que invoca. Esto elimina por completo los
ataques TOCTTOU y
similares.
Sandstorm.io requiere espacios de nombres de usuario sin privilegios para configurar su sandbox, aunque podría adaptarse fácilmente para operar también en modo setuid. @cgwalters cree que su código es bastante bueno, pero aún así podría tener sentido unificarse en bubblewrap. Sin embargo, @kentonv (de Sandstorm) opina que, aunque esto tiene sentido en principio, el costo del cambio supera los beneficios prácticos por ahora. Esta decisión podría reevaluarse en el futuro, pero no se está persiguiendo activamente hoy en día.
runC está trabajando actualmente en
el soporte de contenedores rootless,
sin necesidad de setuid ni de ningún otro privilegio durante la instalación de
runC (usando espacios de nombres de usuario sin privilegios en lugar de setuid),
la creación y la gestión de contenedores. Sin embargo, el modo estándar de
usar runC es similar a systemd nspawn
en que es una herramienta pensada para ser invocada 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 soportar ese modo. Sin embargo, con los contenedores rootless, runC podrá cumplir ciertos casos de uso que bubblewrap soporta (con el beneficio añadido de ser un runtime OCI estandarizado y completo).
binctr es solo un envoltorio para runC, por lo que hereda todas sus ventajas e inconvenientes de diseño.
El nombre bubblewrap se eligió para transmitir que esta herramienta se ejecuta como padre de la aplicación (por lo que la envuelve en cierto sentido) y crea una capa protectora (la sandbox) a su alrededor.
(Gato Bubblewrap por dancing_stupidity)