¿Qué es el sandboxing?

Una "caja de arena" es un área de juego para niños pequeños: se supone que es seguro para ellos (no pueden lastimarse) y a salvo para ellos (es arena, no pueden romperla) . En el contexto de la seguridad de TI, "sandboxing" significa aislar una parte del software de tal manera que haga lo que haga, no causará estragos en otros lugares.

Una forma común de sandboxing en Unix es el comando chroot (que utiliza la llamada al sistema chroot() ). Un proceso iniciado con este comando solo ve un subdirectorio (lo que ve como la raíz del sistema de archivos, el '/' , es ese subdirectorio). El sistema FreeBSD tiene una versión mejorada . Las soluciones más modernas y completas utilizan máquinas virtuales (como en VMWare ). Este tipo de sandboxing está destinado a la contención de daños: pones un proceso determinado en una cárcel porque, en caso de que sea hackeado, por ejemplo, un desbordamiento de búfer, el atacante todavía está en la cárcel y no podrá afectar a otras aplicaciones que se ejecutan en El mismo sistema.

Otro tipo de sandboxing es el que se encuentra en el núcleo de los lenguajes de programación como Java o C # (también conocido como "máquina virtual"): el código de la aplicación se ejecuta en una CPU virtual en la que se comprueba cada código de operación en busca de violaciones. (búfer se desborda y se desborda, no coincide el tipo ...). La estructura de los idiomas y la máquina virtual se han diseñado para que estas comprobaciones no sean demasiado caras. Una vez más, esto es la contención de daños, pero con una granularidad más fina.

El sandboxing no elimina las vulnerabilidades; simplemente reduce las consecuencias de esas vulnerabilidades (por ejemplo, transformar un shell remoto en un bloqueo remoto). Un desbordamiento de búfer es un error, independientemente de si una máquina virtual lo atrapa o no.

Bien, primero, ¿cómo se ejecutan las aplicaciones?

En un sistema operativo estándar del tipo que probablemente esté usando en este momento, los usuarios inician las aplicaciones. Cuando se inicia una aplicación, se carga en la memoria y se le da tiempo para que se ejecute en la CPU.

Para poder hacer las cosas, en lugar de controlar directamente el hardware de la computadora, la aplicación realiza solicitudes del sistema operativo. Los desarrolladores llaman a estas llamadas al sistema, o llamadas a la API. Esencialmente, todo lo que hace un programa es una operación en su propia memoria o una llamada al sistema para hacer otra cosa.

Ahora, obviamente, no podemos simplemente cargar aplicaciones y dejar que hagan nada, porque de lo contrario los usuarios podrían hacer cualquier cosa. Por lo tanto, el sistema operativo que está utilizando ahora tiene un concepto de permisos. Cuando se realiza una llamada al sistema, el sistema operativo mira el contexto de la aplicación, ¿quién lo está ejecutando? - y los permisos sobre el recurso en cuestión. Digo recurso en lugar de archivo porque regedt32 le permitirá establecer permisos en las claves de registro y solo la raíz puede abrir sockets debajo del puerto 1024 en Linux.

Entonces, ¿qué puede hacer una aplicación? Cualquier cosa que puedas hacer. Claramente, esto está bien para el explorador de Windows, pero digamos que descarga otro programa, como un convertidor de pdf a sonido (solo una sugerencia aleatoria). No estás seguro si confías en "Ninefingerz-so-l33t-man", el desarrollador que lo implementó, pero si lo ejecutas, tiene acceso a todo lo que haces.

El sandboxing de aplicaciones se trata de prevenir eso en algún nivel. Herramientas como sandboxie o Sandbox de SELinux enganche esas llamadas al sistema operativo y controle a un nivel más detallado lo que puede hacer ese programa. Por ejemplo, puede permitir que el programa edite cualquier cosa bajo C:\Users\Ninefingers\temporaryisolateddata pero en todos los demás sitios es de solo lectura. Puede evitar que realice conexiones salientes en sockets o que lea el registro en absoluto.

Por supuesto, esa no es la única forma (enganchando el kernel) de implementar un sandbox. La zona de pruebas de Google Chrome en Windows se implementa por completo a través del programa: el proceso maestro de google chrome controla lo que el niño procesa. Se puede acceder, en pocas palabras. Esta zona de pruebas funciona aprovechando los controles de seguridad existentes en Windows, y solo permite que el proceso hijo se comunique de nuevo con el proceso de destino cuando desea realizar una acción que normalmente lograría mediante una llamada al sistema. De esta manera, el proceso de destino realiza el filtrado de solicitudes.

En su núcleo, el sandboxing de la aplicación tiene que ver con restricciones adicionales para evitar que procesos potencialmente maliciosos dañen su sistema. Es una extensión del modelo de permisos existente.

Tenga en cuenta que el control de acceso obligatorio, una función disponible en algunos sistemas operativos, debe, si se implementa correctamente, un entorno limitado, de acuerdo con quién es el usuario y cuál es el proceso.

El sandboxing es un mecanismo para el control del flujo de información. Al ejecutar algún código en un arenero, obtienes control adicional sobre las entradas y salidas del programa. Eso significa que puede denegar / mediar el acceso a datos externos u otros recursos en caso de que el programa de espacio aislado esté comprometido o sea malicioso.

A menudo, se incluye un entorno de ejecución complejo en el entorno limitado, por ejemplo, las bibliotecas Java y Java en el caso de entornos limitados basados en JVM. O puede ejecutar una aplicación dentro de una máquina virtual dedicada, lo que lo convierte en una caja de arena para usted con un sistema operativo heredado completo como entorno de ejecución.

Que yo sepa, la tecnología de vanguardia de sandbox para la ejecución de x86 se describe en el Java Native Client de Google: enlace

El concepto de control de flujo de información es esencial para el diseño de seguridad. Todo lo relacionado con los privilegios y MAC en Linux tiene que ver con el control del flujo de información. En consecuencia, DJB señala en su artículo "Algunas reflexiones sobre la seguridad después de diez años de qmail 1.0" que el flujo de información y las interfaces son sustanciales y que el "privilegio mínimo" no es más que una distracción. Sin embargo, no usó espacios aislados explícitos como una JVM completa, usó la funcionalidad estándar del sistema operativo para dividir qmail en varios programas pequeños con interfaces explícitas y bien definidas. Y, de hecho, las cajas de arena son, por diseño, no mucho más que una replicación / ajuste fino / mejora de lo que el sistema operativo (OS) debería darle.