Toolbox: Entornos de desarrollo aislados para defenderse de errores y malware en el código en desarrollo

¿Quieres un contenedor de usuario persistente sin tu / home? Solo trato de comprender mejor el requisito / caso de uso. - Digamos, ¿comparado con ejecutar un contenedor Fedora estándar desechable?

Considere una cuenta de Unix que se usa tanto para el hogar como para el trabajo. Para un contenedor de trabajo, es posible que prefiera montar solo mi directorio de trabajo en el contenedor.

Considere una aplicación GUI que no sea de confianza. Es posible que solo necesite acceso a una carpeta específica para cargar / guardar archivos. No necesita acceso a mi carpeta .ssh y otros archivos no relacionados.

Para mejorar la seguridad, Chrome OS no comparte carpetas con contenedores de forma predeterminada desde el host. Allí, si desea proporcionar datos a los contenedores desde su directorio de inicio o desde una unidad USB, los comparte explícitamente.

La contenedorización como característica de seguridad pierde un valor significativo si le da al contenedor que no es de confianza todos sus datos de manera predeterminada.

@juhp Veo que trabajas mucho con los paquetes de Haskell. Suponga que uno de los paquetes de Haskell que está instalando de forma remota se ha visto comprometido. ¿Los paquetes de Haskell necesitan acceso a su carpeta .ssh o su billetera Bitcoin? ¿Por qué compartir todo en su entorno de desarrollo Haskell de forma predeterminada?

Recientemente, hubo un módulo de NPM que podría seguir siendo Bitcoin local si se instalaba:
https://www.trendmicro.com/vinfo/nz/security/news/cybercrime-and-digital-threats/hacker-infects-node-js-package-to-steal-from-bitcoin-wallets

El módulo era popular y, de hecho, mi equipo lo había instalado en nuestro árbol. No cumplimos con los otros criterios para que desencadenara un robo de bitcoins, pero ese riesgo se habría mitigado por completo si nuestro entorno de desarrollo no tuviera acceso completo a nuestros directorios de inicio de forma predeterminada. Ningún empleado hubiera optado por compartir su billetera Bitcoin en este entorno de desarrollo.

Esto es totalmente válido pero va a ser difícil.

Hablando en términos prácticos, creo que el mejor camino es facilitar la ejecución de cajas de herramientas como usuarios separados (crear transitoriamente nuevos uids, cada uno con su propio /home ) - requiere un servicio de sistema privilegiado para hacer eso.

Ahora, si desea compartir algunos archivos, por ejemplo, de solo lectura, eso se vuelve más complicado.

¿Es posible excluir archivos / directorios de un directorio bind-mount?

Para asegurarme de que entiendo el desafío, veo que el montaje del directorio de inicio ocurre en una línea de código

    --volume "$HOME":"$HOME":rslave

Pero el desafío aquí sigue siendo hacer que las aplicaciones GUI y algunas otras características funcionen, porque esas características esperan que el usuario dentro y fuera del contenedor sea el mismo.

En realidad, esta es una característica bastante importante. Creo que está bien montarlo en casa de forma predeterminada, pero debería ser posible usar un contenedor de una manera que no sea de confianza. El montaje en casa en un contenedor supone que confía en el contenedor, lo que en un contenedor desechable a menudo no es el caso. Incluso en casos simples como probar algún módulo de NPM, me gustaría tener la tranquilidad de que no va a arruinar mi carpeta de inicio.

@markstos tal vez pueda probar lo que puede hacer sin el soporte para el hogar o si solo está montando un directorio específico (cwd).

@juhp En realidad, esto fue espectacular para mí: dejé de evaluar Silverblue una vez que encontré esta característica que faltaba. Si esto se soluciona, puedo darle a Silverblue una segunda mirada. También me decepcionó descubrir que no fue fácil averiguar cómo ejecutar un contenedor de Ubuntu, que es el sistema operativo que he estado usando antes.

Si Fedora quiere dar la bienvenida a usuarios provenientes de otras distribuciones de Linux, facilitar la ejecución de su antigua distribución en un contenedor sería un buen lugar para comenzar.

@markstos gracias - Soy solo otro usuario de Toolbox. :-)
Estoy completamente de acuerdo en que extender Toolbox para admitir más sistemas operativos sería realmente muy útil.
Tenga en cuenta que Toolbox también funciona sin Silverblue (es decir, en otras ediciones de Fedora).

@juhp En realidad, esto fue espectacular para mí: dejé de evaluar Silverblue una vez que encontré esta característica que faltaba

¿Qué hiciste antes? ¿Hay alguna otra herramienta / enfoque que estaba utilizando que no funcionó en Silverblue?

Nada en absoluto le impide, por ejemplo, usar una máquina virtual desechable (como QubesOS), o para el caso tener un script personalizado que implemente algunas de las sugerencias de este hilo. Podría decirse que deberíamos ser más obstinados e incorporar una funcionalidad similar a QubesOS en Silverblue.

Pero de todos modos la tecnología de contenedores y máquinas virtuales existente está ahí. De hecho, toolbox hoy es en realidad un montón de scripts que hacen que podman confundan intencionalmente con el host. Si no desea la integración, puede comenzar con podman run ... ya que ese es el valor predeterminado.

@cgwalters Comencé a usar Chrome OS en mi computadora portátil personal y he llegado a apreciar la seguridad de tener mi entorno de desarrollo (y casi todo lo demás) ejecutándose dentro de un contenedor en VM a través del proyecto Crostini . Me gusta que sea compatible con aplicaciones GUI y con aplicaciones de línea de comandos. También me gusta que los contenedores sean privados por defecto. Tengo que compartir explícitamente carpetas de datos o unidades USB con ellos. Por otro lado, el soporte de sonido y wayland se configura automáticamente en esos contenedores.
url
En su lugar, he estado evaluando soluciones similares para usar en mi computadora portátil de trabajo. Una opción sería Cloudready de Neverware, un sistema operativo Chrome de código abierto para hardware de PC. A veces hay puertos en los que Crostini se bloquea, se pierden datos y es necesario comenzar de nuevo. Por esa razón, dudo en duplicar ChromeOS / Crostini ahora.

Silverblue también parecía atractivo hasta que descubrí que no parece admitir contenedores de Ubuntu de fábrica y comparte en exceso mis datos personales con contenedores en los que no tengo la intención de confiar. También miré Clear Linux. Tiene el mismo concepto de ejecutar casi todo en contenedores. No estoy encantado con los estrechos vínculos con Intel y x86. Tampoco es principalmente un sistema operativo de escritorio. Una opción final (¿predeterminada?) Sería seguir con Ubuntu como escritorio y mover más mi trabajo de desarrollo a contenedores LXD, que es lo que usa Crostini de Chrome. Debería poder copiar contenedores LXD entre mi trabajo y las computadoras portátiles personales, aunque el sistema operativo host sea diferente. Usando plantillas LXD, debería poder configurar una plantilla que comparta suficientes montajes en los contenedores para el soporte de Wayland.

nota al margen: ¡Gracias por todos los años de mantenimiento de Rhythmbox!

Quizás no entiendo bien la misión de toolbox . Del README:

.. La intención de estos sistemas es desalentar la instalación de software en el host

¿Por qué? Con el valor predeterminado es compartir todos sus datos personales en el contenedor de forma predeterminada, no creo que se pueda reclamar una seguridad mejorada.

El beneficio potencial restante sería el aislamiento, por lo que podría instalar versiones conflictivas de software una al lado de la otra.

Si se mantiene el comportamiento de compartir siempre, podría ser útil actualizar los documentos para aclarar que toolbox comparte todo su directorio de inicio en los contenedores, que el comportamiento no se puede deshabilitar y no se debe usar con no confiables contenedores.

Entiendo que puedo usar podman directamente, pero estaba interesado en una solución de contenedor con integración de GUI. Al buscar cómo lograr eso con podman , usar toolbox es el enfoque recomendado:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

@markstos Si está interesado, he creado PR # 298 que crea una imagen de Ubuntu 19.04.

