Conception du mécanisme d’intégrité Windows

Article
07/05/2007

Le mécanisme d’intégrité Windows est une extension de l’architecture de sécurité Windows, qui est basée sur le Moniteur de référence de sécurité dans le noyau. Le moniteur de référence de sécurité applique le contrôle d’accès en comparant les SID d’utilisateur et de groupe dans le jeton d’accès de sécurité avec les autorisations d’accès accordées dans la liste de contrôle d’accès du descripteur de sécurité d’un objet. Le mécanisme d’intégrité ajoute un niveau d’intégrité au jeton d’accès de sécurité et une entrée de contrôle d’accès d’étiquette obligatoire à l’ACL système (SACL) dans le descripteur de sécurité.

Les principales parties du mécanisme d’intégrité sont les suivantes :

Niveaux d’intégrité prédéfinis et leur représentation.
Stratégies d’intégrité qui limitent les autorisations d’accès.
Niveau d’intégrité attribué au jeton d’accès de sécurité.
Entrée de contrôle d’accès d’étiquette obligatoire.
Étiquettes obligatoires affectées aux objets.
Restrictions d’intégrité dans les API AccessCheck et SeAccessCheck en mode noyau.

Chacune de ces parties est décrite plus en détail ci-dessous. Le mécanisme d’intégrité Windows est toujours en vigueur, indépendamment des autres options de stratégie de sécurité. Les vérifications de niveau d’intégrité, comme les vérifications de contrôle d’accès, ne sont pas facultatives. Il n’existe aucune option de stratégie de sécurité pour désactiver les vérifications de niveau d’intégrité. Bien que le mécanisme d’intégrité prenne en charge l’UAC, le mécanisme d’intégrité reste en vigueur lorsque l’UAC est désactivée par stratégie de groupe de sécurité.

Niveaux d’intégrité

Windows définit les niveaux d’intégrité à l’aide d’un SID. L’utilisation d’un SID pour représenter un niveau d’intégrité facilite l’intégration du mécanisme d’intégrité dans les structures de données de sécurité existantes sans nécessiter de modifications de code. Les SID de niveau intégrité ont la forme suivante : S-1-16-xxxx. Le tableau 1 présente les composants des SID de niveau d’intégrité.

Tableau 1 Valeurs d’autorité de l’identificateur SID de niveau d’intégrité

Valeur	Description
16	Représente l’autorité d’étiquette obligatoire (SECURITY_MANDATORY_LABEL_AUTHORITY).
xxxx	Représente le champ d’identificateur relatif (RID) qui est le niveau d’intégrité. Le RID est une valeur hexadécimale qui représente le niveau d’intégrité.

Il existe quatre niveaux d’intégrité principaux dans Windows Vista avec quatre valeurs correspondantes. Une valeur inférieure indique un niveau d’intégrité inférieur ou un niveau de fiabilité inférieur. Ces valeurs sont définies dans le fichier d’en-tête winnt.h. Le tableau 2 montre les niveaux d’intégrité définis et leurs valeurs correspondantes.

Tableau 2 Niveaux d’intégrité définis et valeurs correspondantes

Valeur	Description	Symbole
0x0000	Niveau non approuvé	SECURITY_MANDATORY_UNTRUSTED_RID
0x1000	Faible niveau d’intégrité	SECURITY_MANDATORY_LOW_RID
0x2000	Niveau d’intégrité moyen	SECURITY_MANDATORY_MEDIUM_RID
0x3000	Niveau d’intégrité élevé	SECURITY_MANDATORY_HIGH_RID
0x4000	Niveau d’intégrité du système	SECURITY_MANDATORY_SYSTEM_RID

Un exemple de SID de niveau d’intégrité moyen est cette chaîne : S-1-16-8192. La valeur RID de 8192 est l’équivalent décimal de 0x2000.

Les RID sont séparés par des intervalles de 0x1000 pour permettre la définition de niveaux supplémentaires à l’avenir. La séparation permet également d’attribuer un niveau d’intégrité à un processus légèrement supérieur à moyen , par exemple, pour répondre à des objectifs de conception de système spécifiques.

Les SID de niveau d’intégrité définis ont des valeurs de nom de chaîne qui leur sont associées. L’utilisation de l’API LookupAccountSID retourne des noms de chaîne pour chaque SID de niveau d’intégrité. Le tableau 3 montre les noms de chaîne pour les niveaux d’intégrité.

Tableau 3 Noms de chaînes de niveau intégrité

SID de niveau d’intégrité	Nom
S-1-16-4096	Étiquette obligatoire\Niveau obligatoire faible
S-1-16-8192	Étiquette obligatoire\Niveau obligatoire moyen
S-1-16-12288	Étiquette obligatoire\Niveau obligatoire élevé
S-1-16-16384	Étiquette obligatoire\Niveau obligatoire du système

Les niveaux d’intégrité sont également définis en tant que chaînes SID dans le langage SDDL (Security Descriptor Definition Language). Le SDDL définit le format de chaîne utilisé par les fonctions ConvertSecurityDescriptorToStringSecurityDescriptor et ConvertStringSecurityDescriptorToSecurityDescriptor pour décrire un descripteur de sécurité en tant que chaîne de texte. Le langage définit également des éléments de chaîne pour décrire des informations dans les composants d’un descripteur de sécurité. L’utilisation du SDDL pour définir les niveaux d’intégrité facilite la définition du niveau d’intégrité d’un objet lors de la création de l’objet. Pour plus d’informations sur les chaînes SID pour les niveaux d’intégrité, consultez Ressources du mécanisme d’intégrité Windows. La prise en charge de SDDL pour les étiquettes obligatoires est décrite dans l’Annexe A : SDDL pour les étiquettes obligatoires.

Windows Vista utilise des SID de niveau d’intégrité dans le jeton d’accès de sécurité pour représenter le niveau d’intégrité de l’objet et utilise des SID de niveau d’intégrité dans l’étiquette obligatoire ACE dans un descripteur de sécurité pour représenter le niveau d’intégrité de l’objet.

Stratégies d’intégrité

Le mécanisme d’intégrité Windows utilise des stratégies simples pour déterminer comment utiliser les étiquettes obligatoires sur les objets afin de restreindre le niveau d’accès disponible pour les sujets à intégrité inférieure. Cela signifie que les stratégies limitent le type d’accès que les objets de niveau d’intégrité inférieur sont autorisés à avoir aux objets de niveau d’intégrité supérieur. Le tableau 4 présente les deux catégories de stratégies.

Tableau 4 Catégories de stratégie d’intégrité

Catégorie	Description
Stratégies obligatoires de jeton d’accès	Définissez dans le jeton d’accès et déterminez comment les stratégies obligatoires s’appliquent à l’objet, qui est représenté dans le jeton d’accès.
Stratégies d’étiquette obligatoires	Définissez dans l’étiquette obligatoire ACE (décrit ci-dessous) sur les objets et déterminez comment restreindre l’accès à l’objet.

Les stratégies d’intégrité sont utilisées lorsque la case activée de stratégie obligatoire est effectuée lors de l’évaluation des autorisations d’accès sur un objet sécurisable. Les stratégies déterminent la façon dont les droits d’accès sont restreints entre les niveaux d’intégrité.

Stratégies de jeton d’accès obligatoires

Le tableau 5 présente les stratégies de jeton d’accès obligatoires définies dans Windows Vista.

Tableau 5 Stratégies de jeton d’accès obligatoire dans Windows Vista

Stratégie	Description
TOKEN_MANDATORY_NO_WRITE_UP	Stratégie par défaut affectée à tous les jetons d’accès. La stratégie limite l’accès en écriture par ce sujet à tout objet à un niveau d’intégrité supérieur.
TOKEN_MANDATORY_NEW_PROCESS_MIN	Contrôle le comportement de l’affectation du niveau d’intégrité aux processus enfants. Normalement, un processus enfant hérite du niveau d’intégrité du processus parent lorsque le jeton d’accès du processus parent est affecté à l’enfant. Avec la stratégie NEW_PROCESS_MIN, le niveau d’intégrité du processus enfant est le niveau d’intégrité minimal du jeton d’accès parent ou du niveau d’intégrité de l’objet du fichier exécutable pour le nouveau processus. Cette stratégie est définie par défaut dans tous les jetons d’accès.

TOKEN_MANDATORY_NO_WRITE_UP

Stratégie par défaut affectée à tous les jetons d’accès. La stratégie limite l’accès en écriture par ce sujet à tout objet à un niveau d’intégrité supérieur.

TOKEN_MANDATORY_NEW_PROCESS_MIN

Contrôle le comportement de l’affectation du niveau d’intégrité aux processus enfants. Normalement, un processus enfant hérite du niveau d’intégrité du processus parent lorsque le jeton d’accès du processus parent est affecté à l’enfant. Avec la stratégie NEW_PROCESS_MIN, le niveau d’intégrité du processus enfant est le niveau d’intégrité minimal du jeton d’accès parent ou du niveau d’intégrité de l’objet du fichier exécutable pour le nouveau processus. Cette stratégie est définie par défaut dans tous les jetons d’accès.

La stratégie NEW_PROCESS_MIN peut être décrite par un exemple. Supposons qu’il existe un programme exécutable appelé lowcalc.exe. Une étiquette d’intégrité faible est affectée au fichier programme. À partir d’une invite de commandes, l’utilisateur exécute lowcalc.exe. Le processus parent, cmd.exe, s’exécute à un niveau d’intégrité moyen. Étant donné que le fichier image, lowcalc.exe, a une étiquette d’intégrité faible, la stratégie de NEW_PROCESS_MIN définit le niveau d’intégrité du nouveau processus, lowcalc, à faible. Cela est illustré dans l’exemple ci-dessous dans la section Conception d’applications à exécuter à un niveau d’intégrité faible.

Stratégies d’étiquette obligatoires

Les stratégies d’étiquette obligatoire sont définies en tant qu’indicateurs (bits) dans le champ Masque de l’entrée de contrôle d’accès d’étiquette obligatoire. Ces indicateurs de stratégie déterminent les restrictions sur les autorisations d’accès qui s’appliquent aux sujets d’intégrité inférieure. Le tableau 6 présente les stratégies d’étiquette obligatoires définies dans Windows Vista.

Tableau 6 Stratégies d’étiquette obligatoires dans Windows Vista

Stratégie	Description
SYSTEM_MANDATORY_POLICY_NO_WRITE_UP	Stratégie par défaut sur toutes les étiquettes obligatoires d’objet. L’indicateur équivaut à la stratégie de jeton d’accès NO_WRITE_UP. La stratégie limite l’accès en écriture à l’objet par un sujet dont le niveau d’intégrité est inférieur.
SYSTEM_MANDATORY_POLICY_NO_READ_UP	Restreint l’accès en lecture à l’objet par un objet avec un niveau d’intégrité inférieur. La stratégie est utilisée, par exemple, pour restreindre l’accès en lecture à l’espace d’adressage de mémoire virtuelle d’un processus.
SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP	Restreint l’accès d’exécution à l’objet par un sujet avec un niveau d’intégrité inférieur. La stratégie est utilisée, par exemple, pour restreindre les autorisations d’activation de lancement sur une classe COM par des sujets d’intégrité inférieure.

Ces stratégies définies répondent aux objectifs de conception de Windows Vista. L’architecture du mécanisme d’intégrité permet une expansion future en définissant des options de stratégie supplémentaires qui contrôlent les autorisations d’accès entre les sujets et les objets à différents niveaux d’intégrité.

Comment les stratégies d’intégrité sont mappées aux droits génériques

La stratégie obligatoire case activée se produit dans le cadre de la fonction de sécurité AccessCheck. AccessCheck (et SeAccessCheck en mode noyau) a comme l’un des paramètres de fonction une structure de GENERIC_MAPPING. Le mappage générique fourni par l’appelant mappe les droits d’accès spécifiques à l’objet aux catégories génériques de lecture, d’écriture et d’exécution. Les stratégies d’étiquette obligatoire implémentent des restrictions sur l’accès autorisé en fonction des catégories génériques. Pour un type d’objet particulier, le GENERIC_MAPPING communique à la stratégie obligatoire case activée quels droits d’accès spécifiques sont interdits.

Si la structure GENERIC_MAPPING passée dans un appel à AccessCheck est de zéros (0), le mappage générique n’est pas défini. Lorsque le mappage générique n’est pas défini, la stratégie obligatoire case activée restreint tous les droits d’accès aux sujets à intégrité inférieure. Les gestionnaires de ressources qui utilisent AccessCheck pour la sécurité des objets privés et passent une structure GENERIC_MAPPING de tous les zéros verront des erreurs d’accès refusé . Une modification du code de l’application Resource Manager est nécessaire pour mapper les droits d’accès spécifiques au type d’objet aux droits d’accès génériques appliqués par la stratégie obligatoire.

Comment les niveaux d’intégrité sont attribués aux jetons d’accès

Le jeton d’accès de sécurité est une structure de données interne que le noyau utilise. Le jeton d’accès de sécurité contient différentes valeurs d’informations qui correspondent aux privilèges, à l’appartenance au groupe et à d’autres détails liés à la sécurité. L’initialisation du jeton d’accès se produit lorsqu’un utilisateur se connecte de manière interactive à Windows ou lorsqu’une authentification réseau se produit. Lorsque le jeton d’accès est initialisé, le SID, les SID de groupe et les privilèges de l’utilisateur sont ajoutés, en plus d’autres valeurs. Windows Vista affecte le niveau d’intégrité du jeton d’accès lors de l’initialisation du jeton d’accès.

Le noyau affecte un jeton d’accès à chaque processus et thread. Le jeton d’accès principal du processus contient le niveau d’intégrité associé à ce processus. Dans le mécanisme d’intégrité Windows, le niveau d’intégrité du processus est appelé niveau d’intégrité du sujet. Si le jeton d’accès d’une application contient le SID d’intégrité moyenne, le processus d’application s’exécute à un niveau d’intégrité moyenne. Plusieurs processus d’application s’exécutant sous le même compte d’utilisateur se voient attribuer le même jeton d’accès principal. C’est ainsi que le même niveau d’intégrité est attribué à chacune des applications.

Les niveaux d’intégrité sont attribués aux jetons d’accès en fonction des SID de groupe spécifiques présents dans la structure TOKEN_GROUPS. Le noyau Windows attribue un niveau d’intégrité basé sur des comptes d’utilisateur ou de groupe intégrés spécifiques. Windows Vista affecte un jeton d’accès dont le SID du compte système local présente le niveau d’intégrité du système, un jeton d’accès avec le sid du groupe Administrateurs local présent se voit attribuer le niveau d’intégrité élevé, et un jeton d’accès pour un compte d’utilisateur standard se voit attribuer le niveau d’intégrité moyen.

Le tableau 7 montre les affectations du niveau d’intégrité au jeton d’accès, en fonction de la présence de SID spécifiques.

Tableau 7 Niveaux d’intégrité liés à des SID spécifiques

SID dans le jeton d’accès	Niveau d’intégrité attribué
LocalSystem	System
LocalService	System
NetworkService	System
Administrateurs	Élevé
Opérateurs de sauvegarde	Élevé
Opérateurs de configuration réseau	Élevé
Opérateurs de chiffrement	Élevé
Utilisateurs authentifiés	Moyenne
Tout le monde (monde)	Faible
Authentification anonyme	Non fiable

