Implementierung des Integritätsmechanismus in Windows Vista

Der Windows-Integritätsmechanismus wird in Windows Vista auf verschiedene Arten verwendet. Sein Standard Zweck besteht darin, die Zugriffsberechtigungen von Anwendungen einzuschränken, die unter demselben Benutzerkonto ausgeführt werden, das weniger vertrauenswürdig ist. Der Mechanismus verhindert, dass weniger vertrauenswürdiger Code Objekte auf höherer Ebene ändert. Die meisten Objekte, die von der Gruppe Administratoren oder dem System gesteuert werden, verfügen über eine diskretionäre Zugriffssteuerungsliste (DACL), die in der Regel Administratoren und dem System die Berechtigung zur vollständigen Kontrolle erteilt und authentifizierten Benutzern Lese- und Ausführungsberechtigungen gewährt. Beispiele für Ressourcen, die von der Gruppe Administratoren und dem System gesteuert werden, sind das Verzeichnis Programme für Anwendungen oder die HKEY_LOCAL_MACHINE Struktur der Registrierung. Der Integritätsmechanismus verbessert nicht die Sicherheit von Objekten, die bereits ordnungsgemäß konfiguriert sind, um den Zugriff verschiedener Benutzerkonten oder Gruppen einzuschränken. Der Hauptzweck des Integritätsmechanismus besteht darin, verschiedene Berechtigungen für Programme für den Zugriff auf Ressourcen unter der vollständigen Kontrolle desselben Benutzersicherheitsprinzipals zu behandeln.

Die Ressourcen unter der Kontrolle desselben Benutzersicherheitsprinzipals, die zusätzlichen Schutz benötigen, befinden sich in erster Linie unter dem Profil des Benutzers (Verzeichnis C:\Benutzer\<Benutzername> und HKEY_CURRENT_USER Struktur in der Registrierung) und den Anwendungsprogrammen, die derzeit im Auftrag dieses Benutzers ausgeführt werden. Windows Vista verwendet den Integritätsmechanismus auf folgende Weise:

• In UAC schränkt es den Zugriff zwischen Prozessen ein, die mit Standardbenutzerberechtigungen ausgeführt werden, und prozessen mit erhöhten Rechten, die mit vollständigen Administratorrechten im Admin Genehmigungsmodus ausgeführt werden.
• DIE COM-Sicherheit kennt Integritätsstufen und erlaubt keine Bindung von Clients mit geringerer Integrität an Klasseninstanzen, die mit einer höheren Integritätsebene ausgeführt werden.
• In den Standardsicherheitseinstellungen wird der Zugriff auf den Stammordner des Systemvolumes eingeschränkt.
• Im geschützten Modus Internet Explorer schränkt es die Möglichkeit ein, dass Code, der im Internetbrowser ausgeführt wird, Benutzerdaten oder Benutzerprofileinstellungen ändern kann.
• Damit Anwendungen, die mit niedriger Integrität ausgeführt werden, einen schreibbaren Dateispeicherort erhalten, weist es bestimmten Ordnern im Benutzerprofil eine niedrige Integritätsebene zu.

Der Integritätsmechanismus ist Teil der Windows Vista-Sicherheitsarchitektur. Im Laufe der Zeit werden bestimmte Anwendungen aktualisiert, die nicht vertrauenswürdige Eingaben verarbeiten (hauptsächlich mit Internetzugriff), um die Möglichkeit zu nutzen, mit einer niedrigen Integritätsebene auszuführen. Persönliche Produktivitätsanwendungen können mit einer mittleren Integritätsebene ausgeführt werden, solange die Benutzer die Quelle der Eingabedaten kennen. Für die meisten Anwendungen ist der Integritätsmechanismus vollständig transparent und beeinträchtigt die Anwendungsfeatures nicht. Anwendungsdienste können aktualisiert werden, um eine bessere Isolation von Serverressourcen für Clientprozesse auf unterschiedlichen Integritätsebenen zu ermöglichen.

Integritätsebenen und UAC

