Sécurité à plusieurs niveaux

La sécurité multiniveau ou les niveaux de sécurité multiples ( MLS ) sont l'application d'un système informatique pour traiter des informations avec des classifications incompatibles (c'est-à-dire à des niveaux de sécurité différents), permettre l'accès par des utilisateurs avec des autorisations de sécurité et des besoins de savoir différents , et empêcher les utilisateurs d'obtenir l'accès à des informations pour lesquelles ils ne sont pas autorisés. Il existe deux contextes pour l'utilisation de la sécurité multiniveau.

• Il s'agit de faire référence à un système capable de se protéger contre la subversion et doté de mécanismes robustes pour séparer les domaines d'information, c'est-à-dire digne de confiance.
• Un autre contexte est celui de faire référence à une application d'un ordinateur qui nécessitera que l'ordinateur soit suffisamment puissant pour se protéger de la subversion et qu'il possède des mécanismes adéquats pour séparer les domaines d'information, c'est-à-dire un système auquel nous devons faire confiance.

Cette distinction est importante car les systèmes auxquels il faut faire confiance ne sont pas nécessairement dignes de confiance.

Un environnement d'exploitation MLS nécessite souvent un système de traitement d'informations hautement fiable, souvent construit sur un système d'exploitation (OS) MLS, mais pas nécessairement. La plupart des fonctionnalités MLS peuvent être prises en charge par un système entièrement composé d'ordinateurs non fiables, bien qu'elles nécessitent plusieurs ordinateurs indépendants reliés par des canaux conformes à la sécurité matérielle (voir la section B.6.2 de l'interprétation des réseaux de confiance, NCSC-TG-005). Un exemple de MLS renforcé par le matériel est l'isolation asymétrique . Si un ordinateur est utilisé en mode MLS, cet ordinateur doit utiliser un système d'exploitation (OS) de confiance. Étant donné que toutes les informations d'un environnement MLS sont physiquement accessibles par le système d'exploitation, des contrôles logiques solides doivent exister pour garantir que l'accès aux informations est strictement contrôlé. Cela implique généralement un contrôle d'accès obligatoire qui utilise des étiquettes de sécurité, comme le modèle Bell-LaPadula .

Les clients qui déploient des systèmes d'exploitation fiables exigent généralement que le produit soit soumis à une évaluation formelle de la sécurité informatique. L'évaluation est plus stricte pour une plage de sécurité plus large, qui correspond aux niveaux de classification les plus bas et les plus élevés que le système peut traiter. Les critères d'évaluation des systèmes informatiques fiables (TCSEC) ont été les premiers critères d'évaluation développés pour évaluer les MLS dans les systèmes informatiques. Selon ces critères, il existait une correspondance uniforme claire entre les exigences de sécurité et l'étendue de la plage de sécurité MLS. Historiquement, peu d'implémentations ont été certifiées capables de traiter les MLS avec une plage de sécurité allant de Non classifié à Top Secret. Parmi elles, on trouve SCOMP de Honeywell , USAF SACDIN, Blacker de la NSA et MLS LAN de Boeing , toutes sous TCSEC, millésime 1980 et basées sur Intel 80386. Actuellement, les produits MLS sont évalués selon les critères communs . Fin 2008, le premier système d'exploitation (voir ci-dessous) a été certifié à un niveau d'assurance évalué élevé : Evaluation Assurance Level (EAL) - EAL 6+ / High Robustness, sous les auspices d'un programme du gouvernement américain exigeant une sécurité à plusieurs niveaux dans un environnement à haut risque. Bien que ce niveau d'assurance présente de nombreuses similitudes avec celui de l'ancien Orange Book A1 (comme les méthodes formelles), les exigences fonctionnelles se concentrent sur les politiques fondamentales d'isolation et de flux d'informations plutôt que sur les politiques de niveau supérieur telles que Bell-La Padula. Étant donné que les critères communs ont découplé l'association de l'assurance (EAL) et de la fonctionnalité (profil de protection) du TCSEC, la correspondance uniforme claire entre les exigences de sécurité et la capacité de la plage de sécurité MLS documentée dans la norme CSC-STD-004-85 a été en grande partie perdue lorsque les critères communs ont remplacé la série Rainbow .

Les systèmes d'exploitation disponibles gratuitement avec certaines fonctionnalités prenant en charge MLS incluent Linux avec la fonctionnalité Security-Enhanced Linux activée et FreeBSD . L'évaluation de la sécurité était autrefois considérée comme un problème pour ces implémentations MLS gratuites pour trois raisons :

1. Il est toujours très difficile de mettre en œuvre une stratégie d’autoprotection du noyau avec la précision nécessaire à la confiance MLS, et ces exemples n’ont pas été conçus ou certifiés pour un profil de protection MLS. Ils peuvent donc ne pas offrir l’autoprotection nécessaire pour prendre en charge MLS.
2. Outre les niveaux EAL, les Critères communs ne disposent pas d’un inventaire de profils de protection de haute assurance appropriés spécifiant la robustesse nécessaire pour fonctionner en mode MLS.
3. Même si (1) et (2) étaient respectés, le processus d’évaluation est très coûteux et impose des restrictions particulières sur le contrôle de la configuration du logiciel évalué.

Malgré ces suppositions, Red Hat Enterprise Linux 5 a été certifié contre LSPP, RBACPP et CAPP à l'EAL4+ en juin 2007. Il utilise Security-Enhanced Linux pour implémenter MLS et a été la première certification Common Criteria à appliquer les propriétés de sécurité TOE avec Security-Enhanced Linux.

Les stratégies de certification des fournisseurs peuvent être trompeuses pour les profanes. Une stratégie courante exploite l'importance excessive accordée par les profanes au niveau EAL avec une surcertification, comme la certification d'un profil de protection EAL 3 (comme CAPP) à des niveaux élevés, comme EAL 4 ou EAL 5. Une autre consiste à ajouter et à certifier des fonctionnalités de support MLS (telles que le profil de protection du contrôle d'accès basé sur les rôles (RBACPP) et le profil de protection de sécurité étiqueté (LSPP)) à un noyau qui n'est pas évalué selon un profil de protection compatible MLS. Ces types de fonctionnalités sont des services exécutés sur le noyau et dépendent du noyau pour les protéger de la corruption et de la subversion. Si le noyau n'est pas évalué selon un profil de protection compatible MLS, les fonctionnalités MLS ne sont pas fiables, quelle que soit l'impressionnante démonstration. Il est particulièrement intéressant de noter que CAPP n'est spécifiquement pas un profil compatible MLS car il exclut spécifiquement les capacités d'autoprotection essentielles pour MLS.

General Dynamics propose PitBull, un système d'exploitation MLS fiable. PitBull n'est actuellement proposé qu'en tant que version améliorée de Red Hat Enterprise Linux , mais des versions antérieures existaient pour Sun Microsystems Solaris, IBM AIX et SVR4 Unix. PitBull fournit un mécanisme de sécurité Bell LaPadula , un mécanisme d'intégrité Biba , un remplacement de privilège pour le superutilisateur et de nombreuses autres fonctionnalités. PitBull constitue la base de sécurité du produit Trusted Network Environment (TNE) de General Dynamics depuis 2009. TNE permet le partage et l'accès d'informations multiniveaux pour les utilisateurs des communautés du ministère de la Défense et du renseignement opérant à différents niveaux de classification. C'est également la base de l'environnement de partage de coalition multiniveau, le Battlefield Information Collection and Exploitation Systems Extended (BICES-X).

Sun Microsystems , aujourd'hui Oracle Corporation , propose Solaris Trusted Extensions comme fonctionnalité intégrée des systèmes d'exploitation commerciaux Solaris et OpenSolaris . En plus du profil de protection d'accès contrôlé (CAPP) et des profils de protection de contrôle d'accès basé sur les rôles (RBAC), Trusted Extensions a également été certifiée EAL4 pour le profil de protection de sécurité étiqueté (LSPP). La ​​cible de sécurité comprend à la fois les fonctionnalités de bureau et de réseau. LSPP exige que les utilisateurs ne soient pas autorisés à outrepasser les politiques d'étiquetage appliquées par le noyau et X Window System (serveur X11). L'évaluation n'inclut pas d' analyse de canal caché . Étant donné que ces certifications dépendent de CAPP, aucune certification Common Criteria ne suggère que ce produit soit digne de confiance pour MLS.

BAE Systems propose le XTS-400 , un système commercial qui prend en charge MLS avec ce que le fournisseur qualifie de « haute assurance ». Les produits précédents (y compris le XTS-300) ont été évalués au niveau TCSEC B3, qui est compatible MLS. Le XTS-400 a été évalué selon les critères communs à EAL5+ par rapport aux profils de protection CAPP et LSPP. CAPP et LSPP sont tous deux des profils de protection EAL3 qui ne sont pas intrinsèquement compatibles MLS, mais la cible de sécurité pour l'évaluation des critères communs de ce produit contient un ensemble enrichi de fonctions de sécurité qui offrent une capacité MLS.

La désinfection est un problème pour les systèmes MLS. Les systèmes qui implémentent des restrictions MLS, comme celles définies par le modèle Bell-LaPadula , n'autorisent le partage que s'il ne viole manifestement pas les restrictions de sécurité. Les utilisateurs ayant des autorisations inférieures peuvent facilement partager leur travail avec des utilisateurs ayant des autorisations supérieures, mais pas l'inverse. Il n'existe aucun mécanisme efficace et fiable permettant à un utilisateur Top Secret de modifier un fichier Top Secret, de supprimer toutes les informations Top Secret, puis de le transmettre aux utilisateurs ayant des autorisations Secret ou inférieures. En pratique, les systèmes MLS contournent ce problème via des fonctions privilégiées qui permettent à un utilisateur digne de confiance de contourner le mécanisme MLS et de modifier la classification de sécurité d'un fichier. Cependant, la technique n'est pas fiable .

Les canaux secrets posent un autre problème aux systèmes MLS. Pour qu'un système MLS conserve parfaitement les secrets, il ne doit pas exister de moyen possible pour un processus Top Secret de transmettre des signaux de quelque nature que ce soit à un processus Secret ou inférieur. Cela inclut les effets secondaires tels que les changements dans la mémoire ou l'espace disque disponible, ou les changements dans la synchronisation du processus. Lorsqu'un processus exploite un tel effet secondaire pour transmettre des données, il exploite un canal secret. Il est extrêmement difficile de fermer tous les canaux secrets dans un système informatique pratique, et cela peut être impossible dans la pratique. Le processus d'identification de tous les canaux secrets est en soi un défi. La plupart des systèmes MLS disponibles dans le commerce ne tentent pas de fermer tous les canaux secrets, même si cela rend leur utilisation peu pratique dans les applications de haute sécurité.

Le contournement est problématique lorsqu'il est utilisé comme moyen de traiter un objet de niveau système comme s'il était approuvé par le MLS. Un exemple courant consiste à extraire des données d'un objet de niveau système secret pour les envoyer vers une destination non classifiée, en citant une propriété des données comme preuve fiable qu'elles sont « vraiment » non classifiées (par exemple, un format « strict »). On ne peut pas faire confiance à un système de niveau système pour préserver une quelconque preuve fiable, et le résultat est qu'un chemin de données ouvert est ouvert sans aucun moyen logique de le médiatiser de manière sécurisée. Le contournement peut être risqué car, contrairement aux canaux secrets à bande passante étroite qui sont difficiles à exploiter, le contournement peut présenter une fuite ouverte importante et facilement exploitable dans le système. Le contournement résulte souvent de l'incapacité à utiliser des environnements d'exploitation approuvés pour maintenir une séparation continue des domaines de sécurité jusqu'à leur origine. Lorsque cette origine se trouve en dehors des limites du système, il peut ne pas être possible de valider la séparation approuvée jusqu'à l'origine. Dans ce cas, le risque de contournement peut être inévitable si le flux est vraiment essentiel.

Un exemple courant de contournement inévitable est un système sujet qui doit accepter des paquets IP secrets provenant d'une source non fiable, chiffrer les données utilisateur secrètes et non l'en-tête et déposer le résultat sur un réseau non fiable. La source se trouve en dehors de la sphère d'influence du système sujet. Bien que la source ne soit pas fiable (par exemple, au niveau du système), elle est approuvée comme s'il s'agissait d'un MLS car elle fournit des paquets qui ont des en-têtes non classifiés et des données utilisateur secrètes en texte clair, une construction de données MLS. Étant donné que la source n'est pas fiable, elle pourrait être corrompue et placer des secrets dans l'en-tête de paquet non classifié. Les en-têtes de paquet corrompus pourraient être absurdes, mais il est impossible pour le système sujet de le déterminer avec une fiabilité raisonnable. Les données utilisateur du paquet sont bien protégées cryptographiquement, mais l'en-tête du paquet peut contenir des secrets lisibles. Si les paquets corrompus sont transmis à un réseau non fiable par le système sujet, ils peuvent ne pas être routables, mais un processus corrompu coopérant dans le réseau pourrait récupérer les paquets et les accuser réception et le système sujet pourrait ne pas détecter la fuite. Il peut s'agir d'une fuite importante et manifeste, difficile à détecter. Le fait de considérer les paquets classifiés avec des en-têtes non classifiés comme des structures de niveau système au lieu des structures MLS qu'ils sont en réalité représente une menace très courante mais sérieuse.

La plupart des contournements sont évitables. Les contournements évitables surviennent souvent lorsque les architectes système conçoivent un système avant de prendre correctement en compte la sécurité, puis tentent d'appliquer la sécurité après coup sous forme de fonctions complémentaires. Dans cette situation, le contournement semble être le seul moyen (facile) de faire fonctionner le système. Certains schémas pseudo-sécurisés sont proposés (et approuvés !) qui examinent le contenu des données contournées dans une vaine tentative d'établir que les données contournées ne contiennent aucun secret. Cela n'est pas possible sans faire confiance à quelque chose concernant les données, comme leur format, ce qui est contraire à l'hypothèse selon laquelle la source n'est pas fiable pour préserver les caractéristiques des données sources. Le « contournement sécurisé » assuré est un mythe, tout comme le soi-disant High Assurance Guard (HAG) qui implémente le contournement de manière transparente. Le risque que ces solutions introduisent est reconnu depuis longtemps ; les solutions existantes sont en fin de compte procédurales, plutôt que techniques. Il n'existe aucun moyen de savoir avec certitude quelle quantité d'informations classifiées est extraite de nos systèmes par l'exploitation du contournement.

Certains profanes conçoivent des systèmes informatiques sécurisés et en concluent que le MLS n'existe pas. Une explication possible pourrait être qu'il y a un déclin du nombre d'experts COMPUSEC et que le terme MLS a été surchargé par deux significations/utilisations différentes. Ces deux utilisations sont : MLS en tant qu'environnement de traitement et MLS en tant que capacité. La croyance selon laquelle le MLS n'existe pas repose sur la conviction qu'il n'existe aucun produit certifié pour fonctionner dans un environnement ou un mode MLS et que, par conséquent, le MLS en tant que capacité n'existe pas. L'un n'implique pas l'autre. De nombreux systèmes fonctionnent dans un environnement contenant des données qui ont des niveaux de sécurité inégaux et sont donc MLS selon le théorème de la valeur intermédiaire de la sécurité informatique (CS-IVT). La conséquence de cette confusion est plus profonde. Les systèmes d'exploitation, bases de données et réseaux MLS certifiés par la NSA existent en mode opérationnel depuis les années 1970 et les produits MLS continuent d'être construits, commercialisés et déployés.

Les profanes concluent souvent qu'admettre qu'un système fonctionne dans un environnement MLS (au sens de MLS centré sur l'environnement) revient à se retrouver dans une situation où l'on a l'impression d'avoir un problème sans solution MLS (au sens de MLS centré sur les capacités). Le MLS est d'une complexité trompeuse et le fait que des solutions simples ne soient pas évidentes ne justifie pas la conclusion qu'elles n'existent pas. Cela peut conduire à une ignorance paralysante de COMPUSEC qui se manifeste par des rumeurs selon lesquelles « on ne peut pas parler de MLS » et « il n'existe pas de MLS ». Ces schémas de déni de MLS évoluent si rapidement qu'ils ne peuvent pas être abordés. Il est donc important de clarifier la distinction entre environnement MLS et capacité MLS.

• MLS comme environnement de sécurité ou mode de sécurité : une communauté dont les utilisateurs ont des autorisations de sécurité différentes peut percevoir MLS comme une capacité de partage de données : les utilisateurs peuvent partager des informations avec des destinataires dont l'autorisation permet la réception de ces informations. Un système fonctionne en mode MLS lorsqu'il a (ou pourrait avoir) une connectivité à une destination qui est autorisée à un niveau de sécurité inférieur à celui des données que contient le système MLS. Cela est formalisé dans le CS-IVT. La détermination du mode de sécurité d'un système dépend entièrement de l'environnement de sécurité du système ; de la classification des données qu'il contient, de l'autorisation de ceux qui peuvent obtenir un accès direct ou indirect au système ou à ses sorties ou signaux, et de la connectivité et des ports du système vers d'autres systèmes. Le mode de sécurité est indépendant des capacités, bien qu'un système ne doive pas être utilisé dans un mode pour lequel il n'est pas digne de confiance.
• MLS en tant que capacité : les développeurs de produits ou de systèmes destinés à permettre le partage de données MLS ont tendance à le percevoir vaguement en termes de capacité à appliquer des restrictions de partage de données ou une politique de sécurité, comme les mécanismes qui appliquent le modèle Bell-LaPadula . Un système est compatible MLS s'il peut être démontré qu'il met en œuvre de manière robuste une politique de sécurité.

L'utilisation originale du terme MLS s'appliquait à l'environnement ou au mode de sécurité. Une solution à cette confusion consiste à conserver la définition originale de MLS et à préciser la compatibilité MLS lorsque ce contexte est utilisé.

Les niveaux de sécurité indépendants multiples (MILS) sont une architecture qui prend en charge le composant de séparation de domaine de MLS. Notez que l'UCDMO (le chef de file du gouvernement américain pour les systèmes interdomaines et multiniveaux) a créé un terme d'accès interdomaine comme catégorie dans sa base de référence des systèmes accrédités par le DoD et la communauté du renseignement , et cette catégorie peut être considérée comme essentiellement analogue à MILS.

Les modèles de sécurité tels que le modèle Biba (pour l'intégrité) et le modèle Bell-LaPadula (pour la confidentialité) permettent un flux unidirectionnel entre certains domaines de sécurité qui sont par ailleurs supposés isolés. MILS traite l'isolement sous-jacent à MLS sans traiter l'interaction contrôlée entre les domaines traités par les modèles ci-dessus. Les canaux de sécurité fiables et conformes mentionnés ci-dessus peuvent relier les domaines MILS pour prendre en charge davantage de fonctionnalités MLS.

L'approche MILS poursuit une stratégie caractérisée par un terme plus ancien, MSL ( multiple single level ), qui isole chaque niveau d'information dans son propre environnement à niveau unique ( System High ).

La communication et l'isolation rigides des processus offertes par MILS peuvent être plus utiles aux applications logicielles à très haute fiabilité que MLS. MILS ne prend notamment pas en compte la structure hiérarchique incarnée par la notion de niveaux de sécurité. Cela nécessite l'ajout d'applications d'importation/exportation spécifiques entre les domaines, dont chacune doit être accréditée de manière appropriée. En tant que tel, MILS pourrait être mieux appelé Multiple Independent Domains of Security (l'émulation MLS sur MILS nécessiterait un ensemble similaire d'applications accréditées pour les applications MLS). En refusant de traiter l'interaction prête à l'emploi entre les niveaux cohérents avec les relations hiérarchiques de Bell-La Padula, MILS est (presque trompeusement) simple à mettre en œuvre initialement, mais nécessite des applications d'importation/exportation supplémentaires non triviales pour atteindre la richesse et la flexibilité attendues par les applications MLS pratiques.

Toute comparaison MILS/MLS doit déterminer si l'accréditation d'un ensemble d'applications d'exportation plus simples est plus réalisable que l'accréditation d'un noyau MLS plus complexe. Cette question dépend en partie de l'ampleur des interactions d'importation/exportation requises par les parties prenantes. Le MILS est peut-être en faveur de la possibilité que toutes les applications d'exportation ne nécessitent pas une assurance maximale.

Il existe une autre façon de résoudre ces problèmes, connue sous le nom de sécurité à niveaux multiples . Chaque niveau de sécurité est isolé dans un domaine distinct non approuvé. L'absence de moyen de communication entre les domaines garantit qu'aucune interaction n'est possible. Le mécanisme de cette isolation est généralement une séparation physique dans des ordinateurs distincts. Cela est souvent utilisé pour prendre en charge des applications ou des systèmes d'exploitation qui n'ont aucune possibilité de prendre en charge MLS, comme Microsoft Windows .

Les infrastructures telles que les systèmes d'exploitation de confiance sont un élément important des systèmes MLS, mais pour répondre aux critères requis par la définition de MLS par CNSSI 4009 (paraphrasée au début de cet article), le système doit fournir une interface utilisateur capable de permettre à un utilisateur d'accéder et de traiter du contenu à plusieurs niveaux de classification à partir d'un seul système. L'UCDMO a organisé un cours spécifiquement axé sur MLS lors du Symposium sur l'assurance de l'information de la NSA en 2009, au cours duquel elle a mis en avant plusieurs systèmes MLS accrédités (en production) et émergents. Notez l'utilisation de MLS dans SELinux .

Il existe plusieurs bases de données classées comme systèmes MLS. Oracle possède un produit appelé Oracle Label Security (OLS) qui implémente des contrôles d'accès obligatoires , généralement en ajoutant une colonne « étiquette » à chaque table d'une base de données Oracle . OLS est déployé au sein de l' INSCOM de l'armée américaine comme base d'une base de données de renseignement « toutes sources » couvrant les réseaux JWICS et SIPRNet . Il existe un projet visant à créer une version étiquetée de PostgreSQL, et il existe également des implémentations de bases de données étiquetées plus anciennes telles que Trusted Rubix. Ces systèmes de base de données MLS fournissent un système back-end unifié pour le contenu couvrant plusieurs étiquettes, mais ils ne résolvent pas le problème de permettre aux utilisateurs de traiter le contenu à plusieurs niveaux de sécurité dans un seul système tout en appliquant des contrôles d'accès obligatoires.

Il existe également plusieurs applications MLS pour les utilisateurs finaux. L'autre fonctionnalité MLS actuellement sur la base de l'UCDMO s'appelle MLChat Archivé le 17 mars 2013 sur la Wayback Machine , et il s'agit d'un serveur de chat qui fonctionne sur le système d'exploitation XTS-400 - il a été créé par le laboratoire de recherche navale américain . Étant donné que le contenu des utilisateurs de différents domaines passe par le serveur MLChat, l'analyse des mots grossiers est utilisée pour protéger le contenu classifié, et il y a eu un débat pour savoir s'il s'agit vraiment d'un système MLS ou plutôt d'une forme de protection des données de transfert inter-domaines . Les contrôles d'accès obligatoires sont maintenus par une combinaison de mécanismes XTS-400 et spécifiques à l'application.

Joint Cross Domain eXchange (JCDX) est un autre exemple de capacité MLS actuellement sur la base de l'UCDMO . JCDX est le seul système de commandement, de contrôle, de communication, d'informatique et de renseignement (C4I) multiniveaux de sécurité (MLS) accrédité par le ministère de la Défense (DoD) et la Defense Intelligence Agency (DIA) qui fournit un soutien en temps quasi réel en matière de renseignement et d'alerte aux commandants tactiques déployés sur le théâtre et à l'avant. L'architecture JCDX est entièrement intégrée à un système d'exploitation sécurisé de niveau de protection quatre (PL4) à haut niveau d'assurance, utilisant l'étiquetage des données pour diffuser des informations en temps quasi réel sur les activités des forces et les menaces terroristes potentielles sur et autour des océans du monde. Il est installé sur des sites aux États-Unis et dans les pays partenaires alliés où il est capable de fournir des données allant du niveau Top Secret/SCI au niveau Secret-Releasable, le tout sur une seule plate-forme.

Les applications MLS qui ne font pas actuellement partie de la base de référence UCDMO incluent plusieurs applications de BlueSpace . BlueSpace possède plusieurs applications MLS, notamment un client de messagerie MLS, une application de recherche MLS et un système MLS C2. BlueSpace s'appuie sur une stratégie middleware pour permettre à ses applications d'être indépendantes de la plate-forme, orchestrant une interface utilisateur sur plusieurs instances du système d'exploitation Windows (sessions de terminal virtualisées ou distantes ). Le laboratoire de recherche navale américain a également mis en œuvre un framework d'application Web multiniveau appelé MLWeb qui intègre le framework Ruby on Rails avec une base de données multiniveau basée sur SQLite3 .

Le plus grand changement qui se produit aujourd'hui dans le domaine de la sécurité multiniveau est peut-être la convergence de MLS avec la virtualisation. Un nombre croissant de systèmes d'exploitation fiables s'éloignent de l'étiquetage des fichiers et des processus et se tournent plutôt vers les conteneurs UNIX ou les machines virtuelles . On peut citer comme exemples les zones de Solaris 10 TX et l' hyperviseur à cellules rembourrées de systèmes tels que la plateforme Integrity de Green Hill et XenClient XT de Citrix. La plateforme High Assurance de la NSA telle qu'implémentée dans l'environnement de virtualisation de confiance (TVE) de General Dynamics est un autre exemple : elle utilise SELinux en son cœur et peut prendre en charge les applications MLS qui s'étendent sur plusieurs domaines.