Les niveaux d’intégrité définissent différents niveaux de fiabilité pour les applications exécutées à différents niveaux d’accès. La plupart des applications dans Windows Vista s’exécutent à un niveau d’accès utilisateur standard au niveau d’intégrité moyen. Les applications au niveau d’intégrité moyen ne subissent aucune restriction quant à la façon dont elles interagissent avec d’autres applications et avec les données au niveau d’intégrité moyen. Les tâches ou applications spécifiques qui nécessitent des droits d’administration s’exécutent à un niveau d’intégrité élevé. Les services système s’exécutent au niveau de l’intégrité du système, car il existe des restrictions quant à leur capacité à interagir avec le bureau par défaut, et ils s’exécutent souvent avec des privilèges système puissants. Certaines applications conçues pour s’exécuter avec le moins de droits possible, telles que les Explorer Internet en mode protégé, peuvent s’exécuter avec un niveau d’intégrité faible.

Certains privilèges Windows d’administration peuvent être attribués à un jeton d’accès uniquement avec au moins un niveau d’intégrité élevé. Si le niveau d’intégrité du jeton d’accès est inférieur à élevé, des privilèges administratifs spécifiques ne sont pas autorisés et sont supprimés du jeton d’accès. Les privilèges d’administration associés à un niveau d’intégrité élevé sont les suivants :

SE_CREATE_TOKEN_PRIVILEGE
SE_TCB_PRIVILEGE
SE_TAKE_OWNERSHIP_PRIVILEGE
SE_BACKUP_PRIVILEGE
SE_RESTORE_PRIVILEGE
SE_DEBUG_PRIVILEGE
SE_IMPERSONATE_PRIVILEGE
SE_RELABEL_PRIVILEGE
SE_LOAD_DRIVER_PRIVILEGE

Les applications peuvent affecter un niveau d’intégrité faible à un jeton d’accès en double lors de la création d’un processus enfant. Windows peut exécuter un processus d’application avec un niveau d’intégrité faible si le fichier image du programme exécutable a une étiquette obligatoire faible. Ces fonctionnalités sont décrites plus loin dans cet article.

Comment obtenir le niveau d’intégrité d’un jeton d’accès

Le niveau d’intégrité est stocké dans le jeton d’accès à l’aide du champ TOKEN_GROUPS. La structure TOKEN_GROUPS est une liste de SID et d’attributs qui identifient les appartenances au groupe pour ce compte d’utilisateur. Le niveau d’intégrité du jeton d’accès est également identifié dans la liste des groupes à l’aide d’un attribut SID. La structure SID_AND_ATTRIBUTES contient le SID de niveau d’intégrité, et le niveau d’intégrité est identifié à l’aide des attributs SE_GROUP_INTEGRITY et SE_GROUP_INTEGRITY_ENABLED.

Vous pouvez récupérer le niveau d’intégrité du jeton d’accès à partir du jeton d’accès à l’aide de l’API GetTokenInformation. GetTokenInformation a un paramètre pour indiquer la classe d’informations de jeton d’accès à récupérer. Le paramètre TOKEN_INFORMATION_CLASS a une valeur définie pour le niveau d’intégrité, TokenIntegrityLevel. La structure de données retournée est un type TOKEN_MANDATORY_LABEL.

Pour déterminer le niveau d’intégrité d’un processus

Ouvrez un handle sur le jeton d’accès du processus.
Obtenez le niveau d’intégrité du jeton d’accès.
Comparez le SID de niveau d’intégrité aux RID de niveau d’intégrité définis par le système.

L’exemple de code permettant d’obtenir le niveau d’intégrité du jeton d’accès est indiqué à l’annexe D.

Comment afficher le niveau d’intégrité d’un jeton d’accès

Le niveau d’intégrité dans le jeton d’accès de sécurité d’un processus peut être affiché à l’aide d’outils qui exposent les détails de sécurité d’un processus, tels que process Explorer à partir de SysInternals.com. Les images suivantes montrent l’affichage de Process Explorer avec la colonne Niveau d’intégrité ajoutée à la vue (à droite).

Figure 1 Niveau d’intégrité dans process Explorer

Si nous examinons les propriétés de sécurité d’un processus spécifique, par exemple explorer.exe, process Explorer affiche le niveau d’intégrité dans la liste des groupes définis dans le jeton d’accès de sécurité du processus. L’image suivante montre l’étiquette obligatoire/niveau obligatoire moyen affecté au jeton d’accès pour le processus, explorer.exe.

Figure 2 Explorer.exe en tant que processus de niveau d’intégrité moyen

Comment définir le niveau d’intégrité d’un jeton d’accès

Les applications n’ont généralement pas besoin de modifier la valeur du niveau d’intégrité du processus. Les applications n’ont généralement pas besoin d’apporter de modifications aux valeurs du jeton d’accès de sécurité. Toutefois, dans certaines circonstances, les services qui prennent en charge les clients locaux à différents niveaux d’intégrité peuvent choisir d’effectuer des tâches à un niveau d’intégrité inférieur. L’emprunt d’identité est l’une des façons dont un thread de service peut s’exécuter à un niveau d’intégrité inférieur. Lorsqu’un thread de service emprunte l’identité d’un client local, le thread d’emprunt d’identité a le contexte de sécurité du client, qui inclut le niveau d’intégrité du client si le client s’exécute sur le même ordinateur local.

Une autre façon pour une application d’effectuer une opération, telle que la création d’un ensemble de fichiers et de clés de Registre, à un niveau d’intégrité inférieur consiste à définir le JetonIntegrityLevel pour le jeton d’accès au thread actuel. Le nouveau niveau d’intégrité ne peut pas être supérieur au niveau d’intégrité dans le jeton d’accès principal du processus.

Pour définir la valeur d’un niveau d’intégrité de jeton d’accès sur un thread

Appelez OpenThreadToken pour obtenir un handle sur le jeton d’accès.
Appelez GetTokenInformation avec la valeur de paramètre TOKEN_INFORMATION_CLASSde TokenIntegrityLevel pour enregistrer le niveau d’intégrité du thread actuel.
Appelez SetTokenInformation avec la valeur de paramètre TOKEN_INFORMATION_CLASS de TokenIntegrityLevel.

Étant donné qu’il n’existe aucune limite de sécurité dans un espace d’adressage de processus entre les threads à différents niveaux d’intégrité, les concepteurs d’applications doivent tenir compte des risques de sécurité potentiels liés à l’exécution du code dans un thread à une intégrité inférieure dans un processus à intégrité supérieure. La plupart des applications peuvent trouver plus simple de créer un processus distinct s’exécutant au niveau d’intégrité inférieur pour effectuer des tâches d’intégrité inférieure.

Un exemple de la façon de définir tokenIntegrityLevel et de créer un processus à un niveau d’intégrité inférieur est illustré dans Comment définir le niveau d’intégrité d’un jeton d’accès.

Étiquette ACE obligatoire

Le mécanisme d’intégrité Windows définit un nouveau type ACE, l’étiquette ACE obligatoire du système. L’étiquette obligatoire ACE est utilisée pour représenter l’étiquette obligatoire d’un objet dans le descripteur de sécurité de l’objet. L’étiquette obligatoire contient le niveau d’intégrité et la stratégie d’intégrité associée. Une étiquette ACE obligatoire est utilisée uniquement dans la liste de contrôle d’accès système ou SACL du descripteur de sécurité. La liste de contrôle d’accès partagé est un champ distinct dans le descripteur de sécurité de la liste de contrôle d’accès discrétionnaire (DACL).

Figure 3 Champs de descripteur de sécurité

La liste de contrôle d’accès discrétionnaire contient les autorisations d’accès utilisateur et de groupe à l’objet. N’importe quel utilisateur ou groupe peut apporter des mises à jour à la liste de contrôle d’accès aux objets avec WRITE_DAC autorisations d’accès aux objets. Les listes de contrôle d’accès discrétionnaires peuvent être mises à jour plus fréquemment et par différents utilisateurs. L’un des objectifs de conception du mécanisme d’intégrité est que le système de sécurité doit conserver l’étiquette avec un objet après l’application d’une étiquette obligatoire à l’objet. L’application de l’étiquette obligatoire appropriée dans le descripteur de sécurité d’objet, avec peu ou pas d’impact sur les applications conçues pour gérer les listes de contrôle d’accès, s’effectue en plaçant l’étiquette obligatoire dans l’ACL système, où elle est principalement sous le contrôle du système de sécurité. L’étiquette obligatoire est logiquement distincte des entrées d’audit système dans la liste saCL. Il n’existe aucun ordre requis pour que l’étiquette obligatoire précède ou suive les entrées d’audit système dans la SACL.