UAC in Windows Vista führt mehrere Programme mit unterschiedlichen Zugriffsebenen auf demselben Desktop aus, wenn Admin Genehmigungsmodus verwendet wird. Programme verfügen über unterschiedliche Berechtigungen basierend auf dem Sicherheitszugriffstoken, das dem Prozess beim Erstellen des Prozesses zugewiesen ist. Benutzer mit Konten, die Standardbenutzer sind, verfügen während der Anmeldung über nur ein Sicherheitszugriffstoken. Dem Standardbenutzerzugriffstoken wird eine mittlere Integritätsebene zugewiesen. Das Standardbenutzerzugriffstoken mit mittlerer Integrität wird fast allen Anwendungsprozessen zugewiesen, die vom Benutzer ausgeführt werden. Bestimmte Anwendungen, z. B. internetgeschützte Modus-Explorer, stellen eine Ausnahme dar, die weiter unten beschrieben wird.

Benutzer mit Konten, die Mitglieder der Gruppe Administratoren sind, verfügen über zwei Sicherheitszugriffstoken, die bei der Anmeldung erstellt wurden und miteinander verknüpft sind. Ein Zugriffstoken ist ein Standardbenutzerzugriffstoken, dem eine mittlere Integritätsebene zugewiesen ist. Die Gruppe Administratoren wird nur für Zugriffsprüfungen verweigern verwendet, und bestimmte Administratorrechte wurden entfernt. Das zweite Zugriffstoken ist ein Vollzugriffstoken mit erhöhten Rechten, dem eine hohe Integritätsebene zugewiesen wird, da die Administratorgruppe und die Administratorrechte im Zugriffstoken vorhanden sind. Die Zugriffstoken sind verknüpft, da sie mit der gleichen interaktiven Anmeldung für dieses Benutzerkonto verknüpft sind. Beide Zugriffstoken verfügen über dieselbe Benutzer-SID und die gleichen globalen Gruppen aus Active Directory (mit Ausnahme der gefilterten Gruppen für Domäne und Enterprise Admin).

Dem Windows-Explorer (auch shell genannt) und allen Aufgaben ohne Administrator wird das Standardbenutzerzugriffstoken mit mittlerer Integrität zugewiesen. Für das Benutzerkonto, das Mitglied der Gruppe Administratoren ist, werden fast alle Anwendungen mit dem Zugriffstoken mit mittlerer Integrität ausgeführt. Die NO_WRITE_UP Integritätsrichtlinie schränkt die Zugriffsberechtigungen von Prozessen auf mittlerer Ebene nicht für den Zugriff auf Objekte ein, die eine implizite obligatorische Bezeichnung für mittlere Objekte aufweisen. Der Integritätsmechanismus ist für Anwendungen mit mittlerer Integritätsebene transparent, es sei denn, er ist für die Steuerung anderer Prozesse konzipiert, die möglicherweise mit einer höheren Berechtigungsebene ausgeführt werden. Windows UI Automation ist ein Beispiel für eine Anwendung, die zum Steuern anderer Prozesse konzipiert ist.

Der UAC-Admin-Genehmigungsmodus ermöglicht dem Benutzer das Starten von Verwaltungsaufgaben und Anwendungen, nachdem er die Zustimmung mit dem Token mit erhöhten Rechten erteilt hat. Das Betriebssystem muss die Möglichkeit des Prozesses mit niedrigeren Berechtigungen (Standardbenutzer) einschränken, den Prozess mit höheren Rechten (Administrator) direkt zu manipulieren, der unter derselben Benutzer-SID ausgeführt wird. Der Windows-Integritätsmechanismus schränkt die Zugriffsberechtigungen ein, die der Prozess mit mittlerer Integrität für den Prozess mit hoher Integrität haben kann. Der Prozess-Manager (Teil des Windows-Kernels) weist die obligatorischen Richtlinienoptionen NO_READ_UP und NO_WRITE_UP zu, um zu verhindern, dass Prozesse mit geringerer Integrität einen Prozess mit höherer Integrität für Lese- oder Schreibzugriff öffnen.

Der Prozess mit geringerer Integrität verfügt nur über generischen Ausführungszugriff. Der generische Ausführungszugriff umfasst Folgendes:

• SYNCHRONISIEREN, PROCESS_QUERY_LIMITED_INFORMATION
• PROCESS_TERMINATE

Der generische Lesezugriff auf einen Prozess mit höherer Integrität (PROCESS_VM_READ Zugriff auf den virtuellen Speicher eines Prozesses und PROCESS_QUERY_INFORMATION) ist eingeschränkt, um die Möglichkeit von Prozessen mit niedrigeren Berechtigungen zu blockieren, Lesezugriff auf Arbeitsspeicher zu erhalten, der Möglicherweise Kennwortdaten oder anderes Schlüsselmaterial enthalten, das für die Authentifizierung verwendet wird. Der generische Schreibzugriff auf den Prozess mit höherer Integrität wird durch die NO_WRITE_UP-Richtlinie blockiert. Zu den generischen Schreibprozesszugriffsrechten gehören:

• PROCESS_CREATE_THREAD
• PROCESS_VM_OPERATION
• PROCESS_VM_WRITE
• PROCESS_DUP_HANDLE
• PROCESS_SET_QUOTA
• PROCESS_SET_INFORMATION
• PROCESS_SET_PORT

Aktuelle Benutzerregistrierungsstruktur

Den meisten Objekten im Benutzerprofil wird keine explizite obligatorische Bezeichnung zugewiesen und weisen daher die implizite Standardintegritätsstufe medium auf. Dies gilt für die HKEY_CURRENT_USER (HKCU) der Registrierung. Schlüssel, die unter HKCU erstellt werden, weisen eine implizite mittlere Integritätsebene auf. Das bedeutet, dass für Benutzer, die Mitglieder der Gruppe Administratoren sind, die HKCU-Struktur von Anwendungen schreibbar ist, die entweder mit einem Standardbenutzerzugriffstoken mit mittlerer Integrität oder mit dem vollintegren Administratorzugriffstoken mit hoher Integrität ausgeführt werden. Dies muss aus Gründen der Anwendungskompatibilität der Fall sein. Denken Sie daran, dass die HKEY_LOCAL_MACHINE -Struktur (HKLM) über eine Standardsicherheitsrichtlinie verfügt, die Administratoren und dem System die vollständige Kontrolle und benutzerseitige Lese- und Ausführungszugriff gewährt. Die HKLM-Struktur kann nur durch Prozesse mit erhöhten Rechten geändert werden, denen das vollständige Administratorzugriffstoken zugewiesen ist. Die HKLM-Struktur ist nicht durch eine hohe Kennzeichnungspflicht geschützt.

Da die Standardintegritätsstufe für Objekte, die keine explizite obligatorische Bezeichnung aufweisen, mittel ist, ist es klar, dass Benutzer, die Mitglieder der Administratorgruppe sind, Programme mit unterschiedlichen Berechtigungsstufen (mittel und hoch) ausführen können, die HKCU- und Benutzerprofildaten gemeinsam nutzen. Windows Vista erzwingt keine strenge Grenze zwischen Prozessen mit mittlerer und hoher Integrität. Der Prozess mit hoher Integrität darf "nachgelesen" werden. Es ist üblich, dass Anwendungen, die mit einem Zugriffstoken mit voller Berechtigung und hoher Integrität ausgeführt werden, Konfigurationsinformationen aus HKCU lesen oder Eingabedateien akzeptieren, die sich auf das Verhalten des Prozesses mit hoher Integrität auswirken. Anwendungen, die mit vollständigen Berechtigungen ausgeführt werden, sollten HKLM verwenden, um Konfigurationsinformationen zu speichern, die nur von Administratoren geändert werden können. Anwendungen mit vollständigen Berechtigungen müssen außerdem überprüfen, ob die Benutzereingabedaten gut formatiert sind, bevor sie benutzerveränderbare Dateien verarbeiten.

COM ist integritätsbewusst

COM ist das Framework zum Erstellen von Anwendungskomponenten und Objektdiensten. Die COM-Infrastruktur kennt den Integritätsgrad eines Clients, der CoCreateInstance aufruft, und der Serverprozess, der eine Klasse instance ausführt. Die Bereiche der COM-Funktionalität, in denen Integritätsstufen das Verhalten beeinflussen, sind:

