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

Notes

Cette documentation s’adresse 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 dernières informations sur UI Automation, consultez API Windows Automation : UI Automation.

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

Contrôle de compte d'utilisateur

La sécurité est un axe majeur de Windows Vista. Parmi les innovations apportées, citons la possibilité pour les utilisateurs d’exécuter le système d’exploitation en tant qu’utilisateurs standard (non-administrateurs) sans être forcément bloqués dans l’exécution des applications et des services qui nécessitent des privilèges plus élevés.

Dans Windows Vista, la plupart des applications sont fournies avec un jeton standard ou un jeton d’administration. Si une application ne peut pas être identifiée en tant qu'application administrative, elle est lancée par défaut en tant qu'application standard. Avant de permettre le lancement d’une application identifiée comme étant une application d’administration, Windows Vista invite l’utilisateur à donner son consentement pour exécuter l’application avec une élévation de privilèges. L'invite de consentement s'affiche par défaut, même si l'utilisateur est membre du groupe Administrateurs local. Cela est dû au fait que les administrateurs sont considérés comme des utilisateurs standard jusqu'à ce qu'une application ou un composant système nécessitant des informations d'identification d'administration demande l'autorisation de s'exécuter.

Tâches nécessitant des privilèges plus élevés

Quand un utilisateur tente d’effectuer une tâche qui nécessite des privilèges administratifs, Windows Vista affiche une boîte de dialogue lui demandant son consentement pour continuer. Cette boîte de dialogue bénéficie d'une protection contre les communications interprocessus, ce qui empêche les logiciels malveillants de simuler l'entrée de l'utilisateur. De même, d'autres processus ne sont normalement pas autorisés à accéder à l'écran d'ouverture de session sur le Bureau.

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

Pour avoir l'autorisation de communiquer avec des applications exécutées à un niveau de privilège plus élevé, les applications doivent être signées.

Fichiers manifeste

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

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

Dans ce code, la valeur de l'attribut level n'est qu'un exemple.

uiAccess a la valeur « false » par défaut. En d’autres termes, si l’attribut est omis, ou s’il n’existe aucun manifeste pour l’assembly, l’application ne peut pas accéder à l’IU protégée.