L’étiquette ACE obligatoire est similaire à un ACE d’accès autorisé, en ce qu’elle contient un en-tête ACE, un masque d’accès et un SID. La partie SID de l’ace d’étiquette obligatoire contient le SID de niveau d’intégrité. Le tableau 8 montre les champs dans l’en-tête ACE.

Tableau 8 Champs contenus dans l’en-tête ACE

Champ d’en-tête ACE	Valeur
AceType	SYSTEM_MANDATORY_LABEL_ACE_TYPE
AceFlags	Indicateurs de contrôle qui définissent l’héritage du type ACE d’étiquette obligatoire
AceSize	Taille de l’étiquette ACE obligatoire

L’étiquette OBLIGATOIRE ACE contient un champ Masque . Le masque est utilisé pour définir les stratégies obligatoires qui déterminent les restrictions sur les autorisations d’accès qui s’appliquent aux processus (ou aux sujets) avec un niveau d’intégrité inférieur. La stratégie NO_WRITE_UP est un exemple de stratégie largement utilisée dans Windows Vista. L’indicateur de stratégie NO_WRITE_UP dans le masque ACE d’étiquette obligatoire signifie que les sujets dont le niveau d’intégrité (dans le jeton d’accès) est inférieur au SID de niveau d’intégrité dans l’étiquette obligatoire sur l’objet ne peuvent pas obtenir un accès en écriture générique à l’objet.

Il n’existe qu’une seule étiquette obligatoire effective sur un objet. Si un descripteur de sécurité obtient plusieurs étiquettes obligatoires dans la liste SACL, la première étiquette ACE obligatoire de la LISTE de contrôle d’accès partagé est l’étiquette effective de l’objet.

Pour plus d’informations sur l’étiquette ACE obligatoire, consultez Ressources du mécanisme d’intégrité Windows.

Lecture de l’étiquette OBLIGATOIRE ACE

Windows Vista utilise la fonction de sécurité GetSecurityInfo pour lire les informations d’étiquette obligatoires à partir d’un objet. GetSecurityInfo obtient les informations propriétaire, groupe, DACL ou SACL à partir d’un objet. Le paramètre SECURITY_INFORMATION à GetSecurityInfo détermine quelle partie du descripteur de sécurité est retournée. Windows Vista définit une nouvelle valeur d’informations de sécurité, LABEL_SECURITY_INFORMATION, qui est utilisée pour renvoyer l’étiquette ACE obligatoire à partir de la LISTE de contrôle d’accès partagé. Si l’appel à GetSecurityInfo spécifie SACL_SECURITY_INFORMATION, seuls les aces d’audit système de la liste SACL sont retournés, et non l’étiquette ACE obligatoire.

L’autorisation d’accès requise pour lire l’étiquette ACE obligatoire sur un objet est la READ_CONTROL droit d’accès standard. Normalement, le droit d’accès ACCESS_SYSTEM_SECURITY est requis pour obtenir ou définir des informations dans la liste de contrôle d’accès partagé. ACCESS_SYSTEM_SECURITY est accordé uniquement si le privilège SE_SECURITY_NAME est activé dans le jeton d’accès. La lecture de l’étiquette obligatoire à partir de la saCL ne nécessite pas SE_SECURITY_NAME privilège ni le droit d’accès ACCESS_SYSTEM_SECURITY.

Définition de l’étiquette OBLIGATOIRE ACE

Windows Vista utilise la fonction de sécurité SetSecurityInfo pour modifier les informations d’étiquette obligatoires sur un objet. L’étiquette obligatoire de l’objet est définie par le sous-système de sécurité lors de la création de l’objet. Le paramètre SECURITY_INFORMATION à SetSecurityInfo doit inclure LABEL_SECURITY_INFORMATION afin de modifier l’étiquette obligatoire dans le descripteur de sécurité.

L’étiquette obligatoire affectée à la création d’un objet est généralement le niveau d’intégrité correct pour un objet, et il n’est pas nécessaire de modifier l’étiquette obligatoire. Toutefois, il peut y avoir des exigences de conception d’application pour modifier le niveau d’intégrité d’un objet lorsque l’application est conçue pour prendre en charge plusieurs processus clients à différents niveaux d’intégrité.

Les autorisations requises pour modifier l’étiquette ACE obligatoire dans la SACL d’un descripteur de sécurité sont WRITE_OWNER. L’écriture de l’étiquette obligatoire dans la saCL ne nécessite pas SE_SECURITY_NAME privilège, ni le droit d’accès ACCESS_SYSTEM_SECURITY. Le niveau d’intégrité dans l’étiquette obligatoire peut être défini sur une valeur inférieure ou égale au niveau d’intégrité du sujet.

La modification la plus courante consiste à réduire le niveau d’intégrité d’un objet pour permettre à un processus d’application à intégrité inférieure d’avoir un accès de modification. Par exemple, une application à un niveau d’intégrité moyen doit se synchroniser avec un autre processus d’application s’exécutant à un niveau d’intégrité faible. Le processus d’intégrité moyenne crée un objet mutex nommé et lui attribue une étiquette obligatoire à faible niveau pour permettre à un processus à faible intégrité d’ouvrir le mutex aux événements de signal.

Privilège d’attribution de réélabel

Le mécanisme d’intégrité Windows définit un nouveau privilège de sécurité Windows, SE_RELABEL_NAME. Lorsqu’il est activé dans un jeton d’accès de sécurité, le privilège de sécurité réélétique permet au sujet de définir l’étiquette obligatoire d’un objet sur un niveau d’intégrité supérieur au niveau d’intégrité dans le jeton d’accès de l’objet. La stratégie de sécurité par défaut pour Windows Vista n’affecte pas ce privilège à un utilisateur ou à un groupe. Le privilège est conçu pour répondre aux scénarios où un processus administrateur s’exécutant à un niveau d’intégrité élevé doit modifier ou affecter l’étiquette obligatoire pour les objets au niveau de l’intégrité système. Windows Vista n’a pas de tâches qui nécessitent ou utilisent le privilège de réétiquetage.

Comment Windows attribue une étiquette obligatoire aux objets

Windows attribue une étiquette obligatoire à un objet sécurisable lors de la création du descripteur de sécurité de l’objet. Le niveau d’intégrité d’un nouvel objet est attribué de l’une des trois manières suivantes :

Le sous-système de sécurité attribue à l’objet une étiquette obligatoire lorsque le descripteur de sécurité est créé pour l’objet .
Le processus de création spécifie une étiquette obligatoire explicite en tant qu’attributs de sécurité lors de la création de l’objet à l’aide d’une fonction, telle que CreateFile.
Le conteneur parent définit une étiquette ACE obligatoire pouvant être héritée qui s’applique aux objets enfants créés dans le conteneur.

Le moyen le plus simple de comprendre comment les niveaux d’intégrité des objets sont attribués consiste à supposer que chaque objet se voit attribuer une étiquette obligatoire avec le même niveau d’intégrité que le niveau d’intégrité du sujet du processus de création (ou du thread). Toutefois, il existe des exceptions à l’idée générale basée sur le type d’objet et le niveau d’intégrité de l’objet. Les exceptions sont le résultat de choix de conception qui sont nécessaires pour prendre en charge d’autres exigences système pour une expérience utilisateur cohérente lorsque différentes stratégies de sécurité, telles que le contrôle D’utilisateur, sont activées ou désactivées.

