[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Sandbox de uso sencillo para aplicaciones de Escritorio



El Mon, 12 Aug 2013 11:31:12 -0500
Carlos Zuniga <carlos.zun@gmail.com> escribió:
> 2013/8/12 jors <jors@enchufado.com>:
> > On 12/08/13 17:06, Carlos Zuniga wrote:
> >>
> >> 2013/8/11 jors<jors@enchufado.com>:
> >>>
> >>> Buenas lista,
> >>>
> >>> ¿Alguien conoce alguna aplicación de sandboxing para apps de
> >>> Escritorio (en
> >>> realidad, que soporte cualquier app)? En mis dias de Windows
> >>> recuerdo usaba
> >>> Sandboxie [1] y me gustaba, y me temo no hay nada o no he sabido
> >>> encontrar
> >>> nada parecido en Linux (concretamente en Debian GNU/Linux).

> >>
> >> Y cual es tu objetivo? Evitar que la aplicación modifique o cree
> >> archivos en tu usuario?
> >
> >
> > Idealmente que no cree/modifique nada. Y si lo hace, que sea sobre
> > archivos temporales que no son en realidad los del sistema.
> >
> >
> >> Tal vez sería más sencillo simplemente crear otro usuario de
> >> prueba y correrla ahí.
> >
> >
> > Si por lo que sea se ejecuta una aplicación maliciosa que consigue
> > sobrepasar las barreras estandar del sistema para ese usuario (p.ej.
> > aprovechando un bug en alguna aplicación), la jodimos.
> >
> 
> Entonces concuerdo con los demás listeros que te recomiendan usar una
> máquina virtual.
> 
> > Además, idealmente la aplicación no tendría que poder cambiar nada
> > y sin embargo creer que sí lo hizo. ¿Algún desarrollador se anima
> > con un soft de sandboxing de este tipo? :D
> >
> 
> Eso suena similar a lo que hace fakeroot, utiliza un wrapper sobre las
> llamadas al sistema para hacer creer a la aplicación que tiene los
> permisos necesarios, si piensas hacer una aplicación, podrías ver como
> lo hacen ellos. Y creo que es un método similar el que utiliza
> SandboxIE.
> 
> Para lo de los cambios a los ficheros, sobre la VM podrías simplemente
> sacar un md5 a todos los ficheros y ver cuales han cambiado tras
> correr la aplicación, o algo más elaborado sería crear un repositorio
> git y ver un diff de los cambios.
> 
> 
> Saludos

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.

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, ...

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.

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.


Reply to: