Partager via

Comment le mécanisme d’intégrité est implémenté dans Windows Vista

  • Article

Le mécanisme d’intégrité Windows est utilisé de plusieurs façons dans Windows Vista. Son objectif main est de restreindre les autorisations d’accès des applications s’exécutant sous le même compte d’utilisateur qui sont moins fiables. Le mécanisme empêche le code moins fiable de modifier des objets à un niveau supérieur. La plupart des objets sous le contrôle du groupe Administrateurs ou du système ont une liste de contrôle d’accès discrétionnaire (DACL) qui accorde généralement une autorisation de contrôle total aux administrateurs et au système, ainsi qu’une autorisation de lecture et d’exécution aux utilisateurs authentifiés. Le répertoire Program Files pour les applications ou la ruche HKEY_LOCAL_MACHINE du Registre sont des exemples de ressources sous contrôle du groupe Administrateurs et du système. Le mécanisme d’intégrité n’améliore pas la sécurité des objets déjà correctement configurés pour empêcher différents comptes d’utilisateurs ou groupes d’y accéder. L’objectif principal du mécanisme d’intégrité est de traiter différentes autorisations pour les programmes d’accéder aux ressources sous le contrôle total du même principal de sécurité utilisateur.

Les ressources sous le contrôle du même principal de sécurité utilisateur qui ont besoin d’une protection supplémentaire se trouvent principalement sous le profil de l’utilisateur (répertoire C:\Users\<username> et HKEY_CURRENT_USER hive dans le Registre) et les programmes d’application en cours d’exécution pour le compte de cet utilisateur. Windows Vista utilise le mécanisme d’intégrité des manières suivantes.

  • Dans UAC, il limite l’accès entre les processus exécutés avec des privilèges utilisateur standard et les processus avec élévation de privilèges s’exécutant avec des droits d’administration complets en mode d’approbation Administration.
  • La sécurité COM est consciente des niveaux d’intégrité et n’autorise pas les clients à intégrité inférieure à se lier à des instances de classe s’exécutant à un niveau d’intégrité plus élevé.
  • Dans les paramètres de sécurité par défaut, il limite l’accès au dossier racine du volume système.
  • En mode protégé Explorer Internet, il limite la capacité du code en cours d’exécution dans le navigateur Internet à modifier les données utilisateur ou les paramètres de profil utilisateur.
  • Pour permettre aux applications s’exécutant à faible intégrité d’avoir un emplacement de fichier accessible en écriture, il affecte un niveau d’intégrité faible à des dossiers spécifiques dans le profil utilisateur.

Le mécanisme d’intégrité fait partie de l’architecture de sécurité de Windows Vista. Au fil du temps, des applications spécifiques qui gèrent des entrées non fiables (principalement accessibles sur Internet) sont mises à jour pour tirer parti de la possibilité de s’exécuter à un niveau d’intégrité faible. Les applications de productivité personnelle fonctionnent correctement à un niveau d’intégrité moyen tant que les utilisateurs connaissent la source des données d’entrée. Pour la plupart des applications, le mécanisme d’intégrité est entièrement transparent et n’interfère pas avec les fonctionnalités de l’application. Les services d’application peuvent être mis à jour pour mieux isoler les ressources serveur pour les processus clients à différents niveaux d’intégrité.

Niveaux d’intégrité et UAC

UAC dans Windows Vista exécute plusieurs programmes à différents niveaux d’accès sur le même bureau lors de l’utilisation du mode d’approbation Administration. Les programmes disposent de privilèges différents en fonction du jeton d’accès de sécurité affecté au processus lors de la création du processus. Les utilisateurs avec des comptes qui sont des utilisateurs standard n’ont qu’un seul jeton d’accès de sécurité créé lors de l’ouverture de session. Un niveau d’intégrité moyen est affecté au jeton d’accès utilisateur standard. Le jeton d’accès utilisateur standard d’intégrité moyenne est affecté à presque tous les processus d’application exécutés par l’utilisateur. Des applications spécifiques, telles que les Explorer Internet en mode protégé, constituent une exception décrite ci-dessous.