• Com-Erhöhungsmoniker ermöglicht Clients das Starten von Diensten mit erhöhten Rechten mit hoher Integritätsebene, nachdem der Administrator die Zustimmung erteilt hat, oder ein Standardbenutzer stellt explizite Administratoranmeldeinformationen bereit.
• Für Serverklassen, die über die mittlere Integritätsebene erhöht ausgeführt werden, muss die CLSID in der HKLM-Registrierungsstruktur definiert sein.
• COM verhindert, dass Clients mit niedrigerer Integritätsebene an ausgeführte Instanzen von Servern auf einer höheren Integritätsebene gebunden werden, es sei denn, der Server lässt programmgesteuert Zugriff von niedrigeren Clients zu.

Der COM-Erhöhungsmoniker ermöglicht Anwendungen mit niedriger oder mittlerer Integritätsebene das Starten von COM-Diensten in einem Prozess, der mit erhöhten Rechten bei hoher Integrität ausgeführt wird. Der Höhenmoniker ermöglicht bestimmte Aufgaben, die für die Ausführung mit erhöhten Rechten konzipiert sind und nicht für die vollständige Anwendungskompatibilität vorgesehen sind. DIE COM-Erhöhung ist in die UAC-Erhöhung integriert. Dem COM-Serverprozess mit erhöhten Rechten wird ein Vollzugriffstoken mit erhöhten Rechten mit hoher Integrität zugewiesen. COM erlaubt es Clients auf niedrigerer Ebene nicht, sich an eine ausgeführte instance des Servers auf einer höheren Integritätsebene zu binden.

Wenn ein COM-Server für die Unterstützung von Verbindungen von Clients mit geringerer Integrität konzipiert ist, kann der Server die Start-/Aktivierungsberechtigungen in der Registrierung für die CLSID programmgesteuert ändern, um die Bindung von einem Client mit geringerer Integrität zuzulassen. COM verwendet die NO_EXECUTE_UP obligatorische Richtlinie in einer obligatorischen Bezeichnung ACE, um zu steuern, ob Clients eine Bindung an einen Server instance auf höherer Integritätsebene zulässig sind. Die COM-Start-/Aktivierungszugriffsberechtigungen werden generischen Ausführungszugriffsrechten in der GENERIC_MAPPING zugeordnet, die von COM zum Überprüfen der Aktivierung verwendet werden. Die Integritätsebene in einer obligatorischen Bezeichnung, die dem Objekt zugeordnet ist, gibt die niedrigste Integritätsebene eines Clients an, der an den Server gebunden werden darf. Ähnlich wie beim Dateisystemzugriff ermöglicht die standardmäßige implizite obligatorische Richtlinie clients mit mittlerer Integrität die Bindung an Server.

Für COM-Server, die es einem Client mit niedriger Integrität ermöglichen, eine Bindung an eine instance des Servers zu ermöglichen, werden die COM-Aktivierungsberechtigungen durch den Servercode festgelegt.

So ermöglichen Sie einer Bindung eines Clients mit niedriger Integrität an den Server

1. Definieren Sie eine obligatorische Bezeichnung mit einer NO_EXECUTE_UP -Richtlinie (NX) für niedrige Integritätsebene. Die SDDL für den Objektsicherheitsdeskriptor mit der obligatorischen Bezeichnungsrichtlinie für niedrige Integrität lautet wie folgt:

   O:BAG:BAD:(A;;0xb;;;WD)S:(ML;;NX;;;LW)

2. Konvertieren Sie den Zeichenfolgensicherheitsdeskriptor in einen binären Sicherheitsdeskriptor.

3. Legen Sie die Startberechtigungen für die CLSID für die SERVER-CLSID mithilfe der binären Sicherheitsbeschreibung fest.

Die COM-Sicherheitsoberfläche dcomcfg.exe unterstützt keine Integritätsstufen.