Les étiquettes obligatoires peuvent être appliquées à tous les objets sécurisables qui ont un contrôle d’accès basé sur le descripteur de sécurité. Il existe de nombreux types d’objets sécurisables, notamment des objets de processus et de thread, des objets nommés et des objets persistants tels que des fichiers ou des clés de Registre. Windows Vista n’affecte pas d’étiquettes obligatoires explicites à tous les types d’objets lors de la création d’objets. Les types d’objets auxquels le sous-système de sécurité affecte des étiquettes obligatoires lors de la création de l’objet sont les suivants :

Processus
Thread
Access token (Jeton d’accès)
Travail

Tous les autres types d’objets ont une valeur par défaut implicite ou une étiquette obligatoire héritée. Rappelez-vous que, lors de l’initialisation du jeton d’accès, un niveau d’intégrité est affecté au jeton d’accès de sécurité créé lors d’une ouverture de session interactive. Le premier processus lancé pour le compte d’une ouverture de session utilisateur est userinit.exe, ce qui démarre le processus de l’interpréteur de commandes, explorer.exe. Userinit.exe est démarré par un service système (Winlogon) qui utilise un appel à CreateProcessAsUser et transmet le jeton d’accès pour l’utilisateur d’ouverture de session interactive.

CreateProcessAsUser crée un objet de processus et un thread initial, entre autres choses. Lorsque l’objet de processus est créé, le descripteur de sécurité de ce processus se voit attribuer le niveau d’intégrité du jeton d’accès affecté en tant que jeton d’accès principal au nouveau processus. Lorsque userinit.exe appelle CreateProcess pour lancer l’interpréteur de commandes, l’objet de processus pour explorer.exe est initialisé. L’objet process inclut un descripteur de sécurité et un jeton d’accès principal. L’étiquette obligatoire sur le processus explorer.exe est définie sur le niveau d’intégrité du processus de création, userinit.exe, qui est moyen. Le jeton d’accès principal pour explorer.exe est hérité du processus parent de création, userinit.exe et a un niveau d’intégrité moyen. Lorsque le processus explorer.exe crée un thread, l’objet thread reçoit un descripteur de sécurité et le sous-système de sécurité attribue un niveau d’intégrité à l’objet thread en fonction du niveau d’intégrité du processus de création. Les objets thread dans le processus explorer.exe se voient attribuer un niveau d’intégrité de support, qui est le niveau d’intégrité du jeton d’accès principal du processus de création.

Notes

Un objet de jeton d’accès est un objet sécurisable avec son propre descripteur de sécurité. Le descripteur de sécurité du jeton est utilisé pour déterminer l’accès autorisé pendant les fonctions OpenProcessToken ou OpenThreadToken. L’objet de jeton d’accès a une étiquette obligatoire dans le descripteur de sécurité sur l’objet de jeton d’accès. Le jeton d’accès contient également un SID de niveau d’intégrité dans la liste des groupes de jetons d’accès qui représente le niveau d’intégrité du sujet.

En affectant toujours des étiquettes obligatoires aux objets de processus, de thread, de jeton et de travail, le mécanisme d’intégrité empêche les processus du même utilisateur à des niveaux d’intégrité inférieurs d’accéder à ces types d’objets et de modifier leur contenu ou leur comportement, comme l’injection d’une DLL ou l’emprunt d’identité d’un jeton d’accès de niveau supérieur.

Niveau d’intégrité par défaut

Un ACE d’étiquette obligatoire n’est pas attribué à tous les types d’objets dans le descripteur de sécurité. Si une étiquette ACE obligatoire est présente dans le descripteur de sécurité, c’est ce qu’on appelle une étiquette obligatoire explicite. Si aucune étiquette ACE obligatoire n’est présente, le sous-système de sécurité utilise une étiquette obligatoire implicite par défaut pour cet objet pendant la case activée de stratégie obligatoire. L’étiquette obligatoire par défaut affecte un niveau d’intégrité moyen pour tous les objets sécurisables. Si aucune étiquette obligatoire n’est définie dans le descripteur de sécurité, l’étiquette obligatoire par défaut implicite s’applique à tous les types d’objets.

Le niveau d’intégrité de l’objet par défaut du support, combiné à la stratégie obligatoire par défaut de NO_WRITE_UP, limite l’accès de modification à tous les objets par des processus dont le niveau d’intégrité du sujet est inférieur à moyen. L’étiquette et la stratégie obligatoires par défaut empêchent les processus non fiables à faible intégrité de modifier des fichiers utilisateur ou système ou des clés de Registre sur le système qui, autrement, autorisent un accès discrétionnaire en écriture dans la LISTE de contrôle d’accès à l’utilisateur.

Les objets de système de fichiers NTFS et les clés de Registre ne sont pas étiquetés automatiquement lors de leur création. Ces objets n’ont pas d’étiquette obligatoire après la mise à niveau d’une version précédente de Windows vers Windows Vista. Les fichiers sur des systèmes de fichiers non NTFS (CDFS ou FAT32) qui n’ont pas de descripteurs de sécurité ne sont pas des objets sécurisables et n’ont pas de niveau d’intégrité. Chaque descripteur de sécurité doit avoir une étiquette obligatoire implicite.

Les processus avec un niveau d’intégrité du sujet au niveau moyen ou supérieur créent des fichiers et des clés de Registre sans étiquette explicite. Par conséquent, les objets de système de fichiers et de Registre créés par un processus de niveau d’intégrité élevé ou système ont une étiquette de support implicite. Les applications qui utilisent des étiquettes obligatoires peuvent définir des étiquettes explicites lors de la création d’objets. Toutefois, Windows Vista n’affecte pas d’étiquettes supérieures à un niveau d’intégrité moyen au système de fichiers ou au Registre par défaut. Cela ne signifie pas que ces objets sont nécessairement susceptibles d’être modifiés par des processus d’intégrité inférieure. La liste de contrôle d’accès discrétionnaire héritée (ou par défaut) sur les objets de système de fichiers ou de Registre créés par un processus de niveau supérieur ou au niveau du système accorde un accès en écriture uniquement aux membres du groupe Administrateurs ou aux comptes système ou de service locaux.

Un certain nombre de contraintes de conception requises à l’aide de l’étiquette obligatoire implicite par défaut de support, au lieu d’affecter une étiquette obligatoire explicite basée sur le niveau d’intégrité du sujet pour la plupart des types d’objets. Un exemple spécifique est basé sur la possibilité d’activer ou de désactiver le contrôle de compte d’utilisateur à l’aide d’une stratégie de sécurité locale. Lorsque le contrôle D’utilisateur est désactivé, un utilisateur membre du groupe Administrateurs local a tous les processus en cours d’exécution avec un jeton d’accès de privilège complet à un niveau d’intégrité élevé. Si tous les objets sont explicitement étiquetés au niveau d’intégrité de l’objet, tous les fichiers tels que les documents et les feuilles de calcul créés par l’utilisateur se verraient attribuer un niveau d’intégrité élevé. L’étiquette haute semble appropriée, même si les autorisations DACL héritées pour le profil utilisateur fournissent un contrôle d’accès suffisant pour l’accès utilisateur. Toutefois, si la UAC est activée par l’ordinateur local ou stratégie de groupe, la plupart des processus exécutés par le même utilisateur se voient attribuer un jeton d’accès de sécurité filtré à un niveau d’intégrité moyen. Une fois le contrôle D’utilisateur activé, l’utilisateur ne peut pas ouvrir les fichiers qui ont été créés lorsque le contrôle d’utilisateur a été désactivé. Une application d’intégrité moyenne qui tente d’ouvrir les documents à haute intégrité de l’utilisateur reçoit une erreur Accès refusé.