Creo que hay algo de confusión aquí.

Nuestro README.md ha crecido y se ha transformado un poco a lo largo de los meses, y probablemente sea un poco más difícil de entender. Anteriormente, solía decir simplemente Hackear en Fedoras basadas en OSTree .

Si instala Silverblue (o cualquier otro sistema operativo basado en OSTree para el caso), la dificultad de depurar el sistema operativo o configurar un entorno de desarrollo se vuelve inmediatamente obvia. Toolbox existe para resolver ese problema.

.. La intención de estos sistemas es desalentar la instalación de software en el host

¿Por qué? Con el valor predeterminado es compartir todos sus datos personales en el contenedor de forma predeterminada, yo
no creo que se pueda reclamar una seguridad mejorada.

La seguridad es una palabra sobrecargada. Toolbox no hace ningún reclamo al respecto.

Durante muchas décadas, cualquier proceso que se ejecute como su UID podría ver sus claves criptográficas privadas, documentos, fotos, etc. e incluso transmitirlos a la mitad del planeta sin que usted lo sepa. Este es el status quo de los sistemas operativos de cliente de software libre.

Flatpak cambia eso al separar cada aplicación gráfica y el sistema operativo en sus propios dominios de seguridad. Silverblue solidifica esta separación al dificultar la instalación de software directamente dentro de la imagen del sistema operativo host. Por lo tanto, para una experiencia de usuario fluida, realmente necesita usar aplicaciones enviadas como Flatpaks.

Sin embargo, como mencioné en la parte superior, esta imagen del sistema operativo bloqueado presenta su propio conjunto de problemas. La forma en que los resolvemos es un compromiso entre conveniencia y seguridad. Cuanto más radical sea la solución, más difícil será para los usuarios actuales de Linux adoptar Silverblue.

Por el momento, Toolbox se inclina hacia la adopción por encima de la seguridad; porque independientemente de si está utilizando Toolbox o no, Silverblue hace una mejora espectacular en el estado de los sistemas operativos de los clientes de software libre y poner eso en manos del usuario sería un paso positivo.

Además, no se trata solo de seguridad. También se trata de estabilidad.

Es muy difícil probar una distribución de Linux convencional. Los paquetes y los espejos siempre se actualizan mediante contribuyentes aleatorios en espejos aleatorios en todo el mundo; la explosión combinatoria solo puede manejarse mediante un elaborado sistema de congelaciones. Cuando las cosas van mal, y lo hacen, también es muy difícil para un usuario revertir una actualización, y cosas como cortes de energía en medio de una actualización pueden dañar irremediablemente el sistema.

Un sistema operativo basado en OSTree cambia todo eso.

Entiendo que puedo usar podman directamente, pero estaba interesado en una solución de contenedor con GUI
integración. Al buscar cómo lograr eso con podman, usar la caja de herramientas es
el enfoque recomendado:

https://discussion.fedoraproject.org/t/how-to-run-a-containerized-gui-application/570

La pregunta es ¿por qué desea utilizar Podman para ejecutar aplicaciones gráficas? :)

En general, Podman (o un contenedor OCI) es una mala opción para ejecutar aplicaciones GUI. Esa es la razón por la que Flatpak existe y Toolbox no compite con eso.

Sin embargo, existe una superposición, en el sentido de que los contenedores de Toolbox tienen cierta integración de escritorio, y hay algunos casos en los que la capacidad de ejecutar una aplicación GUI que no sea Flatpaked es inmensamente útil en el corto plazo inmediato. Puede ser que la aplicación que desea no haya sido Flatpaked todavía, o tal vez a la versión Flatpaked le falten algunas características. Podría ser que esté trabajando en alguna biblioteca que utilizan aplicaciones gráficas y desee ejecutar rápidamente un programa de prueba único para ver si su biblioteca funciona como se esperaba.

De hecho, Toolbox puede ayudar en tales casos, pero eso es diferente a decir que el objetivo principal de Toolbox es contener aplicaciones gráficas. El objetivo principal de Toolbox es permitirle realizar su piratería en un sistema operativo basado en OSTree.

