Vue d’ensemble de la sécurité UI Automation

Remarque

Cette documentation est destinée aux développeurs .NET Framework qui souhaitent utiliser les classes UI Automation managées définies dans l’espace de noms System.Windows.Automation. Pour obtenir les informations les plus récentes sur UI Automation, consultez API Windows Automation : UI Automation.

Cette vue d’ensemble décrit le modèle de sécurité pour Microsoft UI Automation dans Windows Vista.

Contrôle de compte d’utilisateur

La sécurité est un objectif majeur de Windows Vista et parmi les innovations, la capacité des utilisateurs à s’exécuter en tant qu’utilisateurs standard (non administrateur) sans nécessairement être bloqués pour exécuter des applications et des services nécessitant des privilèges plus élevés.

Dans Windows Vista, la plupart des applications sont fournies avec un jeton standard ou administratif. Si une application ne peut pas être identifiée comme une application administrative, elle est lancée en tant qu’application standard par défaut. Avant qu’une application identifiée comme administrative puisse être lancée, Windows Vista invite l’utilisateur à donner son consentement pour exécuter l’application en tant qu’administrateur. L’invite de consentement s’affiche par défaut, même si l’utilisateur est membre du groupe Administrateurs local, car les administrateurs s’exécutent en tant qu’utilisateurs standard jusqu’à ce qu’une application ou un composant système nécessitant des informations d’identification administratives demande l’autorisation d’exécuter.

Tâches nécessitant des privilèges supérieurs

Lorsqu’un utilisateur tente d’effectuer une tâche nécessitant des privilèges d’administration, Windows Vista présente une boîte de dialogue demandant à l’utilisateur de donner son consentement pour continuer. Cette boîte de dialogue est protégée contre la communication interprocessus, afin que les logiciels malveillants ne puissent pas simuler l’entrée utilisateur. De même, l’écran d’ouverture de session du bureau ne peut pas normalement être accessible par d’autres processus.

Les clients UI Automation doivent communiquer avec d’autres processus, certains d’entre eux s’exécutant peut-être à un niveau de privilège supérieur. Les clients peuvent également avoir besoin d’accéder aux boîtes de dialogue système qui ne sont normalement pas visibles par d’autres processus. Par conséquent, les clients UI Automation doivent être approuvés par le système et doivent s’exécuter avec des privilèges spéciaux.

Pour être approuvée pour communiquer avec les applications s’exécutant à un niveau de privilège supérieur, les applications doivent être signées.

Fichiers manifestes

Pour accéder à l’interface utilisateur système protégée, les applications doivent être créées avec un fichier manifeste qui inclut l’attribut uiAccess dans la requestedExecutionLevel balise, comme suit :

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

La valeur de l’attribut level dans ce code est un exemple uniquement.

uiAccess est « false » par défaut ; autrement dit, si l’attribut est omis ou s’il n’existe aucun manifeste pour l’assembly, l’application ne pourra pas accéder à l’interface utilisateur protégée.