Codebeispiele zum Festlegen einer obligatorischen Richtlinie für COM-Startberechtigungen finden Sie unter Windows Integrity Mechanism Resources (Ressourcen des Windows-Integritätsmechanismus ), um weitere Informationen zur Unterstützung von COM und Integritätsebene zu erhalten.

Diensten wird die Systemintegritätsebene zugewiesen.

Der Dienststeuerungs-Manager (Service Control Manager, SCM) startet Dienstprozesse mithilfe eines speziellen Dienstkontos oder eines Benutzernamens und Kennworts. Die speziellen Dienstkonten sind LocalSystem, LocalService und NetworkService. Dienste, die unter einem dieser Dienstkonten ausgeführt werden, verfügen über besondere Berechtigungen, z. B. das SE_IMPERSONATE_NAME-Recht, das es dem Dienst ermöglicht, Aktionen zu ergreifen, während er die Identität anderer Benutzer übernimmt. Windows Vista weist dem Prozessobjekt für Dienste, die unter einem der speziellen Dienstkonten ausgeführt werden, eine Systemintegritätsstufe zu. Die folgende Abbildung von Process Explorer zeigt die Systemintegritätsstufe, die dem Zugriffstoken für spezielle Dienstkonten zugewiesen ist.

Abbildung 6 Systemintegritätsstufe für Dienste

Obwohl der Dienstprozess über eine Systemintegritätsstufe verfügt, wird den sicherungsfähigen Objekten, die von diesen Subjekten erstellt wurden, keine system obligatorische Bezeichnung zugewiesen. Die von Diensten erstellten Objekte (mit Ausnahme von untergeordneten Prozessen, Threads, Zugriffstoken und Aufträgen) weisen eine implizite mittlere Integritätsebene auf.

Die Dienständerungen für Windows Vista beschreiben Änderungen an Diensten, um Die Sicherheit, Zuverlässigkeit und Verwaltbarkeit zu verbessern. Die Änderungen für Dienste verbessern die Systemsicherheit, indem Dienste in Sitzung 0 isoliert und die Ressourcen isoliert werden, auf die Dienste mithilfe von Dienst-SIDs zugreifen können. Die Systemintegritätsstufe für spezielle Dienstkonten ist mit den Dienstisolationszielen konsistent. Dienstprozesse, die auf der Systemintegritätsebene ausgeführt werden, werden durch einen Prozess mit niedrigerer Integrität vor dem Zugriff geschützt. Die Prozesszugriffsrechte, die für Prozesse mit niedrigerer Integrität zum Öffnen eines Dienstprozesses verfügbar sind, sind auf Folgendes beschränkt:

• SYNCHRONIZE
• PROCESS_QUERY_LIMITED_INFORMATION
• PROCESS_TERMINATE

Einige Anwendungen werden mit mehreren kooperativen Prozessen entworfen, die möglicherweise in einem oder mehreren Dienstkonten ausgeführt werden. Die meisten Interprocess Communication (IPC)-Mechanismen zwischen Prozessen und Diensten, z. B. RPC, sind nicht durch die Integritätsebene eingeschränkt. Dienste müssen besonders vorsichtig sein, um Eingaben von Clients mit niedriger Integrität zu überprüfen.

Duplizieren von Handles zwischen Diensten

