Dela via

UI Automation Security Overview

  • Artikel

Note

This documentation is intended for .NET Framework developers who want to use the managed UI Automation classes defined in the System.Windows.Automation namespace. For the latest information about UI Automation, see Windows Automation API: UI Automation.

This overview describes the security model for Microsoft UI Automation in Windows Vista.

This topic contains the following sections.

  • User Account Control
  • Tasks Requiring Higher Privileges
  • Manifest Files

User Account Control

Security is a major focus of Windows Vista and among the innovations is the ability for users to run as standard (non-administrator) users without necessarily being blocked from running applications and services that require higher privileges.

In Windows Vista, most applications are supplied with either a standard or an administrative token. If an application cannot be identified as an administrative application, it is launched as a standard application by default. Before an application identified as administrative can be launched, Windows Vista prompts the user for consent to run the application as elevated. The consent prompt is displayed by default, even if the user is a member of the local Administrators group, because administrators run as standard users until an application or system component that requires administrative credentials requests permission to run.

Tasks Requiring Higher Privileges

When a user attempts to perform a task that requires administrative privileges, Windows Vista presents a dialog box asking the user for consent to continue. This dialog box is protected from cross-process communication, so that malicious software cannot simulate user input. Similarly, the desktop logon screen cannot normally be accessed by other processes.

UI Automation clients must communicate with other processes, some of them perhaps running at a higher privilege level. Clients also might need access to the system dialog boxes that are not normally visible to other processes. Therefore, UI Automation clients must be trusted by the system, and must run with special privileges.

To be trusted to communicate with applications running at a higher privilege level, applications must be signed.

Manifest Files

To gain access to the protected system UI, applications must be built with a manifest file that includes a special attribute in the manifest file. This uiAccess attribute is included in the requestedExecutionLevel tag, as follows:

<trustInfo xmlns="urn:0073chemas-microsoft-com:asm.v3">

    <security>

        <requestedPrivileges>

        <requestedExecutionLevel

            level="highestAvailable"

            UIAccess="true" />

        </requestedPrivileges>

    </security>

</trustInfo>

The value of the level attribute in this code is an example only.

UIAccess is "false" by default; that is, if the attribute is omitted, or if there is no manifest for the assembly, the application will not be able to gain access to protected UI.

For more information on Windows Vista security, on signing applications, and on creating assembly manifests, see "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" on  MSDN.