Übersicht über die Benutzeroberflächenautomatisierungs-Sicherheit
.gif "Hinweis") Hinweis |
|---|
Diese Dokumentation ist für .NET Framework-Entwickler vorgesehen, die die verwalteten UI Automation-Klassen verwenden möchten, die im System.Windows.Automation-Namespace definiert sind.Aktuelle Informationen zu UI Automation finden Sie unter Windows Automation API: UI Automation. |
In dieser Übersicht wird das Sicherheitsmodell für Microsoft UI Automation in Windows Vista beschrieben.
Dieses Thema enthält folgende Abschnitte.
- Benutzerkontensteuerung
- Aufgaben, die höhere Berechtigungen erfordern
- Manifestdateien
Benutzerkontensteuerung
Sicherheit steht bei Windows Vista im Vordergrund. Eine der Innovationen besteht darin, dass sich Benutzer als Standardbenutzer (nicht als Administrator) anmelden können, ohne dass sie dadurch unbedingt am Ausführen von Anwendungen und Diensten gehindert werden, die höhere Berechtigungen erfordern.
In Windows Vista verfügen die meisten Anwendungen entweder über ein Standard- oder ein Verwaltungstoken. Wenn eine Anwendung nicht als administrative Anwendung identifiziert werden kann, wird sie standardmäßig als Standardanwendung gestartet. Bevor eine als administrative Anwendung identifizierte Anwendung gestartet werden kann, wird der Benutzer von Windows Vista zur Bestätigung aufgefordert, dass die Anwendung mit erhöhten Berechtigungen ausgeführt wird. Die Bestätigungsaufforderung wird immer angezeigt, auch wenn der Benutzer Mitglied der lokalen Administratorgruppe ist, da Administratoren solange als Standardbenutzer ausgeführt werden, bis eine Anwendung oder eine Systemkomponente, für die Administratorrechte erforderlich sind, die Ausführungsberechtigung anfordert.
Aufgaben, die höhere Berechtigungen erfordern
Wenn ein Benutzer versucht, eine Aufgabe auszuführen, die Administratorrechte erfordert, wird der Benutzer von Windows Vista in einem Dialogfeld aufgefordert, die Fortsetzung des Vorgangs zu bestätigen. Dieses Dialogfeld ist vor prozessübergreifender Kommunikation geschützt, damit böswillige Software keine Benutzereingabe simulieren kann. Entsprechend können andere Prozesse normalerweise auch nicht auf den Desktopanmeldebildschirm zugreifen.
Benutzerautomatisierungsclients müssen mit anderen Prozessen kommunizieren, von denen einige möglicherweise auf einer höheren Berechtigungsebene ausgeführt werden. Clients benötigen unter Umständen ebenfalls Zugriff auf die Systemdialogfelder, die normalerweise für andere Prozesse nicht sichtbar sind. Deshalb müssen UI Automation-Clients für das System vertrauenswürdig sein und mit besonderen Berechtigungen ausgeführt werden.
Anwendungen müssen signiert sein, damit sie als vertrauenswürdig gelten und mit Anwendungen kommunizieren können, die mit einer höheren Berechtigungsebene ausgeführt werden.
Manifestdateien
Um Zugriff auf die geschützte UI des System zu erlangen, müssen Anwendungen mit einer Manifestdatei erstellt werden, die ein spezielles Attribut enthält. Dieses uiAccess-Attribut wird folgendermaßen in das requestedExecutionLevel-Tag eingefügt:
<trustInfo xmlns="urn:0073chemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
UIAccess="true" />
</requestedPrivileges>
</security>
</trustInfo>
Der Wert des level-Attributs in diesem Code dient hier nur als Beispiel.
UIAccess hat standardmäßig den Wert "false". Wenn das Attribut also weggelassen wird, oder wenn für die Assembly kein Manifest vorhanden ist, kann die Anwendung nicht auf die geschützte UI zugreifen.
Weitere Informationen über die Windows Vista-Sicherheit, über das Signieren von Anwendungen und über das Erstellen von Assemblymanifesten finden Sie unter "Developer Best Practices and Guidelines for Applications in a Least Privileged Environment" auf MSDN (nur auf Englisch verfügbar).