Les utilisateurs disposant de comptes membres du groupe Administrateurs ont deux jetons d’accès de sécurité créés lors de l’ouverture de session qui sont liés. Un jeton d’accès est un jeton d’accès utilisateur standard affecté à un niveau d’intégrité moyen, auquel le groupe Administrateurs est utilisé uniquement pour les vérifications de refus d’accès, et certains privilèges administratifs sont supprimés. Le deuxième jeton d’accès est un jeton d’accès à privilèges complets avec élévation de privilèges qui se voit attribuer un niveau d’intégrité élevé, car le groupe Administrateurs et les privilèges d’administration sont présents dans le jeton d’accès. Les jetons d’accès sont liés, car ils sont liés à la même ouverture de session interactive pour ce compte d’utilisateur. Les deux jetons d’accès ont le même SID utilisateur et les mêmes groupes globaux d’Active Directory (à l’exception des groupes filtrés pour domaine et entreprise Administration).

Le Explorer Windows (également appelé shell) et toutes les tâches non-administrateur se voient attribuer le jeton d’accès d’intégrité moyenne utilisateur standard. Pour le compte d’utilisateur membre du groupe Administrateurs, presque toutes les applications sont exécutées avec le jeton d’accès d’intégrité moyenne. La stratégie d’intégrité NO_WRITE_UP ne limite pas les autorisations d’accès des processus de niveau moyen aux objets qui ont une étiquette d’objet medium implicite obligatoire. Le mécanisme d’intégrité est transparent pour les applications à un niveau d’intégrité moyen, sauf s’ils sont conçus pour contrôler d’autres processus qui peuvent s’exécuter à un niveau de privilège supérieur. Windows UI Automation est un exemple d’application conçue pour contrôler d’autres processus.

Le mode d’approbation Administration UAC permet à l’utilisateur de lancer des tâches d’administration et des applications après avoir donné son consentement avec le jeton d’accès avec privilèges élevés. Le système d’exploitation doit restreindre la capacité du processus à privilège inférieur (utilisateur standard) à falsifier directement le processus à privilèges plus élevés (administrateur) s’exécutant sous le même SID utilisateur. Le mécanisme d’intégrité Windows limite les autorisations d’accès que le processus d’intégrité moyenne peut avoir sur le processus à intégrité élevée. Le gestionnaire de processus (qui fait partie du noyau Windows) attribue les options de stratégie obligatoires NO_READ_UP et NO_WRITE_UP pour empêcher les processus à intégrité inférieure d’ouvrir un processus à intégrité supérieure pour l’accès en lecture ou en écriture.

Le processus à intégrité inférieure n’a qu’un accès d’exécution générique. L’accès d’exécution générique comprend les éléments suivants :

  • SYNCHRONIZE, PROCESS_QUERY_LIMITED_INFORMATION
  • PROCESS_TERMINATE

L’accès en lecture générique à un processus d’intégrité supérieure (PROCESS_VM_READ accès à la mémoire virtuelle d’un processus et PROCESS_QUERY_INFORMATION) est limité pour empêcher les processus à privilèges inférieurs d’obtenir un accès en lecture à la mémoire qui peut contenir des données de mot de passe ou d’autres éléments clés utilisés pour l’authentification. L’accès en écriture générique au processus à intégrité supérieure est bloqué par la stratégie de NO_WRITE_UP. Les droits d’accès au processus d’écriture générique sont les suivants :

  • PROCESS_CREATE_THREAD
  • PROCESS_VM_OPERATION
  • PROCESS_VM_WRITE
  • PROCESS_DUP_HANDLE
  • PROCESS_SET_QUOTA
  • PROCESS_SET_INFORMATION
  • PROCESS_SET_PORT

Ruche du registre des utilisateurs actuels

La plupart des objets du profil utilisateur ne se voient pas attribuer d’étiquette obligatoire explicite et ont donc un niveau d’intégrité par défaut implicite de medium. Cela s’applique à la ruche HKEY_CURRENT_USER (HKCU) du registre. Les clés créées sous HKCU ont un niveau d’intégrité moyen implicite. Cela signifie que, pour les utilisateurs membres du groupe Administrateurs, la ruche HKCU est accessible en écriture par les applications s’exécutant avec un jeton d’accès utilisateur standard d’intégrité moyenne ou le jeton d’accès administrateur complet à haute intégrité. Cela doit être le cas pour des raisons de compatibilité des applications. Rappelez-vous que la ruche HKEY_LOCAL_MACHINE (HKLM) dispose d’une stratégie de sécurité par défaut qui accorde aux administrateurs et au système un contrôle total, ainsi que l’accès en lecture et exécution aux utilisateurs. La ruche HKLM est modifiable uniquement par des processus avec élévation de privilèges auxquels le jeton d’accès administrateur complet est attribué. La ruche HKLM n’est pas protégée par une étiquette obligatoire élevée.

Étant donné que le niveau d’intégrité par défaut pour les objets qui n’ont pas d’étiquette obligatoire explicite est moyen, il est clair que les utilisateurs membres du groupe Administrateurs peuvent exécuter des programmes à différents niveaux de privilège (moyen et élevé) qui partagent des données HKCU et de profil utilisateur. Windows Vista n’applique pas de limite stricte entre les processus d’intégrité moyenne et d’intégrité élevée. Le processus de haute intégrité est autorisé à « lire ». Il est courant pour les applications qui s’exécutent avec un jeton d’accès à haute intégrité à privilèges complets de lire les informations de configuration à partir de HKCU ou d’accepter des fichiers d’entrée qui affectent le comportement du processus de haute intégrité. Les applications qui s’exécutent avec des privilèges complets doivent utiliser HKLM pour stocker des informations de configuration modifiables uniquement par les administrateurs. Les applications à privilèges complets doivent également vérifier que les données d’entrée utilisateur sont bien formées avant de traiter les fichiers modifiables par l’utilisateur.

COM prend en compte l’intégrité

COM est l’infrastructure permettant de créer des composants d’application et des services d’objet. L’infrastructure COM est consciente du niveau d’intégrité d’un client appelant CoCreateInstance et du processus serveur exécutant une classe instance. Les domaines de la fonctionnalité COM où les niveaux d’intégrité influencent le comportement sont les suivants :

  • Le moniker d’élévation COM permet aux clients de lancer des services élevés à un niveau d’intégrité élevé une fois que l’administrateur a donné son consentement, ou un utilisateur standard fournit des informations d’identification d’administrateur explicites.
  • Les classes de serveur qui s’exécutent avec élévation de privilèges au-dessus du niveau d’intégrité moyen doivent avoir le CLSID défini dans la ruche du Registre HKLM.
  • COM empêche les clients à un niveau d’intégrité inférieur de se lier à des instances de serveurs en cours d’exécution à un niveau d’intégrité plus élevé, sauf si le serveur autorise par programmation l’accès à partir de clients inférieurs.

Le moniker d’élévation COM permet aux applications à un niveau d’intégrité faible ou moyen de lancer des services COM dans un processus s’exécutant avec des droits élevés à une intégrité élevée. Le moniker d’élévation permet des tâches spécifiques conçues pour s’exécuter avec élévation de privilèges et non destinées à une compatibilité complète des applications. L’élévation COM est intégrée à l’élévation UAC. Le processus de serveur COM avec élévation de privilèges se voit attribuer un jeton d’accès avec privilèges élevés avec une intégrité élevée. COM n’autorise pas les clients d’un niveau inférieur à se lier à un instance en cours d’exécution du serveur à un niveau d’intégrité plus élevé.