Ahora, si estuviera utilizando un IDE nativo de contenedor como GNOME Builder , que se envía como Flatpak, y configura automáticamente un contenedor para construir y ejecutar el software en el que está trabajando, entonces no necesitaría Toolbox en absoluto.

Sin embargo, no todo el mundo usa GNOME Builder, y los IDE más populares como Visual Studio Code no son nativos del contenedor de esa manera. Por lo tanto, Toolbox.

@debarshiray Gracias por la respuesta reflexiva y completa. El ejemplo que di arriba no fue para aplicaciones gráficas que podrían estar cubiertas por Flatpak. Di el ejemplo de cómo hacer el desarrollo de Node.js. Recientemente, hubo malware real en la cadena de dependencia de Node.js que podría robar de una billetera criptográfica local. Las claves SSH se pueden robar con la misma facilidad. Si bien el README dice que el proyecto se dirige a los desarrolladores, el recurso compartido con contenedores por defecto no protege a los desarrolladores de ese tipo de ataque.

Toolbox no brinda seguridad contra el robo de archivos personales al realizar el desarrollo de CLI con dependencias que no sean de confianza. Dada la complejidad del software de código abierto moderno, es probable que algunas partes del árbol de dependencia no sean confiables.

Encuentro que el README actual es engañoso: Ejecutar "sin privilegios en un contenedor" suena a seguridad, pero es solo un teatro de seguridad: todos los archivos personales son accesibles en el contenedor. Más arriba aclara que Toolbox no pretende hacer ningún reclamo sobre seguridad. Creo que sería una declaración útil incluirla en el archivo README para aclarar que, a pesar del uso de contenedores, esta es una herramienta por conveniencia, no por seguridad.

@debarshiray Gracias por la respuesta reflexiva y completa. El ejemplo que di
lo anterior no fue para aplicaciones gráficas que podrían estar cubiertas por Flatpak. Le di el
ejemplo de desarrollo de Node.js. Recientemente hubo malware real en Node.js
cadena de dependencia que podría robar de una billetera criptográfica local. Las claves SSH podrían ser robadas
con la misma facilidad. Si bien el README dice que el proyecto se dirige a los desarrolladores, el
share-with-containers-by-default no protege a los desarrolladores de ese tipo de ataque.

Sí, en este momento Toolbox simplemente intenta reproducir el entorno tradicional basado en paquetes dentro de un sistema operativo basado en imágenes.

Encuentro que el archivo README actual es engañoso: se ejecuta "sin privilegios en un contenedor"
suena a seguridad, pero es solo un teatro de seguridad: se puede acceder a todos los archivos personales en
El contenedor. Más arriba aclara que Toolbox no pretende hacer ningún reclamo sobre seguridad.
Creo que sería una declaración útil incluirla en el archivo README para aclarar que a pesar de
el uso de contenedores, esta es una herramienta por conveniencia, no por seguridad.

Confirme c047659c1d85ca982374da5c58ee7a24ba3847bd es donde se agregó esa línea. Creo que @cgwalters tenía la intención de decir que solo tiene acceso a su propio UID dentro de un contenedor de caja de herramientas y que la raíz real (es decir, UID 0 en el host) no está involucrada ni disponible para usted.

Tengo el mismo problema. Instalé Silverblue con la esperanza de poder ejecutar un software en el que quizás no confíe por completo sin tener que preocuparme de que robe mis claves SSH y otra información confidencial.

Darme cuenta de que la caja de herramientas no me permite hacer esto fue una gran decepción y me llevó a reconsiderar el uso de Silverblue para empezar. Personalmente, no me importa la instalación del sistema operativo principal. Siempre puedo reinstalar eso. La información que realmente quiero mantener separada se encuentra en mi directorio personal.

¿Sería posible especificar con mayor granularidad con precisión qué partes del directorio de inicio se comparten? Si uno pudiera incluir en la lista blanca solo los directorios que necesita la caja de herramientas (probablemente los relacionados con la configuración del escritorio, etc.), esto resolvería muchos problemas.

