Verificamos de forma exhaustivamente cada uno de los posts de nuestro sitio web con el objetivo de mostrarte en todo momento la información más veraz y actualizada.
Solución:
Una “caja de arena” es un área de juego para niños pequeños: se supone que es segura para ellos (no pueden lastimarse) y segura. de ellos (es arena, no pueden romperla). En el contexto de la seguridad de TI, “sandboxing” significa aislar alguna pieza de software de tal manera que, haga lo que haga, no propagará el caos en otros lugares.
Una forma común de Unix de sandboxing es el chroot comando (que usa el chroot() llamada al sistema). Un proceso iniciado con este comando ve solo 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 espacio aislado está destinado a la contención de daños: pone un proceso determinado en una cárcel porque en caso de que sea pirateado, 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 # (confusamente también llamado “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 (desbordamientos de búfer y subdesbordamientos, desajustes de tipos …). La estructura de los lenguajes y VM se ha diseñado para que estas comprobaciones no sean demasiado caras. De nuevo, se trata de 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, la transformación de 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, en primer lugar, ¿cómo se ejecutan las aplicaciones?
En un sistema operativo estándar del tipo que probablemente esté utilizando 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 hacer las cosas, en lugar de controlar el hardware de la computadora directamente, la aplicación realiza solicitudes al sistema operativo. Los desarrolladores llaman a estas llamadas al sistema o llamadas API. Básicamente, 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 cualquier cosa, porque de lo contrario los usuarios podrían hacer cualquier cosa. Entonces, el sistema operativo que está usando 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 la ejecuta? – y los permisos sobre el recurso en cuestión. Digo recurso en lugar de archivo porque regedt32 le permitirá establecer permisos en el registro keys y solo root puede abrir sockets por debajo del puerto 1024 en Linux.
Entonces, ¿qué puede hacer una aplicación? Todo lo que puedas hacer. Claramente, esto está bien para, por ejemplo, el explorador de Windows, pero digamos que descarga otro programa, como un convertidor de PDF a sonido (solo una sugerencia aleatoria). No está seguro de si confía en “Ninefingerz-so-l33t-man”, el desarrollador que lo implementó, pero si lo ejecuta, tiene acceso a todo lo que hace.
El sandboxing de aplicaciones se trata de prevenir eso en algún nivel. Herramientas como sandboxie o SELinux sandbox enganchan esas llamadas al sistema operativo y controlan a un nivel más detallado lo que ese programa puede hacer. Por ejemplo, puede permitir que el programa edite cualquier cosa en C:UsersNinefingerstemporaryisolateddata pero en todos los demás lugares es de solo lectura. Puede evitar que realice conexiones salientes en sockets o que lea el registro.
Por supuesto, esa no es la única forma (enganchar el kernel) de implementar una caja de arena. La caja de arena de Google Chrome en Windows es implementada completamente por el programa: el proceso maestro de Google Chrome controla a qué pueden acceder los procesos secundarios, en pocas palabras. Esta caja de arena funciona explotando los controles de seguridad existentes en Windows, y solo permite que el proceso hijo se comunique con el proceso de destino cuando quiere tomar una acción que normalmente lograría a través de una llamada al sistema. De esta forma, el proceso de destino realiza el filtrado de solicitudes.
En esencia, el sandboxing de aplicaciones se trata de restricciones adicionales para evitar que los 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, debería, si se implementa correctamente, un espacio aislado de todo 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 algo de código en una caja de arena, obtiene 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 la caja de arena, por ejemplo, Java y bibliotecas de Java en el caso de las cajas de arena basadas en JVM. O puede ejecutar una aplicación dentro de una máquina virtual dedicada, convirtiéndola 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 caja de arena de última generación para la ejecución x86 se describe en Java Native Client de Google: http://research.google.com/pubs/pub34913.html
El concepto de control del flujo de información es esencial para el diseño de seguridad. Todo el asunto de 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ó sandboxes 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 no son, por diseño, mucho más que una réplica, un ajuste o una mejora de lo que el sistema operativo (debería) ofrecerle.
Reseñas y puntuaciones
Al final de la artículo puedes encontrar las notas de otros usuarios, tú igualmente puedes dejar el tuyo si dominas el tema.