Si un serveur COM est conçu pour prendre en charge les connexions à partir de clients à faible intégrité, le serveur peut modifier par programmation les autorisations de lancement/activation dans le Registre pour le CLSID afin d’autoriser la liaison à partir d’un client à intégrité inférieure. COM utilise la stratégie obligatoire NO_EXECUTE_UP dans une ace d’étiquette obligatoire pour contrôler si les clients sont autorisés à établir une liaison à un serveur instance à un niveau d’intégrité plus élevé. Les autorisations d’accès lancement/activation COM sont mappées aux droits d’accès d’exécution génériques dans le GENERIC_MAPPING utilisé par COM pour vérifier l’activation. Le niveau d’intégrité dans une étiquette obligatoire associée à l’objet identifie le niveau d’intégrité le plus bas d’un client autorisé à établir une liaison au serveur. À l’instar de l’accès au système de fichiers, la stratégie obligatoire implicite par défaut permet aux clients d’intégrité moyenne de se lier aux serveurs.

Pour les serveurs COM conçus pour permettre à un client à faible intégrité de se lier à un instance du serveur, les autorisations d’activation COM sont définies par le code du serveur.

Pour permettre à un client à faible intégrité de se lier au serveur

  1. Définissez une étiquette obligatoire avec une stratégie de NO_EXECUTE_UP (NX) pour un niveau d’intégrité faible. Le SDDL pour le descripteur de sécurité d’objet avec la stratégie d’étiquette obligatoire pour une faible intégrité est le suivant :

    O:BAG:BAD:(A;;0xb;;;WD)S:(ML;;NX;;;LW)

  2. Convertissez le descripteur de sécurité de chaîne en descripteur de sécurité binaire.

  3. Définissez les autorisations de lancement pour le CLSID du serveur à l’aide du descripteur de sécurité binaire.

L’interface utilisateur de sécurité COM, dcomcfg.exe, ne prend pas en charge les niveaux d’intégrité.

Des exemples de code pour définir une stratégie obligatoire d’autorisation de lancement COM sont disponibles dans Ressources du mécanisme d’intégrité Windows pour plus d’informations sur la prise en charge de COM et de niveau d’intégrité.

Le niveau d’intégrité du système est attribué aux services

Service Control Manager (SCM) démarre les processus de service à l’aide d’un compte de service spécial ou d’un nom d’utilisateur et d’un mot de passe. Les comptes de service spéciaux sont LocalSystem, LocalService et NetworkService. Les services exécutés sous l’un de ces comptes de service disposent de privilèges spéciaux, tels que le privilège SE_IMPERSONATE_NAME qui permet au service d’effectuer des actions lors de l’emprunt d’identité d’autres utilisateurs. Windows Vista affecte un niveau d’intégrité système à l’objet de processus pour les services exécutés sous l’un des comptes de service spéciaux. L’image suivante de Process Explorer montre le niveau d’intégrité système affecté au jeton d’accès pour les comptes de service spéciaux.

Figure 6 Niveau d’intégrité du système pour les services

Bien que le processus de service ait un niveau d’intégrité système, les objets sécurisables créés par ces sujets ne se voient pas attribuer d’étiquette obligatoire système. Les objets créés par les services (à l’exception des processus enfants, des threads, des jetons d’accès et des travaux) ont un niveau d’intégrité moyen implicite.

Les modifications de service pour Windows Vista décrivent les modifications apportées aux services afin d’améliorer la sécurité, la fiabilité et la facilité de gestion. Les modifications apportées aux services améliorent la sécurité du système en isolant les services dans la session 0 et en isolant les ressources auxquelles les services peuvent accéder à l’aide des SID de service. Le niveau d’intégrité du système pour les comptes de service spéciaux est cohérent avec les objectifs d’isolation du service. Les processus de service exécutés au niveau de l’intégrité du système sont protégés contre l’accès à un par un processus d’intégrité inférieure. Les droits d’accès aux processus qui sont disponibles pour les processus à intégrité inférieure pour ouvrir un processus de service sont limités aux éléments suivants :

  • SYNCHRONIZE
  • PROCESS_QUERY_LIMITED_INFORMATION
  • PROCESS_TERMINATE