Ahora, soy perfectamente consciente de los problemas de seguridad. Dado que he estado usando Qubes OS durante varios años, el problema del aislamiento es difícil. Incluso si protege el directorio de inicio, eso no será suficiente, ya que un programa que se ejecuta dentro de un contenedor siempre puede aprovechar otros medios de comunicación entre contenedores, como el portapapeles. Soy consciente de esto y estoy dispuesto a aceptar algunos de esos riesgos a cambio de la comodidad de algo como la caja de herramientas en comparación con una instalación completa de Qubes.

Aquí se publica una solución alternativa.

La solución alternativa aprovecha el hecho de que toolbox se implementa como un script bash que hace referencia a la variable de entorno $HOME en todos los casos en los que es necesario buscar la ruta de /home/user . Por lo tanto, al configurar la variable de entorno $HOME para una llamada en particular a toolbox hace que un directorio que no sea su directorio de inicio completo, lleno de archivos personales valiosos, se comparta con un contenedor potencialmente no confiable.

En base a eso, parece que podría compartir un directorio vacío que contenga solo la configuración de la caja de herramientas al iniciar la caja de herramientas con un contenedor similar a esto:

#!/bin/bash
mkdir -p ~/toolboxes
HOME=~/toolboxes "$@"'

Si este script se llamara toolbox y se pusiera en su $ PATH antes del sistema toolbox , entonces parece que abordaría esta preocupación. Esta solución no ha sido probada.

Esta función ahora está funcionando en la bifurcación tlbx : https://gitlab.com/uppercat/tlbx/issues/3

Tengo el mismo problema. Instalé Silverblue con la esperanza de poder
ejecutar software en el que no pueda confiar por completo sin tener que preocuparme de que robe mi SSH
claves y otra información sensible.

Umm ... esto parece engañoso. Si desea ejecutar software que no es de confianza como usuario, Flatpak ya reduce sus preocupaciones sobre la pérdida de información confidencial. Si desea entornos de desarrollo aislados, eso es algo diferente.

Además, nada de esto es específico de Silverblue de ninguna manera. Los problemas han existido durante décadas y las soluciones no son específicas de Silverblue; también funcionan en sistemas operativos tradicionales basados ​​en paquetes.

La solución alternativa aprovecha el hecho de que toolbox se implementa como un script bash que
hace referencia a la variable de entorno $HOME en todos los casos donde la ruta de /home/user
necesita ser buscado. Entonces, estableciendo la variable de entorno $HOME para un
llamar a toolbox causa un directorio que no sea su directorio de inicio completo lleno de valiosos
archivos personales para compartir con un contenedor potencialmente no confiable.

Sí, eso es un buen truco. :)

Sin embargo, el objetivo principal del proyecto Toolbox es permitir la configuración de una amplia variedad de entornos de desarrollo en sistemas operativos basados ​​en imágenes (particularmente basados ​​en OSTree) con aproximadamente la misma cantidad de esfuerzo que es necesario en sus contrapartes basadas en paquetes. Hacer que estos entornos de desarrollo sean más seguros es definitivamente un deseo válido, pero no es algo que esté en la lista inmediata de tareas pendientes, porque el problema no es nuevo y existe desde siempre.

Además, Silverblue no se trata necesariamente de seguridad. Lo veo más como una mejora en la estabilidad y robustez del sistema operativo. Sin embargo, fomenta el uso de Flatpaks, por lo que, en ese sentido, mejora indirectamente la seguridad.

Por lo tanto, es valioso garantizar la paridad de características con las distribuciones de Linux basadas en paquetes, incluso si retiene algunos de sus problemas existentes. Resolver algunos problemas y hacer que las soluciones sean accesibles a la base de usuarios existente es mejor que no resolver nada. :)

Voy a cerrar este problema para que la lista de problemas abiertos no se salga de control y continúe reflejando aproximadamente los elementos que están en la lista actual de tareas pendientes. Sin embargo, todavía estará disponible para futuras referencias.

Sin embargo, estoy de acuerdo en que nuestro README.md debería ser más fácil de leer.