Dienstanwendungen, die mehrere Prozesse verwenden, sind manchmal so konzipiert, dass Handles zwischen Serverprozessen in Objekte, z. B. Dateien, dupliziert werden. Wenn alle Prozesse unter demselben speziellen Dienstkonto ausgeführt werden, führt die Standardsicherheit für Dienstprozesse keine Einschränkungen. Die Standard-DACL für Dienstprozesse, die unter speziellen Dienstkonten ausgeführt werden, gewährt keinen PROCESS_DUP_HANDLE Zugriff, der für DuplicateHandle-Aufrufe erforderlich ist. Anwendungsdienst-Designer müssen Funktionen implementieren, um PROCESS_DUP_HANDLE Zugriff auf das Dienstprozessobjekt einem anderen Benutzerkonto zu gewähren, das von einem Co-Prozess verwendet wird, um Handles zwischen Anwendungsprozessen freizugeben, die unter unterschiedlichen Benutzerkonten ausgeführt werden. Wenn es sich bei dem Dienst, in den Sie das Handle duplizieren möchten, jedoch um ein spezielles Dienstkonto handelt, das auf einer Systemintegritätsstufe ausgeführt wird, kann ein Mitprozess, der auf einer hohen oder mittleren Integritätsstufe ausgeführt wird, aufgrund der obligatorischen Bezeichnungsrichtlinie keine PROCESS_DUP_HANDLE abrufen. Selbst wenn die DACL PROCESS_DUP_HANDLE Zugriff gewährt, lässt die obligatorische Bezeichnungsrichtlinie Aufrufern mit niedriger Integrität keinen Zugriff zu. Wenn sich diese Situation auf den Dienstanwendungsentwurf auswirkt, muss sich der Anwendungsdienstcode ändern, sodass sich der Prozess, der DuplicateHandle initiiert, auf einer Integritätsebene befindet, die höher ist als die Integritätsebene des Prozesses, der die Quelle des Handles ist. Das heißt, ein Dienst mit höherer Integrität kann ein Handle aus einem Prozess mit niedrigerer Integrität als Handlequelle in einen eigenen Prozess als Ziel duplizieren.

Identitätswechselrichtlinie

Die berechtigung SE_IMPERSONATE_NAME ermöglicht es einem Serverprozess, die Identität des Sicherheitskontexts eines Clientprozesses zu annehmen. Die Berechtigung Identitätswechsel ist ein leistungsstarkes Recht. Der Integritätsmechanismus ordnet die Identitätswechselberechtigung Zugriffstoken zu, die eine hohe Oder Systemintegritätsstufe aufweisen. Der Integritätsmechanismus erzwingt die Richtlinie, dass ein Antragsteller die Identität eines Clients auf einer höheren Integritätsebene annehmen kann, nur wenn er über die Berechtigung Identitätswechsel verfügt.

Ein Szenario, in dem diese Richtlinieneinschränkung gilt, wäre, wenn ein Prozess mit niedriger Integrität die Benutzeroberfläche spooft, um einen Administratorbenutzer zur Eingabe von Administratoranmeldeinformationen zu bewegen. Der schädliche Code verwendet die Anmeldeinformationen, um LsaLogonUser und ImpersonateLoggedOnUser aufzurufen, um zu versuchen, einen Prozess mit einer höheren Berechtigungsstufe zu starten. Die Integritätsmechanismusrichtlinie für Identitätswechsel-Zugriffstoken lautet, dass die Integritätsebene des Zugriffstokens, das von LsaLogonUser zurückgegeben wird, nicht höher als die Integritätsebene des aufrufenden Prozesses sein darf.

Stammordner mit hoher Integritätsebene

Der Stammordner der Systempartition, in der Regel C:\ , wurde in der Vergangenheit als praktischer Ort zum Speichern von Programmen oder temporären Dateien verwendet, obwohl die Vorgehensweise nicht empfohlen wird. Setupprogramme, die Administratorrechte erfordern, werden häufig vor dem Start in den Stammordner kopiert. Die Standardsicherheitsrichtlinie für den Stammordner ist so konzipiert, dass authentifizierte Benutzer Unterordner unter dem Stammordner erstellen können, aber nur Administratoren können Dateien im Stammordner erstellen. Darüber hinaus erlaubt die Richtlinie idealerweise nicht administrativen Benutzern, Dateien in dem Ordner zu ändern, die von Administratoren erstellt wurden. Diese Richtlinie lässt sich nur schwer definieren, indem nur die ACL für den Stammordner verwendet wird.

Durch Das Festlegen einer obligatorischen Bezeichnung mit einer hohen Integritätsstufe, die für untergeordnete Objekte, aber nicht für untergeordnete Container gilt, erfüllt die Standardsicherheit für den Stammordner diese Richtlinie. Standardbenutzer, die Programme mit mittlerer Integritätsstufe ausführen, können dateien, die von Administratoren im Stammordner erstellt wurden, auch dann nicht ändern, wenn die ACL Benutzern Zugriff auf Änderungen gewährt. Der Stammordner verfügt über eine vererbbare obligatorische Bezeichnung mit hoher Integrität, die objektvererbt ist und nicht an Unterordner weitergegeben wird.