Certaines applications sont conçues à l’aide de plusieurs processus coopératifs qui peuvent s’exécuter dans un ou plusieurs comptes de service. La plupart des mécanismes de communication interprocessus (IPC) entre les processus et les services, tels que RPC, ne sont pas limités par le niveau d’intégrité. Les services doivent être particulièrement prudents pour valider les entrées des clients à faible intégrité.

Handles dupliqués entre les services

Les applications de service utilisant plusieurs processus sont parfois conçues pour dupliquer des handles vers des objets, tels que des fichiers, entre des processus serveur. Si tous les processus s’exécutent sous le même compte de service spécial, la sécurité par défaut sur les processus de service n’introduit pas de restrictions. La liste DACL par défaut sur les processus de service exécutés sous des comptes de service spéciaux n’accorde pas l’accès PROCESS_DUP_HANDLE, ce qui est requis pour les appels DuplicateHandle. Les concepteurs de services d’application doivent implémenter des fonctionnalités pour accorder PROCESS_DUP_HANDLE accès à l’objet de processus de service à un autre compte d’utilisateur utilisé par un coprocesseur afin de partager des handles entre des processus d’application qui s’exécutent sous différents comptes d’utilisateur. Toutefois, si le service dans lequel vous souhaitez dupliquer le handle est un compte de service spécial s’exécutant à un niveau d’intégrité système, un co-processus s’exécutant à un niveau d’intégrité élevé ou moyen ne pourra pas obtenir PROCESS_DUP_HANDLE en raison de la stratégie d’étiquette obligatoire. Même si la liste dacl accorde PROCESS_DUP_HANDLE accès, la stratégie d’étiquette obligatoire n’autorise pas les appelants à faible intégrité à accéder à cet accès. Si cette situation affecte la conception de l’application de service, le code du service d’application doit être modifié afin que le processus qui lance DuplicateHandle soit à un niveau d’intégrité supérieur au niveau d’intégrité du processus qui est la source du handle. Autrement dit, un service à intégrité plus élevée peut dupliquer un handle dans son propre processus en tant que cible à partir d’un processus à faible intégrité en tant que source de handle.

Stratégie d’emprunt d’identité

Le privilège SE_IMPERSONATE_NAME permet à un processus serveur d’emprunter l’identité du contexte de sécurité d’un processus client. Le privilège Emprunt d’identité est un privilège puissant. Le mécanisme d’intégrité associe le privilège d’emprunt d’identité à des jetons d’accès qui ont un niveau d’intégrité élevé ou système. Le mécanisme d’intégrité applique la stratégie selon laquelle un sujet peut emprunter l’identité d’un client à un niveau d’intégrité plus élevé, uniquement s’il dispose du privilège Emprunter l’identité.

Un scénario dans lequel cette restriction de stratégie s’applique serait lorsqu’un processus à faible intégrité usurpe l’interface utilisateur pour persuader un utilisateur administrateur d’entrer des informations d’identification d’administrateur. Le code malveillant utilise les informations d’identification pour appeler LsaLogonUser et ImpersonateLoggedOnUser pour tenter de lancer un processus à un niveau de privilège supérieur. La stratégie de mécanisme d’intégrité pour les jetons d’accès d’emprunt d’identité est que le niveau d’intégrité du jeton d’accès retourné par LsaLogonUser ne doit pas être supérieur au niveau d’intégrité du processus appelant.

Dossier racine à un niveau d’intégrité élevé

