subusuario, beneficio o responsabilidad? [cerrado]

1

Estoy probando varias soluciones de sandboxing en Linux. Estoy acostumbrado a ejecutar programas que no son de confianza (por ejemplo, un navegador web, un lector de documentos pdf, etc.) dentro de una caja de arena selinux, con lo que estoy bastante satisfecho, pero hay un problema: solo es compatible con rhel / fedora. AFAIK otras distribuciones realmente no son compatibles con selinux (incluso cuando dicen que sí, no envían políticas o documentación utilizables), e incluso cuando se proporciona una política casi de trabajo, policycoreutils-sandbox no está disponible (vea debian).

¿Qué podría ser una solución de caja de arena multi-distro? Estoy probando la ventana acoplable / subusuario, que me permite iniciar un contenedor acoplable que ejecuta la aplicación de interés y le da acceso solo a una parte del sistema de archivos. Por ejemplo, puedo ejecutar 'chrome' en un contenedor de la ventana acoplable y dejar que solo acceda a mi directorio de descargas.

Esto parece una solución conveniente ya que es independiente de la distribución y no requiere que instale el programa que planeo ejecutar y sus dependencias en el host.

Sin embargo, no estoy muy seguro de cuánta seguridad hay en 'subuser-security': enlace

En primer lugar, la ventana acoplable aún no admite espacios de nombres de usuarios. Esto significa que cada 'contenedor' se ejecuta como root en mi host, incluso si está aislado por lxc. esto también significa que, si sigo las recomendaciones del subusuario, debo agregar mi usuario al grupo de docker. dado que dockerd se ejecuta como root, tener acceso a él significa que tengo acceso completo a todo el sistema de archivos del host como root, puedo ejecutar contenedores privilegiados, etc. Si esto no permite la escalada de privilegios (incluso si no es desde las aplicaciones 'invitadas', Espero), no sé lo que es.

además, digamos que estoy ejecutando Chrome en subusuario. Ahora tengo un navegador Chrome con su caja de arena deshabilitada (una capa menos) dentro de otra caja de arena debajo del usuario root. ¿Es realmente un beneficio simplemente ejecutando Chrome con su sandbox en un usuario sin privilegios?

No podría limitar su acceso a mi directorio principal, pero aparte de eso, no veo razones para preferir subusuario / docker.

¿Qué otras soluciones independientes de distro quedan?

Estoy empezando a pensar que la solución menos complicada sería simplemente usar usuarios estándar de Unix. Un usuario por aplicación, tal vez instale una aplicación y sus dependencias en ~ local, ~ bin, etc.

¿Qué gestores de paquetes admiten la instalación de un paquete, manteniendo un árbol de paquetes, como usuario dentro del directorio de inicio de un usuario? ¿Hay algún administrador de paquetes de terceros para Linux que admita esto?

¿Cómo compartirías archivos entre usuarios? Estoy pensando en la posibilidad de ejecutar un demonio ftp sin privilegios en localhost, digamos como usuario 'estándar' o 'almacenamiento' y usar usuarios virtuales para exportar partes de ese directorio de inicio (por ejemplo, / home / me / apps / webdownloads ) a otros usuarios, aplicaciones y montaje a través de fusibles.

¿Es esto razonable?

    
pregunta boh15 01.08.2014 - 08:32
fuente

1 respuesta

2

Soy Timothy Hobbs, el autor del subusuario. Me gustaría que primero lea mi artículo sobre la filosofía de seguridad del subusuario para que pueda ver a qué me dirijo. Mi objetivo es proteger una amplia base de usuarios de los ataques de la planta, y no proteger a los usuarios específicos de la NSA / otras organizaciones infames.

First of all, docker doesn't yet support user namespaces. This means that every 'container' runs as root on my host, even if it's isolated by lxc.

Si bien las versiones actuales del subusuario siguen generando la imagen como root, los subusuarios no se ejecutan como root a menos que se especifique lo contrario.

this also means that, if I follow subuser's recommendations, I have to add my user to the docker group. since dockerd runs as root, having access to it means that I have full access to the whole host filesystem as root, I can run privileged containers, etc. If this isn't enabling privilege escalation (even if not from 'guest' apps, I hope), I don't know what it is.

Es cierto que Docker, y como consecuencia, un subusuario, le otorga al usuario normal privilegios de root completos. Considero que esto es un defecto en Docker. Sin duda intentaré solucionar este problema, si la gente de Docker no lo hace por mí. Sin embargo, en un sistema de un solo usuario, no creo que sea un problema de seguridad para el usuario normal tener acceso de root. Porque si alguien obtiene el control del usuario normal, eso es tan malo como la raíz . Es realmente una cuestión de lo que intenta proteger: la integridad del sistema o sus datos y su privacidad.

furthermore, let's say that I'm running chrome in subuser. Now I have a chrome browser running with its sandbox disabled (one less layer) inside another sandbox under the root user. Is it really a benefit from simply running chrome with its sandbox under an unprivileged user?

Chrome es un caso especial. Es el único programa que he encontrado que tiene esta limitación. No recomiendo que ejecutes chrome en un subusuario.

I'm starting to think that the least cumbersome solution would be to simply use standard unix users. One user per application, maybe install an app and its dependencies under ~local, ~bin, etc.

Ciertamente consideré este enfoque cuando diseñé un subusuario. Sin embargo, compartir archivos entre usuarios es desordenado, inseguro o ambos. Además, no puede simplemente mostrar las ventanas x11 de otros usuarios al servidor x11 de su usuario. Debe configurar XPRA, VNC, RPC o alguna otra solución de red. Esto es tedioso, y uno de los objetivos principales del subusuario es eliminar el tedio de dicha configuración.

which package managers support installing a package, mantaining a package tree, as a user inside a user's home directory? are there any third party package managers for linux that support this?

Hay muchos administradores de paquetes que admiten la instalación de programas como usuarios normales. Puede ver una lista incompleta http //subuser.org/related-projects.html (no tiene suficiente reputación para publicar más de 2 enlaces) en el sitio web del subusuario. Simplemente desplácese hacia abajo hasta que llegue a la instalación cero. Por supuesto, estos administradores de paquetes no hacen nada en términos de seguridad.

'' '' ¿Cómo compartirías archivos entre usuarios? Estoy pensando en la posibilidad de ejecutar un demonio ftp sin privilegios en localhost, digamos como usuario 'estándar' o 'almacenamiento' y usar usuarios virtuales para exportar partes de ese directorio de inicio (por ejemplo, / home / me / apps / webdownloads ) a otros usuarios, aplicaciones y montaje a través de fusibles.

¿Es esto razonable? '' ''

El kit de herramientas de subidentidad http //ccl.cse.nd.edu/software/subid/ (no tiene suficiente reputación para publicar más de dos enlaces) proporciona una herramienta llamada subuserchown que ayuda a compartir archivos entre usuarios.

    
respondido por el timthelion 17.10.2014 - 12:40
fuente

Lea otras preguntas en las etiquetas