Die folgende Abbildung zeigt die Standardsicherheitseinstellungen für C:\ Stammordner, einschließlich des Objekts erben obligatorische Bezeichnung bei hoher Integrität. Tabelle 9 zeigt die Definitionen für die Abkürzungen in der Abbildung.

Tabelle 9 Bildabkürzungen

Abkürzung	Definition
(OI)	Objekterben
(NP)	Keine Weitergabe
(E/A)	Nur erben
(NW)	Kein Schreibvorgang

Abbildung 7 Obligatorische Bezeichnung im Stammordner

Internet im geschützten Modus Explorer mit niedriger Integrität

Internet Explorer ist ein Beispiel für eine Anwendung, die dafür konzipiert ist, beliebige Daten und erweiterbaren Code aus dem Internet zu akzeptieren. Da die Quelle von Internetinhalten selten authentifiziert (signiert) wird, müssen wir davon ausgehen, dass alle Eingaben aus dem Internet nicht vertrauenswürdig sind. Angriffe auf das Internet Explorer oder gegen einen anderen Internetbrowser zeigen, wie vertrauenswürdig dynamische Inhalte und Daten aus dem Internet sind. Aus Sicherheitssicht gehen wir davon aus, dass der Internet-Explorer Prozess selbst kompromittiert und nicht vertrauenswürdig ist, und wir suchen nach Lösungen, die den potenziellen Schaden begrenzen, der durch Angriffe auf den Browser verursacht wird. Einige vorgeschlagene Lösungen für browserbasierte Angriffe versuchen, den Webbrowser vollständig von anderen Anwendungen und Daten zu isolieren. Leider hat die vollständige Isolation des Browsers erhebliche Auswirkungen auf die Browsererfahrung des Benutzers, z. B. die Möglichkeit, Programme automatisch zu starten, um verschiedene Dateitypen zu lesen, z. B. .pdf Dateien. Die vollständige Isolation behindert allgemeine Benutzeroberflächen, z. B. das Hochladen von Bildern auf Websites, wenn der Browser keinen Lesezugriff auf Benutzerdatendateien hat.

Das Ziel von Internet-Explorer im geschützten Modus ist es, die für den Prozess verfügbaren Zugriffsrechte zu reduzieren, um die Fähigkeit eines exploits, der im Browser ausgeführt wird, unerwünschte Startdateien zu erstellen, Benutzerdatendateien zu ändern, lästige Änderungen an Browserkonfigurationseinstellungen vorzunehmen oder das Verhalten anderer Programme zu steuern, die auf dem Desktop ausgeführt werden. Der gesamte Code, der im geschützten Modus internet Explorer in einem Prozess mit niedriger Integrität ausgeführt wird, gilt als nicht vertrauenswürdig. Die standardmäßige mittlere Integritätsstufe für Objekte verhindert, dass der Browser Verzeichnisse, Dateien oder Registrierungsschlüssel für den Schreibzugriff öffnet, mit Ausnahme derjenigen, die explizit mit niedriger Integrität gekennzeichnet sind. UIPI verhindert, dass der Browsercode mit niedriger Integrität potenziell schädliche Fensternachrichten an andere Anwendungen sendet, die auf dem Desktop ausgeführt werden.

Der Browser, der mit niedriger Integrität ausgeführt wird, verfügt über Lesezugriff auf Benutzerdatendateien. Da der Windows-Integritätsmechanismus keine Vertraulichkeit erzwingt, schränkt er den Informationsfluss nicht ein. Der Prozess kann auch Standardanmeldeinformationen verwenden, um Netzwerkverbindungen zu initiieren, z. B. mit einem Netzwerkproxyserver (erforderlich, wenn eine Authentifizierung erforderlich ist, um eine Verbindung mit dem Internet herzustellen) oder mit einem Netzwerkdruckergerät, um eine Webseite zu drucken. Der Prozess mit niedriger Integrität kann auch eine authentifizierte Verbindung mit anderen Netzwerkdiensten initiieren und sich dadurch bei diesen Servern als aktueller Benutzer authentifizieren.