Le dossier racine de la partition système, généralement C:\ a toujours été utilisé comme emplacement pratique pour stocker des programmes ou des fichiers temporaires, bien que la pratique ne soit pas encouragée. Les programmes d’installation qui nécessitent des privilèges d’administrateur sont souvent copiés dans le dossier racine avant d’être lancés. La stratégie de sécurité par défaut pour le dossier racine est conçue pour permettre aux utilisateurs authentifiés de créer des sous-dossiers sous le dossier racine, mais autoriser uniquement les administrateurs à créer des fichiers dans le dossier racine. En outre, dans l’idéal, la stratégie n’autorise pas les utilisateurs non administratifs à modifier les fichiers du dossier qui ont été créés par les administrateurs. Cette stratégie est difficile à définir en utilisant uniquement la liste de contrôle d’accès pour le dossier racine.

En définissant une étiquette obligatoire avec un niveau d’intégrité élevé qui s’applique aux objets enfants, mais pas aux conteneurs enfants, la sécurité par défaut du dossier racine répond à cette stratégie. Les utilisateurs standard qui exécutent des programmes à un niveau d’intégrité moyen ne peuvent pas modifier les fichiers créés par les administrateurs dans le dossier racine, même si la liste de contrôle d’accès accorde aux utilisateurs l’accès à la modification. Le dossier racine a une étiquette obligatoire pouvant être héritée à haute intégrité, qui est héritée par l’objet et qui ne se propage pas aux sous-dossiers.

L’image suivante montre les paramètres de sécurité par défaut sur le C:\ le dossier racine, y compris l’objet, héritent de l’étiquette obligatoire à une intégrité élevée. Le tableau 9 présente les définitions des abréviations dans l’image.

Tableau 9 Abréviations d’image

Abréviation Définition

(OI)

L’objet hérite

(NP)

Aucune propagation

(E/S)

Hériter uniquement

(NW)

Aucune écriture en cours

Figure 7 Étiquette obligatoire sur le dossier racine

Mode protégé Explorer Internet à faible intégrité

Internet Explorer est un exemple d’application conçue pour accepter des données arbitraires et du code extensible provenant d’Internet. Étant donné que la source de contenu Internet est rarement authentifiée (signée), nous devons supposer que toutes les entrées provenant d’Internet ne sont pas fiables. Les attaques contre les Explorer Internet, ou contre tout autre navigateur Internet, démontrent la nature peu fiable du contenu dynamique et des données disponibles à partir d’Internet. Du point de vue de la sécurité, nous partons du principe que le processus de Explorer Internet lui-même est compromis et non approuvé, et nous recherchons des solutions qui limitent les dommages potentiels causés par les attaques sur le navigateur. Certaines solutions proposées aux attaques basées sur un navigateur tentent d’isoler complètement le navigateur web des autres applications et données. Malheureusement, l’isolation complète du navigateur a un impact significatif sur l’expérience de navigation de l’utilisateur, comme la possibilité de démarrer automatiquement des programmes pour lire différents types de fichiers, comme les fichiers .pdf. L’isolation complète entrave les expériences utilisateur courantes, telles que le chargement d’images sur des sites Web, si le navigateur n’a pas accès en lecture aux fichiers de données utilisateur.

L’objectif de l’Explorer Internet en mode protégé est de réduire les droits d’accès disponibles pour le processus, afin de limiter la capacité d’un exploit s’exécutant dans le navigateur à créer des fichiers de démarrage indésirables, à modifier les fichiers de données utilisateur, à apporter des modifications ennuyeuses aux paramètres de configuration du navigateur ou à piloter le comportement d’autres programmes exécutés sur le bureau. Tout le code exécuté en mode protégé Explorer Internet dans un processus à faible intégrité est considéré comme non fiable. Le niveau d’intégrité moyen par défaut pour les objets empêche le navigateur d’ouvrir des répertoires, des fichiers ou des clés de Registre pour l’accès en écriture, à l’exception de ceux qui sont explicitement étiquetés à faible intégrité. UIPI empêche le code du navigateur à faible intégrité d’envoyer des messages de fenêtre potentiellement nuisibles à d’autres applications qui s’exécutent sur le bureau.

