Vue d'ensemble de la sécurité UI Automation
.gif "Remarque") Remarque |
|---|
Cette documentation s'adresse aux développeurs .NET Framework qui veulent 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 (page éventuellement en anglais). |
Cette vue d'ensemble décrit le modèle de sécurité pour Microsoft UI Automation dans Windows Vista.
Cette rubrique comprend les sections suivantes.
- Contrôle de compte d'utilisateur
- Tâches nécessitant des privilèges plus élevés
- Fichiers manifeste
Contrôle de compte d'utilisateur
La sécurité est un objectif majeur de Windows Vista et, parmi les innovations, on note la possibilité pour les utilisateurs de s'exécuter en tant qu'utilisateurs (non administrateurs) standard, sans blocage d'exécution 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 application administrative, elle est lancée comme application standard par défaut. Avant qu'une application identifiée comme étant administrative puisse être lancée, Windows Vista invite l'utilisateur à autoriser l'exécution de l'application comme étant élevée. L'invite d'autorisation est affichée par défaut, même si l'utilisateur est membre du groupe local Administrateurs, 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 d'administration demande l'autorisation d'exécution.
Tâches nécessitant des privilèges plus élevés
Lorsqu'un utilisateur tente d'effectuer une tâche nécessitant des privilèges d'administrateur, Windows Vista présente une boîte de dialogue demandant à l'utilisateur s'il souhaite continuer. Cette boîte de dialogue est protégée de la communication interprocessus, de sorte que les logiciels malveillants ne puissent pas simuler d'entrée d'utilisateur. De la même façon, l'écran d'ouverture de session du bureau n'est normalement pas accessible aux autres processus.
Les clients UI Automation doivent communiquer avec d'autres processus, dont certains peuvent être exécutés à un niveau de privilège plus élevé. Les clients sont également susceptibles d'avoir à accéder aux boîtes de dialogue du système qui ne sont normalement pas visibles pour les 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 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'UI système protégée, les applications doivent être générées avec un fichier manifeste incluant un attribut spécial. Cet attribut uiAccess est inclus dans la balise requestedExecutionLevel, comme suit :
<trustInfo xmlns="urn:0073chemas-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 ; 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'UI protégée.
Pour plus d'informations sur la sécurité Windows Vista, la signature des applications et la création de manifestes d'assembly, consultez « Meilleures pratiques et recommandations à l'intention des développeurs pour les applications dans un environnement avec des privilèges minimum » sur MSDN (en anglais).