EXEMPLE : Le KVM/370 était une version sécurité-augmentée du moniteur virtuel de machine d'IBM VM/370. Ce système a fourni les machines virtuelles pour ses utilisateurs, et un de ses buts était d'empêcher des communications entre les machines virtuelles de différentes classes de sécurité, ainsi les utilisateurs dans différentes classes de sécurité pourraient employer le système en même temps. Comme VM/370, il a fourni aux machines virtuelles des minidisks et a permis à des systèmes de partager quelques secteurs de disque. À la différence de VM/370, il a employé une politique de sécurité pour négocier l'accès aux secteurs partagés du disque pour limiter des communications entre les systèmes.

EXEMPLE : Karger et collègues à la Digital Equipment Corporation Ont développé un moniteur virtuel de machine (VMM) pour le DEC VAX. Le moniteur est un grain de sécurité et peut exploiter le VMS ou le logiciel d'exploitation d'Ultrix. Les courses VMM sur le matériel indigène de VAX et est appelées toutes les fois que la machine virtuelle exécute une instruction privilégiée. Sa structure est typique des machines virtuelles conçues pour fournir la sécurité.

Le VAX a quatre niveaux de privilège : utilisateur, surveillant, directeur, et modes de grain. Afin de fournir une machine virtuelle compatible, les machines virtuelles doivent également avoir quatre niveaux de privilège. Cependant, le mode de grain permet à un processus d'accéder à des instructions privilégiées sur le matériel de VAX directement. On permet seulement Au le VMM de faire ceci. Les machines virtuelles ne peuvent pas accéder au mode de grain. La solution est de fournir des modes virtuels. Ces modes sont utilisateur de VM (correspondant au mode d'utilisateur), mode de surveillant de VM, et directeur de VM et des modes de grain de VM (les deux le mode réellement exécutif).

Les sujets VMM sont des utilisateurs et des machines virtuelles. VMM a un système de fichiers de base et plat pour son usage personnel et des cloisons l'espace disque restant parmi les machines virtuelles. Ces machines peuvent employer n'importe quelle structure de dossier qu'elles désirent, et chaque machine virtuelle a son propre ensemble de systèmes de fichiers. Chaque sujet et objet fait former une étiquette à multiniveaux de sécurité et d'intégrité, et les niveaux de sécurité et d'intégrité une classe d'accès. Deux entités ont la même classe d'accès si et seulement si leur sécurité et des étiquettes d'intégrité sont identique, et une entité domine des autres si et seulement si les classes de sécurité et d'intégrité dominent.

Un composant intégral du VMM est un mécanisme apurant. Ce mécanisme enregistre des actions pour l'analyse postérieure.

EXEMPLE : Le grain opérationnel du mur à l'épreuve du feu de Sidewinder emploie le type application pour confiner des processus. C'est un exemple d'un sandbox établi dans un grain, et il a la propriété que le sandbox est défini par le fournisseur. On ne le prévoit pas pour être changé à l'emplacement. Une telle conception est typique pour un système clés en main, qui est l'utilisation prévue pour un mur à l'épreuve du feu de Sidewinder.

La machine virtuelle de Java, en laquelle a téléchargé des applet sont exécutées, sont un autre exemple d'un sandbox. Le sandbox limite l'ensemble de dossiers aux lesquels l'applet peut accéder et des centres serveurs auxquels l'applet peut se relier. D'autres mécanismes de sécurité augmentent le sandbox.

DTE, le type mécanisme d'application pour DTEL, est un exemple dans lequel les modifications de grain permettent à des interfaces gestionnaire de configurer leurs propres sandboxes. Le grain impose les contraintes.

EXEMPLE : Janus met en application un sandbox. C'est un environnement d'exécution dans lequel des appels de système sont emprisonnés et vérifiés. Les utilisateurs l'exécutent pour limiter les objets et les modes de l'accès de l'untrusted le programme. Janus se compose d'un cadre, qui fait la vérification d'exécution, et des modules, qui déterminent quels accès doivent être laissés.

Janus lit d'abord un dossier de configuration. Ce dossier lui demande pour charger certains modules. Avec le module l'identification est une liste de contraintes. Le dossier suivant de configuration d'exemple définit les Statistiques financière internationale de variable d'environnement pour l'enfant et limite l'accès de l'enfant au système de fichiers. L'enfant ne peut accéder à aucun dossiers excepté ceux qui sont appelés ci-dessous. L'enfant peut lire ou écrire à n'importe quel dossier dans le système de fichiers de /usr excepté ceux dans le /usr/lib et les annuaires de /usr/local/lib (qui sont lus seulement) et dans /usr/bin (lu et s'exécuter). L'enfant peut lire n'importe quel dossier dans l'annuaire de /lib et peut lire et exécuter n'importe quel dossier dans les annuaires de /sbin et de /bin. Dans le dossier de configuration ci-dessous, le premier mot dans chaque ligne d'instruction est le nom du module et les autres mots sont les arguments passés aux modules ("#" commence un commentaire).

# module de base de base

# définissez le putenv IFS="\t\n" 
PATH=/sbin:/bin:/usr/bin TZ=PST8PDT de variables d'environnement de 
sous-processus

# niez l'accès à tout à moins que les dossiers 
sous le chemin de /usr nient lu, écrivent * le chemin laissent 
indiqué, écrivent /usr/* # permettent au sous-processus de lire des 
dossiers dans des annuaires de bibliothèque # nécessaire pour le 
chemin dynamique de chargement laissent lisent /lib/* /usr/lib/* 
/usr/local/lib/* # nécessaire ainsi l'enfant peut exécuter des 
programmes que le chemin permettent indiqué, l'exec /sbin/* /bin/* 
/usr/bin/*

Chaque module contraint des appels de système. Le cadre utilise les modules pour établir une liste liée pour chaque appel surveillé de système. La liste définit des actions permises et rejetées. Une fois que cette liste a été construite, le cadre de Janus appelle le programme de telle manière que tous les appels surveillés de système soient emprisonnés.

Quand le programme exécute un appel surveillé de système, les pièges de programme et le cadre de Janus est appelés. Il a accès aux arguments fournis à l'appel de sysem. Il valide qu'on permet l'appel de système, avec ces paramètres spécifiques. Si on ne permet pas l'appel de système, le cadre place l'environnement de l'enfant de sorte que l'appel de système semble avoir échoué. Si on permet l'appel de système, le cadre renvoie la commande à l'enfant, qui passe alternativement la main au grain. Sur le retour, la commande va au cadre, qui met à jour n'importe quel état interne et renvoie les résultats à l'enfant.

Une utilisation d'exemple serait dans le courrier de MIME de lecture. On pourrait avoir placé le programme de lecture de courrier pour passer la main à un moteur d'affichage de post-scriptum. Quelques tels moteurs ont un mécanisme pour exécuter des commandes au niveau système incluses dans le dossier de post-scriptum. Par conséquent, un attaquant a pu mettre une commande de suppression de dossier dans le dossier de post-scriptum. Le destinataire courrait le moteur d'affichage pour lire le dossier, et une partie d'elle des dossiers serait supprimée. Cependant, l'utilisateur (ou l'interface gestionnaire) peut installer le dossier de configuration de Janus rejettent l'exécution de tous les sous-programmes. La commande incluse sera détectée (à l'appel de système pour l'exécuter) et alors rejetée.