Le navigateur qui s’exécute à faible intégrité dispose d’un accès en lecture aux fichiers de données utilisateur. Étant donné que le mécanisme d’intégrité Windows n’applique pas la confidentialité, il ne restreint pas le flux d’informations. Le processus peut également utiliser les informations d’identification par défaut pour établir des connexions réseau, par exemple à un serveur proxy réseau (nécessaire lorsque l’authentification est requise pour se connecter à Internet) ou à un périphérique d’imprimante réseau pour imprimer une page web. Le processus de faible intégrité peut également initier une connexion authentifiée à d’autres services réseau et ainsi s’authentifier auprès de ces serveurs en tant qu’utilisateur actuel.

La conception de l’application d’Internet Explorer a nécessité une restructuration pour s’exécuter en mode protégé à un niveau d’intégrité faible. La principale modification est que certaines opérations de programme ont été déplacées vers un processus distinct, appelé processus de répartiteur, exécuté à un niveau d’intégrité moyen. Le processus du répartiteur démarre à un niveau d’intégrité moyen lorsque l’utilisateur clique sur l’icône de Explorer Internet ou sur un lien URL. Le répartiteur vérifie l’URL et la stratégie de zone et lance un processus enfant, iexplore.exe, au niveau d’intégrité faible pour établir la connexion Internet et afficher la page web. L’image suivante de Process Explorer montre le ieuser.exe, le processus broker au niveau d’intégrité moyen et le processus iexplore.exe au niveau d’intégrité faible.

Figure 8 Processus de Explorer Internet en mode protégé

Tout ce que l’utilisateur rencontre dans internet Explorer navigateur web est effectué à l’intérieur du processus de faible intégrité. Quelques opérations spécifiques, telles que la modification des paramètres Options Internet ou la boîte de dialogue Enregistrer sous fichier, sont gérées par le processus broker. Si l’URL est un site approuvé, en fonction des paramètres de stratégie de zone par défaut, le processus broker démarre une autre instance de iexplore.exe dans un processus d’intégrité moyenne. Toutes les extensions de navigateur et les contrôles ActiveX s’exécutent dans le processus de faible intégrité. Cela présente l’avantage que toute exploitation potentielle d’une extension de navigateur s’exécute également à faible intégrité.

Internet Explorer est un peu plus compliqué que d’autres applications, car il héberge des extensions de navigateur et des contrôles ActiveX qui ne sont pas développés par Microsoft, il lance d’autres applications basées sur des types mime pour différentes extensions de fichier et intègre la fenêtre cliente à partir de différentes applications dans un cadre de fenêtre parente unique. Les utilisateurs téléchargent également des logiciels à partir d’Internet via le navigateur et lancent immédiatement un package d’application ou un programme d’installation d’application. La plupart de ces opérations nécessitent l’aide du processus broker à un niveau d’intégrité plus élevé pour assurer la médiation par l’utilisateur afin de confirmer une opération. Sinon, le code en cours d’exécution dans le navigateur peut installer des logiciels malveillants sur le système et essayer de modifier ou de supprimer les données de l’utilisateur. L’installation des contrôles ActiveX est effectuée à l’aide d’une tâche avec élévation de privilèges démarrée par le contrôle d’utilisateur qui nécessite des droits d’administrateur.

Étant donné que les Explorer Internet prennent en charge un large éventail d’interactions utilisateur entre le navigateur et d’autres applications locales (copier-coller en est un exemple évident), le mécanisme d’intégrité qui limite l’accès en écriture aux objets n’est pas un mécanisme d’isolation complet. La conception de l’internet en mode protégé Explorer examiné de nombreuses interactions différentes et a spécifiquement adapté le comportement du répartiteur et du processus d'iexplore.exe à faibles droits pour maintenir les fonctionnalités de privilèges minimum tout en offrant une expérience utilisateur riche et hautement collaborative.

Pour plus d’informations sur les Explorer Internet en mode protégé, consultez Comprendre et travailler en mode protégé internet Explorer (https://go.microsoft.com/fwlink/?LinkId=90931).