Hmm, no entiendo ese argumento. Solo porque un problema es viejo y ha estado ahí desde siempre, ¿no lo resuelves? Ese no es un buen punto de vista, en mi humilde opinión.
Y como usted dice, flatpak hace eso: paso a paso mejora la seguridad y aísla las aplicaciones. Tampoco dijeron "hmm, hemos enviado aplicaciones como paquetes rpm para siempre, ¿por qué deberíamos resolver este problema?", Simplemente lo resolvieron.

No veo ninguna razón por la que la caja de herramientas no debería al menos aislar el directorio de inicio también. Así que supongo que la discusión puede continuar en https://github.com/containers/toolbox/issues/348 de todos modos.

Creo que los contribuyentes y mantenedores de Toolbox están tomando este hilo como un ataque a la idea y el trabajo que se pone en el proyecto. Creo que debería tomarse como una característica requerida por muchas personas entusiasmadas con la idea. No me resisto a trabajar en una función que le permita montar un directorio de trabajo que no sea $ HOME. Es una característica que podría mejorar en gran medida la funcionalidad y el caso de uso, lo que también mejorará la adopción y el interés.

Yo fui quien sugirió cambiar la variable $ HOME en el n. ° 348. Es una solución hacky porque causa problemas cuando desea trabajar con dos contenedores múltiples con diferentes directorios $ HOME. Mi temor es que incluso esto no funcionará cuando la caja de herramientas se reescriba con go.

Mucha gente está solicitando esta función y se ha convertido en una barrera de entrada para muchas personas para adoptar cajas de herramientas, rpm-ostree y silverblue. Incluso si no se trata de seguridad, es una característica que abrirá muchas posibilidades para trabajar con cajas de herramientas.

Estoy dispuesto a ayudar en el tema si puedo y creo que otros también estarán dispuestos. Espero que esta característica no se convierta en un punto de discusión y se quede fuera de las futuras versiones de la caja de herramientas. En mi opinión, es lo único que le falta actualmente. Sería como conseguir un dnf en una maratón por salir de los últimos 10 metros. (juego de palabras intencionado :))

Fue un factor decisivo para mí. Renuncié a la caja de herramientas y Silverblue después
encontrando este defecto.

Solo porque un problema es antiguo y ha estado ahí desde siempre,
simplemente no lo resuelvas? Ese no es un buen punto de vista, en mi humilde opinión.

No tener algo en la lista inmediata de tareas pendientes no es lo mismo que no resolverlo . Existe la prioridad .

Y como usted dice, flatpak hace eso: paso a paso mejora la seguridad y
aísla aplicaciones. Tampoco dijeron "mmm, hemos enviado aplicaciones como
rpm paquetes para siempre, ¿por qué deberíamos resolver este problema? ", simplemente lo hicieron
resuélvelo.

Me encanta tu uso de la palabra ellos .

Bien, bien, así que si lo interpreto correctamente, esto puede ser una idea para el futuro, pero no en su "lista inmediata de tareas pendientes". (aunque supongo que es fácil de implementar, especialmente si puede seleccionar algunos parches de una bifurcación ) *

Si es así, tal vez mantenga este problema abierto y etiquételo como "se necesita ayuda", aunque realmente no necesita ayuda, no sé ... ¿qué le impide implementar esto? Supongo que solo necesita decir que acepta relaciones públicas sobre este tema y se implementará.
No veo que nada te detenga de eso, y aún puedes lograr la paridad de características o algo así, lo que sea ... en realidad es solo una característica menor. :pensando:

* Sí, veo y sé que esto se ha reescrito en Go ahora, pero tal vez esto todavía ayude o algo así, no lo sé. Al menos demuestra que es fácil de implementar.

Secuestrando un poco este problema aquí en caso de que alguno de los participantes quisiera revisar y dar su opinión sobre mi prototipo en https://gitlab.com/bkhl/etui

Está pensado como una alternativa a Toolbox para cuando desee un contenedor de desarrollo más estrictamente contenido.

@bkhl ¡Gracias! Marcado como favorito.