Si un processus s’exécute avec un niveau d’intégrité du sujet inférieur au niveau d’intégrité par défaut du support, ce processus aura des autorisations d’accès limitées à tous les objets qui ont un niveau d’intégrité moyen implicite. Les processus avec un niveau d’intégrité faible ne pourront pas modifier un objet avec un niveau d’intégrité explicite ou implicite de niveau moyen ou supérieur, quels que soient les droits d’accès accordés au principal de sécurité dans le DACL. Par conséquent, tous les objets créés par un processus dont le niveau d’intégrité du sujet est inférieur au niveau par défaut (moyen) sont explicitement étiquetés par le sous-système de sécurité. Des restrictions d’accès sur les processus à faible intégrité sont possibles dans Windows Vista, car toutes les applications s’exécutent généralement au niveau d’intégrité moyen et les problèmes de compatibilité des applications sont minimes. Les applications qui s’exécutent correctement à faible intégrité nécessitent généralement des modifications de conception spécifiques pour fonctionner correctement avec un accès restreint. Les modifications de conception sont décrites dans la section ci-dessous sur La conception d’applications à exécuter à un niveau d’intégrité faible.

Étiquetage des objets créés par des sujets faibles

Les applications peuvent être démarrées à l’aide de la fonction CreateProcessAsUser à un niveau d’intégrité faible. Un processus faible est initialisé par CreateProcessAsUser avec les informations de niveau d’intégrité suivantes :

Le nouvel objet de processus est créé avec un descripteur de sécurité contenant une étiquette obligatoire avec une faible intégrité.
Un nouvel objet thread est créé pour ce processus et avec un descripteur de sécurité qui contient une étiquette obligatoire avec une faible intégrité.
Un jeton d’accès principal est affecté au nouveau processus. L’objet de jeton d’accès a un descripteur de sécurité avec une étiquette obligatoire à faible, et le jeton d’accès contient un TokenIntegrityLevel avec un SID d’intégrité faible qui représente le niveau d’intégrité de l’objet.

Supposons que le processus de faible intégrité est en cours d’exécution et qu’il souhaite créer un thread. Pour créer un thread, il doit ouvrir son propre objet de processus pour l’accès en écriture afin de créer un objet thread. Si l’étiquette obligatoire sur l’objet de processus était moyenne, le sujet faible ne parviendrait pas à ouvrir le processus et ne serait pas en mesure de créer un thread. Étant donné que l’objet de processus est également étiqueté à faible intégrité, l’objet faible est autorisé à ouvrir le processus pour l’accès en écriture et à créer un objet thread. L’exemple montre pourquoi il est important que les étiquettes obligatoires sur l’objet de processus, les objets thread et le jeton d’accès de sécurité soient cohérentes au même niveau d’intégrité.

Notes

Cela s’applique à tous les niveaux d’intégrité, pas seulement aux sujets faibles.

Supposons que le processus faible crée un fichier temporaire. L’application appelle CreateFile pour créer un fichier, écrire des données et fermer le fichier. Plus tard, le processus faible souhaite rouvrir le même fichier pour ajouter des données. Si le fichier temporaire a une étiquette obligatoire implicite par défaut à un niveau d’intégrité moyen, le processus faible ne pourra pas rouvrir le fichier qu’il a créé précédemment pour modifier l’accès. Le même problème peut se poser pour tout objet sécurisable qu’un sujet dont le niveau d’intégrité est inférieur au niveau par défaut du moyen crée. Par conséquent, tous les objets sécurisables créés par un sujet dont le niveau d’intégrité est inférieur au niveau par défaut se voient automatiquement attribuer une étiquette obligatoire explicite. En d’autres termes, tous les objets de noyau, clés de Registre et objets de système de fichiers sont explicitement étiquetés à faible quand le niveau d’intégrité de l’objet est faible.

Comment créer un objet avec une étiquette obligatoire spécifique

La plupart des applications Windows n’ont pas besoin de prendre en compte l’intégrité. Le sous-système de sécurité crée automatiquement des objets et leur attribue une étiquette obligatoire. Étant donné que la plupart des applications s’exécutent à un niveau d’intégrité moyen et que le niveau d’intégrité des objets par défaut est moyen, la stratégie d’intégrité ne modifie pas le contrôle d’accès autorisé pour la plupart des applications. Toutefois, certaines applications, telles que les services, sont conçues pour prendre en charge les applications clientes à différents niveaux d’intégrité. Le service peut s’exécuter à un niveau d’intégrité supérieur à celui du client et peut vouloir étiqueter explicitement les nouveaux objets créés pour le compte du client à un niveau d’intégrité inférieur. Le niveau d’intégrité de l’objet peut être défini par le processus de création. La contrainte est que le niveau d’intégrité sur le nouvel objet doit être inférieur ou égal au niveau d’intégrité du processus de création.

Pour créer un objet avec une étiquette obligatoire spécifique

Créez un descripteur de sécurité SDDL qui définit une étiquette obligatoire faible, par exemple :
#define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
Convertissez la chaîne SDDL en descripteur de sécurité à l’aide de ConvertStringSecurityDescriptorToSecurityDescriptor.
Affectez le descripteur de sécurité avec l’étiquette obligatoire faible à une structure d’attributs de sécurité.
Passez le paramètre d’attributs de sécurité à l’appel pour créer un objet, tel que CreateFile.

Héritage d’étiquette obligatoire

Windows Vista n’étiquet pas explicitement les fichiers et les répertoires dans le système de fichiers NTFS. Comme mentionné précédemment, le sous-système de sécurité utilise une étiquette obligatoire implicite avec un niveau par défaut de support pour les objets qui n’ont pas d’étiquette obligatoire dans le descripteur de sécurité.

Les applications peuvent être conçues pour s’exécuter à un niveau d’intégrité faible. Le mode Internet protégé Explorer est un exemple d’application Windows Vista conçue pour s’exécuter à faible intégrité. Les applications à faible intégrité peuvent avoir besoin de dossiers dans le système de fichiers où elles peuvent écrire des fichiers temporaires ou des données d’application. Dans le cas de l’Explorer Internet en mode protégé, le dossier Fichier Internet temporaire dans le profil de l’utilisateur est utilisé. Comment une application faible peut-elle écrire dans un dossier de système de fichiers ? Une étiquette obligatoire explicite doit être attribuée au dossier qui autorise l’accès en écriture à partir d’un processus de faible intégrité.

Selon la conception de l’application, d’autres processus de coopération peuvent ajouter des fichiers au dossier utilisé par l’application à faible intégrité. Si les autres processus s’exécutent également avec une faible intégrité, les fichiers créés par ces processus se voient automatiquement attribuer une étiquette obligatoire faible. Toutefois, si l’autre processus partenaire a une intégrité plus élevée, le processus partenaire (un service de synchronisation de fichiers ou un agent utilisateur) peut créer des fichiers dans le dossier bas qui ne sont pas automatiquement étiquetés à faible valeur. Le processus partenaire crée un fichier moyen dans le dossier utilisé par l’application basse, que l’application faible ne peut ni modifier ni supprimer.

Le mécanisme d’intégrité permet à un dossier avec une étiquette obligatoire faible d’avoir des objets enfants, des fichiers et des sous-dossiers, chacun avec une étiquette obligatoire différente et supérieure, car chaque objet de système de fichiers a un descripteur de sécurité unique. Il existe de nombreux scénarios où l’intention est que, pour un dossier auquel une étiquette obligatoire faible est attribuée, tous les fichiers du dossier doivent se voir attribuer une étiquette obligatoire faible afin qu’un processus faible puisse les modifier. Le mécanisme d’intégrité prend en charge cela en permettant aux AE d’étiquette obligatoire d’être héritables du conteneur parent vers les sous-conteneurs et les objets enfants.

La structure de données de type ACE d’étiquette obligatoire contient un en-tête ACE avec un champ AceFlags. Le champ AceFlags est utilisé pour définir des indicateurs d’héritage pour le type ACE qui sont identiques aux indicateurs d’héritage pour d’autres types ACE, tels que le type ACE autorisé par accès utilisé pour l’accès discrétionnaire. Les AE d’étiquette obligatoire peuvent être définies comme pouvant être héritées, car le conteneur hérite (CI) et/ou l’objet hérite (OI). Les AE d’étiquette obligatoire ne peuvent pas être inherit_only (E/S). Si une étiquette ACE obligatoire pouvant être héritée est affectée à un conteneur, l’étiquette obligatoire s’applique au conteneur lui-même et aux objets enfants pour lesquels l’héritage s’applique.

Un exemple d’étiquette obligatoire pouvant être héritée est l’étiquette obligatoire faible sur l’un des dossiers créés sous chaque profil utilisateur : %USERPROFILE%\AppData\LocalLow. Ce dossier se voit attribuer une étiquette obligatoire faible lorsque le profil est initialisé et destiné à être le dossier de niveau supérieur qui peut être écrit par défaut par les applications à faible intégrité. L’image suivante montre l’étiquette obligatoire pouvant être héritée dans le dossier AppData\LocalLow affiché à l’aide de la commande Icacls. Pour plus d’informations sur la façon dont Icacls prend en charge les étiquettes obligatoires, consultez l’Annexe B : Icacls et niveaux d’intégrité des fichiers.

Les indicateurs d’héritage dans l’étiquette obligatoire indiquent que l’ACE est (OI) et (CI) ACE avec une stratégie obligatoire de NO_WRITE_UP (NW). Tous les sous-dossiers créés sous le dossier AppData\LocalLow héritent de l’étiquette pouvant être héritée.

Figure 4 Étiquette obligatoire faible héritée

Lorsqu’un nouveau fichier ou sous-dossier est créé à partir d’un processus moyen, le nouvel objet hérite de l’étiquette obligatoire basse. Dans l’exemple suivant, l’invite de commandes s’exécute en cours d’exécution avec un niveau d’intégrité moyen. Un fichier, newfile.txt et un nouveau dossier, Temp, sont créés dans le dossier LocalLow, et les deux objets héritent de l’étiquette minimale obligatoire du conteneur parent. Icacls indique que l’étiquette obligatoire est héritée avec la désignation (I).

Figure 5 Hériter d’une étiquette obligatoire sur un objet enfant

L’héritage des étiquettes obligatoires garantit la cohérence du niveau d’intégrité des objets créés sous une partie de l’espace de noms du système de fichiers.

Héritage et étiquettes explicites

Les objets créés dans un conteneur qui a une étiquette obligatoire pouvant être héritée héritent de l’étiquette obligatoire du conteneur. Toutefois, le processus qui crée un objet tel qu’un fichier peut fournir une étiquette obligatoire explicite dans le paramètre d’attributs de sécurité à la fonction create, telle que CreateFile.

Si le processus de création fournit une étiquette explicite en tant que paramètre à la fonction de création d’objet, le nouvel objet se voit attribuer l’étiquette obligatoire explicite fournie par l’appelant et n’hérite pas du conteneur parent. L’étiquette obligatoire explicite ne peut pas avoir un niveau d’intégrité supérieur au processus d’objet qui crée l’objet. Le niveau d’intégrité dans l’étiquette obligatoire explicite fournie par l’objet peut être supérieur au niveau d’intégrité dans l’étiquette obligatoire héritée du conteneur parent.

Hériter uniquement de la restriction

Hériter uniquement (E/S) est un indicateur dans une entrée de contrôle d’accès qui indique que l’ACE ne contrôle pas l’accès à l’objet auquel il est attaché. Les AFC héritent uniquement sont généralement affectés aux objets conteneur. L’ACE hérité uniquement n’est pas efficace sur le conteneur lui-même ; elle s’applique plutôt aux objets enfants du conteneur. Il existe une restriction sur les sujets dont le niveau d’intégrité est inférieur à la valeur par défaut pour définir INHERIT_ONLY étiquettes sur les nouveaux objets. Si l’étiquette explicite transmise pour un nouvel objet conteneur est une étiquette INHERIT_ONLY avec un niveau inférieur à la valeur par défaut, l’étiquette est considérée comme non valide et ignorée. La raison de cette restriction est qu’un sujet faible crée un conteneur et tente de définir une étiquette de INHERIT_ONLY sur le conteneur à faible valeur. Si l’étiquette INHERIT_ONLY était acceptée, le niveau d’intégrité effectif pour le conteneur serait le niveau implicite par défaut du moyen.

En outre, les sujets ne peuvent pas définir une étiquette INHERIT_ONLY avec un niveau d’intégrité supérieur au niveau d’intégrité du sujet. Par exemple, un sujet moyen ne peut pas définir une étiquette INHERIT_ONLY avec un niveau d’intégrité élevé.

SaCL et héritage d’étiquettes protégés

SDDL prend en charge la définition d’une liste SACL protégée, qui peut inclure une étiquette obligatoire explicite. La liste SACL protégée définit l’indicateur SE_SACL_PROTECTED dans le champ SECURITY_DESCRIPTOR_CONTROL du descripteur de sécurité. La séparation logique entre LABEL_SECURITY_INFORMATION et SACL_SECURITY_INFORMATION en ce qui concerne les droits d’accès n’est pas complète en ce qui concerne le comportement d’une liste de contrôle d’accès protégée. Les étiquettes obligatoires sont stockées dans la liste SACL. Une liste SACL protégée implique que l’étiquette obligatoire soit également protégée.

Si l’indicateur SE_SACL_PROTECTED est défini dans le SECURITY_DESCRIPTOR_CONTROL, l’étiquette obligatoire est également protégée.

S’il n’existe pas d’ace d’étiquette obligatoire dans la liste SACL protégée, une étiquette ACE obligatoire héritée du conteneur n’est pas appliquée (le nouvel objet a une étiquette obligatoire implicite par défaut).
S’il existe une étiquette ACE obligatoire dans la liste SACL protégée, les modifications apportées à l’étiquette ACE pouvant être héritée sur le conteneur n’affectent pas cet objet.

Pour plus d’informations sur SDDL, consultez l’Annexe A : SDDL pour les étiquettes obligatoires ou les ressources du mécanisme d’intégrité Windows.

Fonctionnement des vérifications d’accès avec la stratégie obligatoire

La fonction AccessCheck applique la stratégie obligatoire. AccessCheck compare le descripteur de sécurité spécifié avec le jeton d’accès spécifié et indique, dans le paramètre AccessStatus , si l’accès est accordé ou refusé. La fonction AccessCheck compare d’abord le niveau d’intégrité dans Le ClientToken à l’étiquette obligatoire dans la liste saCL de pSecurityDescriptor pour déterminer quels droits d’accès ne sont pas disponibles, en fonction de la stratégie obligatoire. Une fois la stratégie obligatoire case activée, AccessCheck compare l’accès souhaité aux droits d’accès accordés dans la liste de contrôle d’accès.

La stratégie obligatoire par défaut empêche les processus à faible intégrité d’obtenir un accès en écriture générique aux objets à intégrité supérieure. Par exemple, par défaut, un processus à faible intégrité se voit refuser l’accès en écriture générique à un objet avec un niveau d’intégrité plus élevé. Si pSecurityDescriptor ne contient pas d’ACE obligatoire, un ACE obligatoire implicite est supposé attribuer à l’objet un niveau d’intégrité moyen. Le paramètre GenericMapping détermine quels droits d’accès sont associés à l’accès en écriture générique. Si le paramètre GenericMapping a tous des zéros, l’intégrité case activée n’accordera aucun droit d’accès spécifique à un ClientToken de faible intégrité. Une fois que l’intégrité case activée a déterminé les droits d’accès génériques disponibles pour l’appelant en fonction de la stratégie obligatoire, la liste DACL du descripteur de sécurité est comparée à ClientToken pour déterminer les droits d’accès accordés restants.

Isolation des privilèges d’interface utilisateur (UIPI) et intégrité

L’isolation des privilèges d’interface utilisateur (UIPI) implémente des restrictions dans le sous-système Windows qui empêche les applications à privilèges inférieurs d’envoyer des messages de fenêtre ou d’installer des hooks dans les processus à privilèges supérieurs. Les applications à privilèges plus élevés sont autorisées à envoyer des messages de fenêtre aux processus à privilèges inférieurs. Les restrictions sont implémentées dans les fonctions de message SendMessage et de fenêtre associées. Tous les messages de fenêtre envoyés d’un processus à privilèges inférieurs à un processus à privilèges plus élevés ne sont pas tous bloqués. En règle générale, les messages de type « lecture », par exemple WM_GETTEXT, peuvent être envoyés d’une fenêtre à privilèges inférieurs vers une fenêtre à privilèges plus élevés. Toutefois, les messages de type écriture, tels que WM_SETTEXT, sont bloqués.

Le niveau de privilèges de l’interface utilisateur est au niveau du processus et s’applique à toutes les fenêtres créées par le processus. Le sous-système USER s’initialise lorsque le processus effectue le premier appel à l’interface de périphérique graphique Windows (GDI). Pendant l’initialisation du processus, le sous-système USER appelle le sous-système de sécurité pour déterminer le niveau d’intégrité attribué dans le jeton d’accès de sécurité principal du processus. Une fois que le sous-système USER a défini le niveau de privilèges de l’interface utilisateur lors de l’initialisation du processus, il ne change pas. La définition d’une valeur inférieure à TokenIntegrityLevel pour un thread n’affecte pas le niveau de privilèges de l’interface utilisateur du processus ni les fenêtres ouvertes par ce processus ou thread.

UIPI n’interfère pas avec ou ne modifie pas le comportement de la messagerie de fenêtre entre les applications au même niveau de privilège (ou d’intégrité). UIPI empêche les processus à privilèges inférieurs d’accéder aux processus à privilèges plus élevés en bloquant le comportement suivant. Un processus à privilèges inférieurs ne peut pas :

Effectuez une validation de gestion de fenêtre d’un processus en cours d’exécution avec des droits plus élevés.
Utilisez SendMessage ou PostMessage pour les fenêtres d’application s’exécutant avec des droits plus élevés. Ces API retournent la réussite, mais suppriment silencieusement le message de fenêtre.
Utilisez des crochets de thread pour attacher à un processus s’exécutant avec des droits plus élevés.
Utilisez des hooks de journal pour surveiller un processus en cours d’exécution avec des droits plus élevés.
Effectuez l’injection de bibliothèque de liens dynamiques (DLL) dans un processus exécuté avec des droits plus élevés.

Avec UIPI activé, les ressources UTILISATEUR partagées suivantes sont toujours partagées entre les processus à différents niveaux de privilèges.

Fenêtre de bureau, qui possède en fait la surface de l’écran
Mémoire partagée en lecture seule du tas de bureau
Table d’atomes globale
Presse-papiers

La peinture à l’écran est une autre action qui n’est pas bloquée par UIPI. Le modèle USER/graphics device interface (GDI) n’autorise pas le contrôle des surfaces de peinture. Par conséquent, il est possible pour une application s’exécutant avec moins de droits de peindre sur la surface de la fenêtre d’application pour une application s’exécutant avec des droits plus élevés.

UIAccess pour les applications UI Automation

Microsoft UI Automation est le modèle Windows Vista qui prend en charge les exigences d’accessibilité avec des améliorations par rapport au modèle précédent, appelé Microsoft Active Accessibility (MSAA). Les applications conçues pour prendre en charge l’expérience utilisateur accessible contrôlent le comportement d’autres applications Windows pour le compte de l’utilisateur. Lorsque toutes les applications (client et serveur Automation) s’exécutent en tant qu’utilisateur standard, c’est-à-dire à un niveau d’intégrité moyen, les restrictions UIPI n’interfèrent pas avec le modèle d’automatisation de l’interface utilisateur.

Toutefois, il peut arriver qu’un utilisateur administratif exécute une application avec des privilèges élevés basés sur le contrôle d’utilisateur dans Administration mode d’approbation. Le programme d’automatisation de l’interface utilisateur ne sera pas en mesure de piloter l’interface utilisateur graphique des applications avec élévation de privilèges sur le bureau sans la possibilité de contourner les restrictions implémentées par UIPI. La possibilité de contourner les restrictions UIPI sur SendMessage à travers les niveaux de privilège est disponible pour les programmes d’automatisation de l’interface utilisateur à l’aide d’un attribut de sécurité spécial dans le manifeste d’application du programme, appelé UIAccess.

Voici un exemple d’entrée de manifeste d’application pour un programme UIAccess.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

En spécifiant UIAccess="true » dans l’attribut requestedPrivileges, l’application indique qu’il est nécessaire de contourner les restrictions UIPI sur l’envoi de messages de fenêtre entre les niveaux de privilège. Windows Vista implémente les vérifications de stratégie suivantes avant de démarrer une application avec le privilège UIAccess.

L’application doit avoir une signature numérique qui peut être vérifiée à l’aide d’un certificat numérique qui se connecte à une racine approuvée dans le magasin de certificats autorités de certification racines de confiance de l’ordinateur local.
L’application doit être installée dans un répertoire d’application de dossier local accessible en écriture uniquement par les administrateurs, tel que le répertoire Program Files. Les répertoires autorisés pour les applications UI Automation sont les suivants :
- %ProgramFiles% et ses sous-répertoires.
- %Windir% et ses sous-répertoires, à l’exception des quelques sous-répertoires exclus du fait des utilisateurs standard qui possèdent un accès en écriture.

Les sous-répertoires %WinDir% qui sont exclus des sous-répertoires sont les suivants :

\Debug
\PCHealth
\Enregistrement
\System32\ccm
\System32\com
\System32\FxsTmp
\System32\Spool
\System32\Tasks

Windows Vista fournit un paramètre de sécurité pour la stratégie d’ordinateur local et pour stratégie de groupe d’ajuster l’exigence selon laquelle les programmes UIAccess doivent être lancés à partir d’emplacements sécurisés. Le paramètre est défini sous options de sécurité sous Stratégies locales pour les stratégies de sécurité locales. La stratégie de sécurité est la suivante :

Contrôle de compte d’utilisateur : élever uniquement les applications UIAccess installées à des emplacements sécurisés

Ce paramètre est activé par défaut. Toutefois, un administrateur peut la désactiver s’il existe des situations où les applications UIAccess (technologie accessible) qui doivent être lancées à partir de dossiers ne sont pas protégées par l’accès en écriture administrateur uniquement.

Si l’application UI Automation qui demande UIAccess répond aux exigences du paramètre UIAccess, Windows Vista lance l’application avec la possibilité de contourner la plupart des restrictions UIPI. Si l’application UI Automation ne respecte pas les restrictions de sécurité, l’application est lancée sans droits UIAccess et peut interagir uniquement avec les applications ayant un niveau de privilège identique ou inférieur.

Un processus lancé avec des droits UIAccess :

A la possibilité de définir la fenêtre de premier plan.
Peut piloter n’importe quelle fenêtre d’application à l’aide de la fonction SendInput.
Contient une entrée en lecture pour tous les niveaux d’intégrité à l’aide de hooks de bas niveau, d’entrée brute, de GetKeyState, de GetAsyncKeyState et de GetKeyboardInput.
Peut définir des hooks de journal.
Utilise AttachThreadInput pour attacher un thread à une file d’attente d’entrée d’intégrité supérieure

Les applications lancées avec des droits UIAccess pour un utilisateur standard se voient attribuer une valeur de niveau d’intégrité légèrement supérieure dans le jeton d’accès. Le niveau d’intégrité du jeton d’accès pour l’application UIAccess pour un utilisateur standard est la valeur du niveau d’intégrité moyen, plus un incrément de 0x10. Le niveau d’intégrité supérieur pour les applications UIAccess empêche d’autres processus sur le même bureau au niveau d’intégrité moyen d’ouvrir l’objet de processus UIAccess.

Partager via