Partager via

Application de descripteurs de sécurité sur l’objet Device

  • Article

La plupart des pilotes utilisent les contrôles d’accès appliqués par le gestionnaire d’E/S à leurs objets d’appareil pour se protéger contre les accès inappropriés. L’approche la plus simple pour la plupart des pilotes consiste à appliquer un descripteur de sécurité explicite lorsque le pilote est installé. Dans un fichier INF, ces descripteurs de sécurité sont décrits par l’entrée « Sécurité » de la section AddReg. Pour plus d’informations sur le langage complet utilisé pour décrire les descripteurs de sécurité, consultez Security Descriptor Definition Language dans la documentation Microsoft Windows SDK.

Le format de base d’un descripteur de sécurité utilisant le langage SDDL (Security Descriptor Definition Language) inclut les éléments distincts suivants d’un descripteur de sécurité standard :

  • SID du propriétaire.

  • SID de groupe.

  • Liste de contrôle d'accès discrétionnaire.

  • Liste de contrôle d'accès système.

Ainsi, la description d’un script INF pour un descripteur de sécurité est la suivante :

O:owner-sidG:group-sidD:dacl-flags(ace)(ace)S:sacl-flags(ace)(ace)

Les entrées de contrôle d’accès individuelles décrivent l’accès à accorder ou refuser à un groupe ou un utilisateur particulier, comme spécifié par l’identificateur de sécurité ou le SID. Par exemple, un fichier INF peut contenir une ligne telle que :

"D:P(A;CI;GR;;;BU)(A;CI;GR;;;PU)(A;CI;GA;;;BA)(A;CI;GA;;;SY)(A;CI;GA;;;NS)(A;CI;GA;;;LS)(A;CI;CCDCLCSWRPSDRC;;;S-1-5-32-556)"

L’exemple ci-dessus provient d’un NETTCPIP. Fichier INF d’un système Microsoft Windows XP Service Pack 1 (SP1).

Dans cette instance, aucun propriétaire ou groupe n’est spécifié. Par conséquent, les valeurs prédéfinies ou par défaut sont définies par défaut. La D indique qu’il s’agit d’une liste de contrôle d’accès dacl. Le P indique qu’il s’agit d’une liste de contrôle d’accès protégée et qu’il n’hérite d’aucun droit du descripteur de sécurité de l’objet contenant. La liste de contrôle d’accès protégée empêche l’héritage d’une sécurité plus clémente sur le parent. L’expression entre parenthèses indique une entrée de contrôle d’accès unique (ACE). Une entrée de contrôle d’accès qui utilise le SDDL est composée de plusieurs composants distincts séparés par des points-virgules. Dans l’ordre, ils sont les suivants :

  • Indicateur de type pour l’ACE. Il existe quatre types uniques pour les DACL et quatre types différents pour les SACL.

  • Champ d’indicateurs utilisé pour décrire l’héritage de cette ACE pour les objets enfants ou la stratégie d’audit et d’alarme pour les LISTES de contrôle d’accès.

  • Le champ droits indique quels droits sont accordés ou refusés par l’ACE. Ce champ peut soit spécifier une valeur numérique spécifique indiquant les droits génériques, standard et spécifiques applicables à cet ACE, soit utiliser une description sous forme de chaîne des droits d’accès courants.

  • GUID d’objet si la liste DACL est une structure ACE spécifique à l’objet.

  • GUID d’objet hérité si la liste DACL est une structure ACE spécifique à un objet

  • SID indiquant l’entité de sécurité à laquelle cette ACE s’applique.

Ainsi, en interprétant l’exemple de descripteur de sécurité, le « A » menant à l’ACE indique qu’il s’agit d’une entrée « accès autorisé ». L’alternative est une entrée « accès refusé », qui n’est que rarement utilisée et est désignée par un caractère « D » en tête. Le champ indicateurs spécifie Container Inherit (CI), ce qui indique que cette ACE est héritée par les sous-objets.

Les valeurs de champ de droits encodent des droits spécifiques qui incluent des droits génériques et des droits standard. Par exemple, « GR » indique l’accès « lecture générique » et « GA » indique l’accès « générique tout », qui sont tous deux des droits génériques. Un certain nombre de droits spéciaux suivent ces droits génériques. Dans l’exemple ci-dessus, « CC » indique créer un accès enfant, qui est spécifique aux droits de fichier et de répertoire. L’exemple ci-dessus inclut également d’autres droits standard après la chaîne « CC », notamment « DC » pour supprimer l’accès enfant, « LC » pour l’accès enfant de liste, « SW » pour l’accès auto-droit, « RP » pour l’accès aux propriétés de lecture, « SD » pour l’accès de suppression standard et « RC » pour l’accès de contrôle de lecture.

Les chaînes d’entrée SID de l’exemple ci-dessus incluent « PU » pour les utilisateurs expérimentés, « BU » pour les utilisateurs intégrés, « BA » pour les « administrateurs intégrés », « LS » pour le compte de service local, « SY » pour le système local et « NS » pour le compte de service réseau. Ainsi, dans l’exemple ci-dessus, les utilisateurs bénéficient d’un accès en lecture générique sur l’objet. En revanche, les administrateurs intégrés, le compte de service local, le système local et le service réseau bénéficient de tous les accès génériques (lecture, écriture et exécution). L’ensemble complet de tous les droits possibles et les chaînes SID standard sont documentés dans le Kit de développement logiciel (SDK) Windows.

Ces listes de contrôle d’accès seront appliquées à tous les objets d’appareil créés par un pilote donné. Un pilote peut également contrôler les paramètres de sécurité d’objets spécifiques à l’aide de la nouvelle fonction IoCreateDeviceSecure lors de la création d’un objet d’appareil nommé. La fonction IoCreateDeviceSecure est disponible sur Windows XP Service Pack 1 et Windows Server 2003 et versions ultérieures. À l’aide d’IoCreateDeviceSecure, le descripteur de sécurité à appliquer à l’objet d’appareil est décrit à l’aide d’un sous-ensemble du langage de définition de descripteur de sécurité complet qui convient aux objets d’appareil.

L’objectif de l’application de descripteurs de sécurité spécifiques aux objets d’appareil est de s’assurer que des vérifications de sécurité appropriées sont effectuées sur l’appareil chaque fois qu’une application tente d’accéder à l’appareil lui-même. Pour les objets d’appareil qui contiennent une structure de noms (l’espace de noms d’un système de fichiers, par exemple), les détails de la gestion de l’accès à cet espace de noms d’appareil appartiennent au pilote, et non au gestionnaire d’E/S.

Dans ces cas, il est intéressant de savoir comment gérer la sécurité à la limite entre le gestionnaire d’E/S responsable de la vérification de l’accès à l’objet de périphérique du pilote et le pilote de périphérique, qui implémente la stratégie de sécurité appropriée pour le pilote. Traditionnellement, si l’objet ouvert est le nom de l’appareil lui-même, le gestionnaire d’E/S effectue une case activée d’accès complet à l’objet d’appareil directement à l’aide de son descripteur de sécurité. Toutefois, si l’objet en cours d’ouverture indique un chemin à l’intérieur du pilote lui-même, le gestionnaire d’E/S ne case activée que pour s’assurer que l’accès traversant est accordé à l’objet d’appareil. En règle générale, ce droit de traverse est accordé car la plupart des threads ont reçu SeChangeNotifyPrivilege, ce qui correspond à l’octroi du droit de traverse sur le répertoire. Un appareil qui ne prend pas en charge la structure de noms demande normalement au gestionnaire d’E/S d’effectuer une case activée de sécurité complète. Pour ce faire, définissez le bit FILE_DEVICE_SECURE_OPEN dans le champ caractéristiques de l’appareil. Un pilote qui inclut une combinaison de tels objets d’appareil doit définir cette caractéristique pour les appareils qui ne prennent pas en charge la structure de noms. Par exemple, un système de fichiers définirait cette option sur son objet d’appareil nommé (qui ne prend pas en charge une structure de nommage), mais ne définirait pas cette option sur ses objets d’appareil sans nom (un volume, par exemple), qui prennent en charge la structure de nommage. Le fait de ne pas définir correctement ce bit est un bogue courant dans les pilotes et peut autoriser un accès inapproprié à l’appareil. Pour les pilotes qui utilisent l’interface de pièce jointe (IoAttachDeviceToDeviceStackSafe, par exemple), le bit FILE_DEVICE_SECURE_OPEN est défini si ce champ est défini dans l’appareil auquel le pilote est attaché. Par conséquent, les pilotes de filtre n’ont pas besoin de se soucier de cet aspect particulier de la vérification de la sécurité.