EJEMPLO: El KVM/370 era una versión seguridad-realzada del monitor virtual de la máquina de la IBM VM/370. Este sistema proporcionó las máquinas virtuales para sus usuarios, y una de sus metas era prevenir comunicaciones entre las máquinas virtuales de diversas clases de la seguridad, así que los usuarios en diversas clases de la seguridad podrían utilizar el sistema en el mismo tiempo. Como VM/370, proveió de las máquinas virtuales los minidisks y permitió que los sistemas compartieran algunas áreas del disco. Desemejante de VM/370, utilizó una política de la seguridad para mediar el acceso a las áreas compartidas del disco para limitar comunicaciones entre los sistemas.

EJEMPLO: Karger y los colegas en la Digital Equipment Corporation Desarrollaron un monitor virtual de la máquina (VMM) para la DEC VAX. El monitor es un núcleo de la seguridad y puede funcionar el VMS o el sistema operativo de Ultrix. Los funcionamientos VMM en el hardware nativo de VAX y se invocan siempre que la máquina virtual ejecute una instrucción privilegiada. Su estructura es típica de las máquinas virtuales diseñadas para proporcionar seguridad.

El VAX tiene cuatro niveles de privilegio: usuario, supervisor, ejecutivo, y modos del núcleo. Para proporcionar una máquina virtual compatible, las máquinas virtuales deben también tener cuatro niveles de privilegio. Sin embargo, el modo del núcleo permite que un proceso tenga acceso a instrucciones privilegiadas en el hardware de VAX directamente. Solamente el VMM se permite hacer esto. Las máquinas virtuales no pueden tener acceso a modo del núcleo. La solución es proporcionar modos virtuales. Estos modos son usuario de la VM (que corresponde al modo del usuario), modo del supervisor de la VM, y ejecutivo de la VM y los modos del núcleo de la VM (ambos el modo realmente ejecutivo).

Los temas VMM son usuarios y máquinas virtuales. VMM tiene un sistema del fichero básico, "plano" para su propio uso y particiones la espacio de disco restante entre las máquinas virtuales. Esas máquinas pueden utilizar cualquier estructura de archivo que deseen, y cada máquina virtual tiene su propio sistema de sistemas de ficheros. Cada tema y objeto hace que una etiqueta de niveles múltiples de la seguridad y de la integridad, y los niveles de la seguridad y de la integridad forme una clase del acceso. Dos entidades tienen la misma clase del acceso si y solamente si su seguridad y las etiquetas de la integridad es igual, y una entidad domina otra si y solamente si las clases de la seguridad y de la integridad dominan.

Un componente integral de el VMM es un mecanismo de revisión. Este mecanismo registra las acciones para un análisis más último.

EJEMPLO: El núcleo operacional del cortafuego de Sidewinder utiliza el tipo aplicación para confinar procesos. Éste es un ejemplo de un sandbox construido en un núcleo, y tiene la característica que el sandbox es definido por el vendedor. No se piensa para ser alterado en el sitio. Tal diseño es típico para un sistema de llavero, que es el uso previsto para un cortafuego de Sidewinder.

La máquina virtual de Java, en la cual descargó los applet se ejecuta, es otro ejemplo de un sandbox. El sandbox restringe el sistema de los archivos a que el applet puede tener acceso y de los anfitriones con los cuales el applet puede conectar. Otros mecanismos de la seguridad realzan el sandbox.

El DTE, el tipo mecanismo de aplicación para DTEL, es un ejemplo en el cual las modificaciones del núcleo permiten a administradores de sistema configurar sus propios sandboxes. El núcleo hace cumplir los apremios.

EJEMPLO: Janus pone un sandbox en ejecucio'n. Es un ambiente de la ejecución en el cual se atrapan y se comprueban las llamadas del sistema. Los usuarios lo ejecutan para restringir los objetos y los modos del acceso del untrusted programa. Janus consiste en un marco, que hace la comprobación runtime, y los módulos, que se determinan qué accesos deben ser permitidos.

Janus primero lee un archivo de la configuración. Este archivo le manda para cargar ciertos módulos. Junto con el módulo la identificación es una lista de apremios. El archivo siguiente de la configuración del ejemplo define a IFS de la variable de entorno para el niño y restringe el acceso del niño al sistema de ficheros. El niño no puede tener acceso a ninguna archivos excepto los que se nombren abajo. El niño puede leer o escribir a cualquier archivo en el sistema de ficheros de /usr a excepción de ésos en el /usr/lib y los directorios de /usr/local/lib (que se leen solamente) y en /usr/bin (leído y ejecutarse). El niño puede leer cualquier archivo en el directorio de /lib y puede leer y ejecutar cualquier archivo en los directorios de /sbin y de /bin. En el archivo de la configuración abajo, la primera palabra en cada línea de instrucción es el nombre del módulo y las otras palabras son las discusiones pasadas a los módulos ("#" comienza un comentario).

# módulo básico básico

# defina el putenv IFS="\t\n" 
PATH=/sbin:/bin:/usr/bin TZ=PST8PDT de las variables de entorno del 
subprocess

# niegue el acceso a todo a menos que los archivos
debajo de la trayectoria de /usr nieguen leído, escriben * la 
trayectoria permite leído, escribe /usr/* # permiten que el 
subprocess lea archivos en directorios de biblioteca # necesitado para
la trayectoria dinámica del cargamento permiten leen /lib/* 
/usr/lib/* /usr/local/lib/* # necesitado así que el niño puede 
ejecutar los programas que la trayectoria permite leído, exec /sbin/*
/bin/* /usr/bin/*

Cada módulo obliga llamadas del sistema. El marco utiliza los módulos para construir una lista encadenada para cada llamada supervisada del sistema. La lista define acciones permitidas y rechazadas. Una vez que se haya construido esta lista, el marco de Janus invoca el programa de una manera tal que se atrapen todas las llamadas supervisadas del sistema.

Cuando el programa ejecuta una llamada supervisada del sistema, se invoca las trampas del programa y el marco de Janus. Tiene acceso a las discusiones provistas a la llamada del sysem. Valida que la llamada del sistema, con estos parámetros específicos, está permitida. Si la llamada del sistema no se permite, el marco fija el ambiente del niño de modo que la llamada del sistema aparezca haber fallado. Si se permite la llamada del sistema, el marco vuelve control al niño, que alternadamente pasa control al núcleo. En vuelta, el control va al marco, que pone al día cualquier estado interno y vuelve los resultados al niño.

Un uso del ejemplo estaría en correo del MIME de la lectura. Uno habría podido fijar el programa de la lectura del correo para pasar control a un motor de la exhibición de la posdata. Algunos tales motores tienen un mecanismo para ejecutar los comandos a nivel sistema encajados en el archivo de la posdata. Por lo tanto, un atacante podía poner un comando de la canceladura del archivo en el archivo de la posdata. El recipiente funcionaría el motor de la exhibición para leer el archivo, y suprimirían algo de ella los archivos. Sin embargo, el usuario (o el administrador de sistema) puede instalar el archivo de la configuración de Janus rechaza la ejecución de cualquier subprograma. Después el comando encajado será detectado (en la llamada del sistema para ejecutarlo) y rechazado.