Re: [OT] Sandbox de uso sencillo para aplicaciones de Escritorio
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
Reply to: