On 14/08/13 11:28, Juan José López wrote:
Lo que pretendeis hacer no es tan sencillo. fakeroot carga un librería que envuelve algunas llamadas al sistema, para que parezca que el proceso llamante tiene permisos de root (udi=0), aunque realmente no los tenga. Es decir, el proceso cree llamar a la función 'getuid()' del sistema, cuando en realidad está llamando a la función 'getuid()' de la librería cargada. Esta técnica es relativamente fácil de implementar, permitiendo envolver cualquier llamada a la librería libc (en general, a cualquier librería), pero presenta un MUY GRAVE problema de seguridad. Nada impide a una aplicación realizar llamadas directas a las funciones del núcleo, saltandose la librería libc y cualquier otra que este cargada. Si la seguridad es prioritaria, esta técnica está descartada.
Dejando a un lado la discutible "facilidad" de implementación de esta técnica, por los motivosque comentas, veo no es la solución. Entiendo Carlos lo comentó para tomar el ejemplo de cómo trabaja fakeroot (interceptando llamadas a sistema a través de libc) y encontrar/aplicar una solución similar.
Otro enfoque es utilizar herramientas del tipo AppArmor, SELinux, e incluso Linux Containers. No tengo experiencia práctica con ellas, y no se hasta que punto se pueden configurar para que intercepten ciertas llamdas al sistema y emulen un entorno aislado. Son multitud las llamadas a interceptar, y los resultados han de ser coherentes y persistentes durante todo el tiempo de ejecución de la aplicación, si queremos que esta funciones con normalidad. Es decir, si la aplicación crea un archivo y realiza lecturas y escrituras, ese archivo y esos datos han de existir durante el tiempo que la aplicación esté activa. Este método puede considerarse el mas seguro, a costa de limitar la integración general con el sistema. Llamadas a servicios esperados por la aplicación (dbus, por ejemplo, o el socket de X), lectura de archivos estandar (/dev/nul, /etc/services, /etc/passwd ). Librerías compartidas necesarias, ...
Como dije en un correo previo, creo que SELinux tiene tool de sandboxing (sólo en CentOS/Redhat) y AppArmor algo parecido para SuSe, pero como comentó Camaleon, configurarlo tiene su complejidad (algo que intento evitar).
En cuanto al tema de containers, si bien necesita su espacio en disco, el uso de recursos es contenido (comparado con las soluciones de virtualización). Pero al menos con lxc acabo de ver [1] [2] que para poder tener un entorno con escritorio, necesitas habilitar acceso a dispositivos, y eso merma la seguridad.
[1] http://unix.stackexchange.com/questions/18003/linux-lxc-deploying-images-with-tiniest-possible-x11 [2] http://www.jonnor.com/2010/03/hardware-passthrough-in-lxc-or-running-a-desktop-in-a-cgroup/
Un enfoque similar es utilizar chroot. Configurar un entorno chroot es practicamente igual a configurar nuestro entorno 'real'. Una escalada de privilegios se produce de igual forma tanto en el entorno real como en el chrooteado. Un bug de una aplicación o del propio kernel presenta los mismos problemas, y si se consigue acceso root, el chroot no sirve para nada. Los chroot ofrecen más facilidades de integración entre las 'jaulas' y el entorno real. Se pueden compartir sistemas de ficheros, incluso hacer que los cambios a un archivo se realicen en realidad en un sistema de archivos distinto. UnionFS, ROFS, 'mount -o ro,bind', ... y los sockets son accesibles, pero se pueden filtar de varias maneras. Creo que hay por ahí un módulo para IPTABLES que permite filtrar los paquetes por usuario. Un chroot, un usuario específico para las pruebas de aplicaciones, un sistema de archivos tipo UnionFS, que escriba en un volumen distinto, filtros IPTABLES especiales para ese usuario, ... las posibilidades son múltiples.
Demasiada complicación para conseguir "sólo" aislamiento (y no también monitorización de la actividad de la aplicación, algo que por lo que veo no cubre ningúna aplicación orientada a usuario, sino herramientas dispares y que necesitan cierta familiaridad/habilidad en el manejo como tripwire, tcpdump, strace... e incluso gdb).
En otras palabras, que al final voy a acabar tirando por la opción inicial de usar una VM: tendré el entorno más aislado, aunque sin tool de monitorización/rastreo de lo que hace una aplicación dada.
Cualquier opción necesita su propio espacio. A mayor seguridad, mayor espacio requerido para proporcionar a la aplicación un entorno más 'aislado'. La aplicación puede leer las librerías compartidas del sistema, o proporcionarle unas propias. Si utilizas copias de librerias, se necesita espacio para ellas. Si utilizar las librerías del entorno 'real', asegurate de que no pueda escribir en ellas. Si no puede escribir en ellas, asegurate de que si puede escribir en aquellos sitios en los que lo necesite (típicamente, /home). Resumiendo: si la seguridad es prioritária, utiliza una VM. Prioridad a la seguridad implica no importar el espacio utilizado. Si el espacio es prioritario, no esperes una seguridad inflanqueable. Bueno, esto da para un libro. Espero haber ayudado algo.
Si maquetas todo este correo, creo que te da para el primer tomo :P Muchas gracias por tu tiempo. Salut, jors -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