Der Anwendungsentwurf des Internet-Explorer musste umstrukturiert werden, um im geschützten Modus mit niedriger Integritätsstufe ausgeführt zu werden. Die primäre Änderung besteht darin, dass bestimmte Programmvorgänge in einen separaten Prozess verschoben wurden, der als Brokerprozess bezeichnet wird und auf einer mittleren Integritätsebene ausgeführt wird. Der Brokerprozess wird auf mittlerer Integritätsebene gestartet, wenn der Benutzer auf das Symbol "Internet Explorer" oder auf einen URL-Link klickt. Der Broker überprüft die URL- und Zonenrichtlinie und startet einen untergeordneten Prozess iexplore.exe auf der niedrigen Integritätsebene, um die Internetverbindung herzustellen und die Webseite zu rendern. Die folgende Abbildung aus Process Explorer zeigt die ieuser.exe, den Brokerprozess auf mittlerer Integritätsebene und den iexplore.exe Prozess mit niedriger Integritätsebene.

Abbildung 8 Internet-Explorer-Prozesse im geschützten Modus

Alle Benutzeroberflächen im Internet Explorer Webbrowser werden innerhalb des Prozesses mit niedriger Integrität durchgeführt. Einige bestimmte Vorgänge, z. B. das Ändern der Einstellungen für Internetoptionen oder das Dialogfeld Als Datei speichern , werden vom Brokerprozess verarbeitet. Wenn es sich bei der URL um eine vertrauenswürdige Website handelt, startet der Brokerprozess basierend auf den Richtlinieneinstellungen der Standardzone eine andere instance von iexplore.exe in einem Prozess mit mittlerer Integrität. Alle Browsererweiterungen und ActiveX-Steuerelemente werden innerhalb des Prozesses mit niedriger Integrität ausgeführt. Dies hat den Vorteil, dass alle potenziellen Exploits für eine Browsererweiterung ebenfalls mit niedriger Integrität ausgeführt werden.

Internet Explorer ist etwas komplizierter als andere Anwendungen, da es Browsererweiterungen und ActiveX-Steuerelemente hostet, die nicht von Microsoft entwickelt werden, andere Anwendungen gestartet werden, die auf MIME-Typen für verschiedene Dateierweiterungen basieren, und es integriert das Clientfenster aus verschiedenen Anwendungen in einem einzigen übergeordneten Fensterrahmen. Benutzer laden auch Software aus dem Internet über den Browser herunter und starten sofort ein Anwendungspaket oder ein Anwendungsinstallationsprogramm. Viele dieser Vorgänge erfordern Hilfe vom Brokerprozess auf einer höheren Integritätsebene, um durch den Benutzer zu vermitteln, um einen Vorgang zu bestätigen. Andernfalls könnte code, der im Browser ausgeführt wird, schadhafte Software auf dem System installieren und versuchen, die Daten des Benutzers zu ändern oder zu löschen. Die Installation von ActiveX-Steuerelementen erfolgt mithilfe einer von der UAC gestarteten Aufgabe mit erhöhten Rechten, die Administratorrechte erfordert.

Da internet Explorer eine Vielzahl von Benutzerinteraktionen zwischen dem Browser und anderen lokalen Anwendungen unterstützt (kopieren und einfügen ist ein offensichtliches Beispiel), ist der Integritätsmechanismus, der den Schreibzugriff auf Objekte beschränkt, kein vollständiger Isolationsmechanismus. Der Entwurf des internetgeschützten Modus Explorer viele verschiedene Interaktionen untersucht und das Verhalten des Brokers und des iexplore.exe-Prozesses mit geringen Rechten speziell angepasst, um die Funktionalität mit den geringsten Rechten beizubehalten und gleichzeitig eine umfassende, hochgradig kollaborative Benutzererfahrung zu bieten.

Weitere Informationen zu Internet-Explorer im geschützten Modus finden Sie unter Grundlegendes und Arbeiten im internetgeschützten Modus Explorer (https://go.microsoft.com/fwlink/?LinkId=90931).