ClubEnsayos.com - Ensayos de Calidad, Tareas y Monografias
Buscar

Sandoox


Enviado por   •  30 de Abril de 2020  •  Apuntes  •  2.591 Palabras (11 Páginas)  •  132 Visitas

Página 1 de 11

INTRODUCCIÓN

La protección del sistema operativo y los datos del usuario de aplicaciones no confiables ha sido un problema importante en la seguridad informática. Incluso un usuario no técnico tendría dificultades para evitar escuchar pautas como "tenga cuidado con los archivos adjuntos de correo electrónico desconocidos". El problema con los archivos adjuntos de correo electrónico desconocidos es doble: en el caso de un archivo adjunto ejecutable, la aplicación adjunta generalmente puede hacer todo lo que los propios usuarios pueden hacer. Sin embargo, incluso los archivos adjuntos que parecen ser seguros, es decir, aquellos que generalmente no contienen código ejecutable, pueden causar problemas si logran explotar una falla en el programa utilizado para inspeccionar el archivo. Abrir una foto maliciosa en una aplicación de visualización de imágenes confiable pero vulnerable podría resultar en la ejecución de código no confiable.

La razón por la cual tales pautas son necesarias es un aislamiento insuficiente de las aplicaciones y capacidades predeterminadas demasiado amplias de los programas. Los usuarios a menudo pueden descargar y ejecutar programas de origen desconocido, que, a su vez, tienen amplias capacidades para inspeccionar y compartir datos personales del usuario. Debido a la falta de restricciones, incluso los programas que son nominalmente seguros pueden convertirse en maliciosos mediante ataques de inyección de código. ¿Por qué el mencionado visor de imágenes debería tener acceso, por ejemplo, al correo electrónico del usuario? Lo que claramente se necesita es una forma más precisa de limitar las capacidades otorgadas a las aplicaciones. Esta necesidad de una mejor gestión de lo que las aplicaciones pueden y no pueden hacer ha creado un campo completo de diferentes soluciones y tecnologías de aislamiento. Las soluciones abarcan desde la virtualización de sistema completo tradicional hasta mecanismos que dependen de componentes personalizados a nivel de kernel y cajas de arena que funcionan completamente en el espacio del usuario. En este documento, examinamos la investigación existente sobre soluciones de sandboxing por aplicación y discutimos los mecanismos que se utilizan para la contención de la aplicación. Nuestro enfoque principal son las implementaciones que proporcionan lo que Lietal. [10] llame a la protección unidireccional, es decir, protegen el sistema operativo y los datos del usuario de la aplicación contenida, pero no intentan proteger la aplicación del sistema operativo.

IMPLEMENTACIONES

Janus

Janus [4, 7, 17] fue una de las primeras soluciones de sandboxing basadas en interposición de llamadas del sistema. Si bien las primeras versiones del proyecto eran exclusivas de Solaris debido a su mejor soporte para el seguimiento de llamadas del sistema, las versiones posteriores del proyecto agregaron soporte para Linux con la ayuda de un módulo de kernel personalizado que amplía las políticas de decisión estándar. qué llamadas del sistema permitir se definen mediante archivos de configuración.

Cada directiva de configuración hace referencia a un módulo de política particular que implementa la lógica para decidir si se debe permitir o no una llamada particular al sistema. Por defecto, todas las llamadas al sistema son denegadas. Como ejemplo, el módulo de ruta podría usarse para denegar o permitir ciertas llamadas al sistema relacionadas con el archivo 10 en función de las rutas de archivo. Con base en las experiencias obtenidas de la implementación del sistema, los autores han discutido [5] los desafíos asociados con la implementación de un sistema de pruebas basado en interposición de llamadas de sistema.

Ostia

Donde la mayoría de los sandboxes encuestados se basan en el filtrado de llamadas del sistema desde la aplicación sandboxed, Ostia [6] introduce una alternativa arquitectónica basada en la delegación de llamadas del sistema. Al delegar la arquitectura, el proceso de espacio aislado no realiza las llamadas del sistema, sino que las realiza un agente externo y los resultados se transfieren de nuevo a la aplicación de espacio aislado. Según los autores, este cambio de diseño simplifica el sistema y lo protege de las disputas, ya que los argumentos se transfieren al agente. Ostia se implementa como un pequeño módulo de kernel y un componente de espacio de usuario.

El módulo del kernel es responsable de evitar que el programa de espacio aislado ejecute directamente cualquier llamada insegura del sistema. En cambio, el módulo del núcleo invoca una devolución de llamada colocada dentro del espacio de direcciones del proceso de espacio aislado. La devolución de llamada luego transforma la solicitud de llamada del sistema en una llamada IPC al agente. El agente, a su vez, recibe las solicitudes de llamada del sistema y, después de decidir si se debe permitir la llamada del sistema, ejecuta la solicitud y devuelve los resultados a través del enlace IPC. Sin embargo, es digno de mención que no todas las llamadas al sistema tienen que pasar por el proceso de delegación: algunas llamadas al sistema siempre se pueden permitir mientras que otras siempre se rechazan.

Consh

Consh [2] es un proyecto de sandboxing que reutiliza componentes de Janus pero extiende su funcionalidad con un sistema de archivos virtualizado. Consh apunta a Solaris y se implementa completamente en el espacio del usuario y no requiere privilegios de superusuario. El núcleo de Consh es Catcher, su sistema de canalización de llamadas de interposición. Catcher maneja las llamadas al sistema realizadas por el proceso de espacio aislado, que puede enrutarlas secuencialmente a través de una serie de pasos de procesamiento. Cada paso del proceso puede realizar operaciones arbitrarias basadas en la llamada y sus argumentos y antes de pasar la llamada posiblemente transformada a los pasos posteriores. Uno de esos pasos es el motor de decisión de Janus. Como último paso del proceso de procesamiento de llamadas del sistema, Janus puede rechazar cualquier formulación de llamadas del sistema producida por los pasos anteriores. Lo que separa a Consh de Janus es su capacidad de proporcionar procesos de espacio aislado con una vista virtualizada del sistema de archivos. Esto se logra a través de un paso de canalización que transforma las llamadas relacionadas con el sistema de archivos. En un nivel conceptual, este enfoque para proporcionar acceso virtualizado al sistema de archivos coloca a Consh más cerca de MBOX, una implementación de sandbox más reciente. Esta capacidad de proporcionar vistas virtualizadas del sistema de archivos se utiliza para presentar aplicaciones con un sistema de archivos inicialmente vacío que el usuario puede expandir selectivamente. Además, Consh proporciona acceso a los recursos de red a través de la misma abstracción del sistema de archivos. Se puede usar un directorio especial para acceder a los puntos finales HTTP y FTP mediante operaciones regulares del sistema de archivos.

...

Descargar como (para miembros actualizados)  txt (17 Kb)   pdf (123 Kb)   docx (180 Kb)  
Leer 10 páginas más »
Disponible sólo en Clubensayos.com