Windows-Verwaltung

Einblick in den Windows Vista-Kernel: Teil 3

Mark Russinovich

Kurz zusammengefasst:

• Zuverlässigkeit
• Wiederherstellung
• Sicherheit

In dieser Serie wurden bisher Verbesserungen beim Windows Vista-Kernel im Zusammenhang mit Prozessen, E/A, Speicherverwaltung, Systemstart, Herunterfahren und Energieverwaltung behandelt. Dieser dritte und letzte

Teil dreht sich um Features und Verbesserungen in den Bereichen Zuverlässigkeit, Wiederherstellung und Sicherheit.

Ein Feature, das ich in dieser Serie nicht behandle, ist die Benutzerkontensteuerung (User Account Control, UAC), die verschiedene Technologien umfasst, unter anderem die Virtualisierung von Dateisystem und Registrierung bei Legacyanwendungen, Zustimmung für den Zugriff auf Administratorrechte sowie den Windows®-Integritätsebenenmechanismus zum Isolieren von Prozessen, die mit Administratorrechten von weniger privilegierten Prozessen im selben Konto ausgeführt werden. In einer zukünftigen Ausgabe des TechNet Magazins werde ich die UAC-Internals ausführlich behandeln.

Windows Vista™ verbessert die Zuverlässigkeit Ihres Systems und die Fähigkeit, System- und Anwendungsprobleme mithilfe einer Reihe neuer Features und Verbesserungen zu diagnostizieren. Die Kernelprotokollierung „Ereignisablaufverfolgung für Windows“ (Event Tracing for Windows, ETW) ist immer aktiv und generiert Ablaufverfolgungen für Datei, Registrierung, Interrupt und andere Arten von Aktivitäten in einem Umlaufpuffer. Beim Auftreten eines Problems kann die neue Windows-Diagnoseinfrastruktur (WDI) einen Snapshot des Puffers aufzeichnen und diesen lokal analysieren oder zur Problembehandlung zum Microsoft-Support hochladen.

Die neue Windows-Zuverlässigkeits- und Leistungsüberwachung hilft Benutzern, Fehler wie z. B. Abstürze mit Änderungen an der Systemkonfiguration in Verbindung zu bringen. Das leistungsfähige System Repair Tool (SRT) ersetzt die Wiederherstellungskonsole bei der Offlinewiederherstellung von nicht startbaren Systemen.

Es gibt drei Bereiche, die Änderungen am System auf Kernelebene erfordern und daher in diesem Artikel näher betrachtet werden sollten: Kerneltransaktions-Manager (KTM), verbesserte Absturzbehandlung und das Feature „Vorherige Versionen“.

Kerneltransaktions-Manager

Einer der aufwändigeren Aspekte der Softwareentwicklung ist die Behandlung von Fehlern. Dies gilt besonders dann, wenn beim Durchführen eines Vorgangs auf höchster Ebene eine Anwendung eine oder mehrere Teilvorgänge abgeschlossen hat, die zu Änderungen im Dateisystem oder in der Registrierung führen. Der Softwareaktualisierungsdienst einer Anwendung könnte beispielsweise mehrere Registrierungsaktualisierungen vornehmen, die ausführbaren Dateien der Anwendung ersetzen und dann beim Aktualisierungsversuch für eine zweite ausführbare Datei keinen Zugriff mehr erhalten. Wenn der Dienst die Anwendung nicht im daraus resultierenden inkonsistenten Zustand belassen will, muss er alle bereits durchgeführten Änderungen nachverfolgen und rückgängig machen. Das Testen des Wiederherstellungscodes nach Fehlern ist schwierig und wird daher oft ausgelassen. Mögliche Fehler im Wiederherstellungscode machen daher jeden Wiederherstellungsversuch zunichte.

Für Anwendungen, die für Windows Vista geschrieben wurden, können bei sehr geringem Aufwand mithilfe der neuen Transaktionsunterstützung in NTFS und der Registrierung mit dem Kerneltransaktions-Manager automatische Funktionen zur Wiederherstellung nach Fehlern hinzugefügt werden. Wenn eine Anwendung eine Reihe von aufeinander bezogenen Änderungen vornehmen will, kann sie entweder eine DTC-Transaktion (Distributed Transaction Coordinator) und ein KTM-Transaktionshandle erstellen oder direkt ein KTM-Handle erstellen und die Änderungen der Dateien und Registrierungsschlüssel der Transaktion zuordnen. Wenn alle Änderungen erfolgreich sind, übergibt die Anwendung die Transaktion, und die Änderungen werden angewendet. Bis zu diesem Punkt kann die Anwendung die Transaktion jedoch jederzeit zurücksetzen, sodass die Änderungen zurückgewiesen werden.

Ein weiterer Vorteil besteht darin, dass andere Anwendungen die in einer Transaktion vorgenommenen Änderungen erst sehen, wenn die Transaktion übergeben wird. Anwendungen, die den DTC in Windows Vista und die zukünftige Windows Server®-Version mit dem Codenamen „Longhorn“ verwenden, können ihre Transaktionen mit SQL Server™, Microsoft® Message Queue Server (MSMQ) und anderen Datenbanken koordinieren. Ein Anwendungsaktualisierungsdienst, der KTM-Transaktionen verwendet, wird die Anwendung daher nie in einem inkonsistenten Zustand belassen. Aus diesem Grund verwenden sowohl Windows Update als auch die Systemwiederherstellung Transaktionen.

Als Kern der Transaktionsunterstützung ermöglicht KTM Transaktionsressourcenmanagern wie z. B. NTFS und der Registrierung, die Aktualisierungen für einen bestimmten Satz an von einer Anwendung durchgeführten Änderungen zu koordinieren. In Windows Vista verwendet NTFS eine Erweiterung zur Unterstützung von Transaktionen, die als TxF bezeichnet wird. Die Registrierung verwendet eine ähnliche Erweiterung mit der Bezeichnung TxR. Diese Kernelmodus-Ressourcen-Manager arbeiten mit dem KTM zusammen, um den Transaktionszustand zu koordinieren, ähnlich wie Benutzermodus-Ressourcen-Manager den DTC zum Koordinieren des Transaktionszustands über mehrere Benutzermodus-Ressourcen-Manager hinweg verwenden. Dritte können den KTM ebenfalls zum Implementieren ihrer eigenen Ressourcen-Manager verwenden.

Sowohl TxF als auch TxR definieren einen neuen Satz an Dateisystem- und Registrierungs-APIs, die vorhandenen ähnlich sind, aber zusätzlich einen Transaktionsparameter enthalten. Wenn eine Anwendung eine Datei innerhalb einer Transaktion erstellen will, verwendet sie zunächst KTM zum Erstellen der Transaktion und übergibt dann das resultierende Transaktionshandle an die zum Erstellen einer neuen Datei vorgesehene API.

TxF und TxR basieren auf der Funktion zur Hochgeschwindigkeitsdateisystemprotokollierung des gemeinsamen Protokolldateisystems oder CLFS (%SystemRoot%\System32\Clfs.sys), das in Windows Server 2003 R2 eingeführt wurde. TxR und TxF verwenden CLFS, um Änderungen am Transaktionszustand dauerhaft zu speichern, bevor sie eine Transaktion übergeben. So können sie Transaktionswiederherstellung und Zusicherungen selbst bei einem Stromausfall bereitstellen. Zusätzlich zum CLFS-Protokoll erstellt TxR einen Satz zugehöriger Protokolldateien zum Verfolgen von Transaktionsänderungen an der Registrierungsdatei des Systems in %Systemroot%\System32\Config\Txr, wie in Abbildung 1 dargestellt, sowie separate Sätze an Protokolldateien für jede Benutzerregistrierungsstruktur. TxF speichert Transaktionsdaten für jedes Volume in einem ausgeblendeten Verzeichnis in dem als $Extend\$RmMetadata bezeichneten Volume.

Abbildung 1** TxR-Protokolldateien der Systemregistrierungsstruktur  **(Klicken Sie zum Vergrößern auf das Bild)

Verbesserter Support bei Abstürzen

Wenn in Windows ein nicht behebbarer Kernelmodusfehler auftritt (egal, ob dieser auf einen fehlerhaften Gerätetreiber, fehlerhafte Hardware oder das Betriebssystem zurückzuführen ist), wird versucht, die Beschädigung von Daten auf Datenträgern zu verhindern, indem das System nach Anzeige des berüchtigten blauen Absturzbildschirms angehalten wird. Bei entsprechender Konfigurierung wird der Inhalt eines Teils oder des gesamten physischen Speichers in eine Absturzsicherungsdatei geschrieben. Sicherungsdateien sind nützlich, da der OCA-Dienst (Microsoft Online Crash Analysis) bei einem Neustart nach einem Absturz eine Analyse dieser Dateien anbietet, um die Ursache zu ermitteln. Wenn Sie möchten, können Sie die Dateien auch selbst mithilfe der Microsoft-Debuggingtools für Windows analysieren.

In früheren Versionen von Windows wurde der Support für Absturzsicherungsdateien erst aktiviert, wenn der Sitzungs-Manager-Prozess (%Systemroot%\System32\Smss.exe) die Auslagerungsdateien initialisiert hatte. Dies bedeutete, dass kritische Fehler bis zu diesem Zeitpunkt zu einem blauen Bildschirm führten, ohne dass eine Sicherungsdatei erstellt wurde. Da der Hauptteil der Gerätetreiberinitialisierung vor dem Start von Smss.exe erfolgt, resultierten frühe Abstürze nie in Absturzsicherungsdateien, was die Diagnose der Ursache äußerst schwierig gestaltete.

Windows Vista verkürzt den Zeitraum, in dem keine Sicherungsdatei generiert wird, durch Initialisierung der Unterstützung für Sicherungsdateien, nachdem alle Systemstartgerätetreiber initialisiert wurden, jedoch vor dem Laden der Systemstarttreiber. Wenn es nun zu Beginn des Startprozesses zu einem Absturz kommt, kann das System aufgrund dieser Änderung eine Absturzsicherungsdatei erstellen, sodass OCA Ihnen beim Lösen des Problems helfen kann. Des Weiteren speichert Windows Vista Daten in einer Sicherungsdatei in Blöcken von 64 KB, während es bei früheren Windows-Versionen Blöcke von 4 KB waren. Diese Änderung führt zu größeren Sicherungsdateien, die bis zu zehnmal schneller geschrieben werden.

Das Behandeln von Anwendungsabstürzen wurde in Windows Vista ebenfalls verbessert. Bei früheren Windows-Versionen führte der Absturz einer Anwendung einen unbehandelten Ausnahmehandler aus. Der Handler startete den AER-Prozess (Microsoft Application Error Reporting) (%Systemroot%\System32\Dwwin.exe) und zeigte einen Dialog an, dass das Programm abgestürzt ist und ob Sie einen Fehlerbericht an Microsoft senden wollen. Doch wenn der Stapel des Hauptthreads des Prozesses während des Absturzes beschädigt wurde, stürzte der unbehandelte Ausnahmehandler während der Ausführung ab, was zur Beendigung des Prozesses durch den Kernel, das sofortige Verschwinden der Programmfenster und zur Nichtanzeige des Dialogs zur Fehlerberichterstattung führte.

Windows Vista verschiebt die Fehlerbehandlung aus dem Kontext des Absturzprozesse in einen neuen Dienst, die Windows-Fehlerberichterstattung (Windows Error Reporting, WER). Dieser Dienst wird von einer DLL (%Systemroot%\System32\Wersvc.dll) innerhalb eines Dienstshostprozesses implementiert. Wenn eine Anwendung abstürzt, führt sie immer noch einen unbehandelten Ausnahmehandler aus, doch dieser Handler sendet eine Nachricht an den WER-Dienst, und dieser Dienst startet dann den WER Fault Reporting-Prozess (%Systemroot%\System32\Werfault.exe) und zeigt den Dialog zur Fehlerberichterstattung an. Wenn der Stapel beschädigt ist und der unbehandelte Ausnahmehandler abstürzt, wird der Handler erneut ausgeführt und stürzt erneut ab, bis er schließlich den gesamten Stack des Threads (Scratchspeicherbereich) verwendet hat. Zu diesem Zeitpunkt greift der Kernel ein und sendet die Absturzbenachrichtigung an den Dienst.

Der Unterschied zwischen diesen beiden Ansätzen ist in Abbildung 2 und 3 dargestellt. Die Abbildungen zeigen die Prozessbeziehung von Accvio.exe, einem Testprogramm, das abstürzt, und die in Grün hervorgehobenen Fehlerberichterstattungsprozesse unter Windows XP und Windows Vista. Die neue Fehlerbehandlungsarchitektur von Windows Vista bedeutet, dass Programme nicht mehr ohne Warnung beendet werden, ohne dass die Möglichkeit besteht, einen Fehlerbericht an Microsoft zu senden, sodass Softwareentwickler ihre Anwendungen verbessern können.

Abbildung 2a** Fehlerbehandlung bei Anwendungen unter Windows XP **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 2b(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3a** Fehlerbehandlung bei Anwendungen unter Windows Vista **(Klicken Sie zum Vergrößern auf das Bild)

Abbildung 3b

Volumeschattenkopie

Unter Windows XP wurde eine Technologie mit der Bezeichnung Volumeschattenkopie eingeführt, um zu einem bestimmten Zeitpunkt Snapshots von Datenträgervolumes zu erstellen. Sicherungsanwendungen können diese Snapshots verwenden, um konsistente Sicherungsabbilder zu erstellen, doch ansonsten sind die Snapshots ausgeblendet und werden nur für die Dauer des Sicherungsprozesses beibehalten.

Die Snapshots sind nicht wirklich umfassende Kopien der Volumes. Sie sind vielmehr Ansichten eines Volumes zu einem früheren Zeitpunkt, die die mit Kopien von Volumesektoren überlagerten Livevolumedaten umfassen, die sich seit Erstellen des Snapshot geändert haben. Der Volume Snapshot Provider-Treiber (%Systemroot\%System32\Drivers\Volsnap.sys) überwacht Volumevorgänge und erstellt Sicherungskopien von Sektoren, bevor Änderungen an diesen zugelassen werden. Die ursprünglichen Daten werden in einer Datei gespeichert, die dem Snapshot im Verzeichnis „System Volume Information“ des Volumes zugeordnet ist.

Windows Server 2003 stellte Administratoren auf dem Server und Benutzern auf Clientsystemen die Snapshotverwaltung mit Schattenkopien von freigegebenen Ordnern zur Verfügung. Dieses Feature ermöglichte permanente Snapshots von Ordnern und Dateien in den Dateifreigaben des Servers, auf die die Benutzer über die Registerkarte „Vorherige Versionen“ in den Dialogfeldern für Explorer-Eigenschaften zugreifen konnten.

Das Feature „Vorherige Versionen“ bei Windows Vista stellt diesen Support für alle Clientsysteme zur Verfügung und erstellt automatisch Volumesnapshots (normalerweise einmal pro Tag), auf die Sie über die Explorer-Eigenschaftendialogfelder über dieselbe Schnittstelle zugreifen können, die von Schattenkopien für freigegebene Ordner verwendet wird. Dies ermöglicht Ihnen das Anzeigen, Wiederherstellen oder Kopieren alter Versionen von Dateien und Verzeichnissen, die Sie möglicherweise unbeabsichtigt geändert oder gelöscht haben. Während es sich aus technischer Sicht nicht um eine neue Technologie handelt, optimiert die Implementierung der Volumeschattenkopie unter Windows Vista mittels „Vorherige Versionen“ die Technologie von Windows Server 2003 bei Verwendung in Clientdesktopumgebungen.

Windows Vista nutzt Volumesnapshots außerdem, um Benutzer- und Systemdatenschutzmechanismen zu vereinheitlichen und das Speichern redundanter Sicherungsdaten zu vermeiden. Wenn eine Anwendungsinstallation oder Konfigurationsänderung falsche oder unerwünschte Verhaltensweisen verursacht, können Sie die Systemwiederherstellung verwenden, ein Feature, das in der Windows NT®-Reihe von Windows XP-Betriebssystemen eingeführt wurde, um den Zustand von Systemdateien und Daten wiederherzustellen, der beim Erstellen eines Wiederherstellungspunkts vorhanden war.

In Windows XP verwendet die Systemwiederherstellung einen Dateisystemfiltertreiber (ein Treibertyp, der Änderungen auf Dateiebene sehen kann), um Sicherungskopien von Systemdateien zum Zeitpunkt der Änderung zu erstellen. Bei Windows Vista verwendet die Systemwiederherstellung Volumesnapshots. Wenn Sie die Benutzeroberfläche für die Systemwiederherstellung in Windows Vista verwenden, um zu einem Wiederherstellungspunkt zurückzukehren, kopieren Sie im Grunde frühere Versionen der geänderten Systemdateien aus dem Snapshot, der dem Wiederherstellungspunkt zugeordnet ist, in das Livevolume.

BitLocker

Windows Vista ist die bisher sicherste Version von Windows. Neben dem Windows Defender-Antispywaremodul führt Windows Vista zahlreiche Sicherheits- und Tiefenverteidigungsfeatures ein wie beispielsweise die vollständige BitLocker™-Volumeverschlüsselung, die Codesignierung für Kernelmoduscode, geschützte Prozesse, Address Space Load Randomization und Verbesserungen bei der Windows-Dienstsicherheit und Benutzerkontensteuerung.

Ein Betriebssystem kann seine Sicherheitsrichtlinien nur durchsetzen, während es aktiv ist. Daher müssen Sie zusätzliche Maßnahmen ergreifen, um Daten zu schützen, wenn die physische Sicherheit eines Systems gefährdet ist und von außerhalb des Betriebssystems auf die Daten zugegriffen werden kann. Hardwarebasierte Mechanismen wie z. B. BIOS-Kennwörter und Verschlüsselung sind zwei häufig verwendete Technologien, um nicht autorisierten Zugriff besonders auf Laptops zu verhindern, bei denen die Wahrscheinlichkeit am größten ist, dass sie verloren gehen oder gestohlen werden.

Windows 2000 hat die Dateiverschlüsselung mit EFS (Encrypting File System) eingeführt. In der Windows Vista-Version umfasst EFS eine Reihe von Verbesserungen gegenüber früheren Implementierungen, einschließlich Leistungsverbesserungen, Support für das Verschlüsseln der Auslagerungsdatei und das Speichern von EFS-Schlüsseln von Benutzern auf Smartcards. Sie können EFS jedoch nicht verwenden, um den Zugriff auf vertrauliche Systembereiche wie z. B. die Registrierungsstrukturdateien zu schützen. Wenn Ihnen die Gruppenrichtlinie beispielsweise das Anmelden bei Ihrem Laptop selbst dann ermöglicht, wenn Sie nicht mit einer Domäne verbunden sind, wird die Überprüfung Ihrer Domänenanmeldeinformationen in der Registrierung zwischengespeichert, sodass Angreifer Tools verwenden könnten, um Ihr Kennworthash für das Domänenkonto zu erhalten, mithilfe dessen sie dann versuchen könnten, das Kennwort zu knacken. Mit dem Kennwort könnten Angreifer dann auf Ihr Konto und Ihre EFS-Dateien zugreifen (vorausgesetzt, Sie haben den EFS-Schlüssel nicht auf einer Smartcard gespeichert).

Um das Verschlüsseln des gesamten Startvolumes (das Volume mit dem Windows-Verzeichnis) einschließlich aller Systemdateien und Daten zu erleichtern, führt Windows Vista eine Feature für vollständige Volumeverschlüsselung mit der Bezeichnung Windows BitLocker-Laufwerkverschlüsselung ein. Im Unterschied zum EFS, das vom NTFS-Dateisystemtreiber implementiert wird und auf Dateiebene arbeitet, verschlüsselt BitLocker auf der Volumeebene mithilfe des FVE-Treibers (Full Volume Encryption, vollständige Volumeverschlüsselung) (%Systemroot%\System32\Drivers\Fvevol.sys) wie in Abbildung 4 dargestellt.

Abbildung 4** BitLocker FVE-Filtertreiber **(Klicken Sie zum Vergrößern auf das Bild)

FVE ist ein Filtertreiber, d. h., er sieht automatisch alle E/A-Anforderungen, die vom NTFS an das Volume gesendet werden, wobei Blöcke mithilfe des Schlüssels zur vollständigen Volumeverschlüsselung (Full Volume Encryption Key, FVEK), der dem Volume bei der anfänglichen Konfiguration zur Verwendung von BitLocker zugewiesen wird, beim Schreiben verschlüsselt und beim Lesen entschlüsselt werden. Standardmäßig werden Volumes mit einem 128-Bit-AES-Schlüssel und einem 128-Bit-Diffusorschlüssel verschlüsselt. Da die Verschlüsselung und die Entschlüsselung unter dem NTFS im E/A-System erfolgt, scheint das Volume für NTFS unverschlüsselt zu sein, und NTFS muss nicht einmal wissen, dass BitLocker aktiviert ist. Wenn Sie versuchen, außerhalb von Windows Daten aus dem Volume zu lesen, scheint es sich um zufällige Daten zu handeln.

Der FVEK wird mit einem Volumehauptschlüssel (Volume Master Key, VMK) verschlüsselt und in einem speziellen Metadatenbereich des Volumes gespeichert. Bei der Konfigurierung von BitLocker stehen Ihnen je nach Hardwarefunktionen des Systems eine Reihe von Optionen zum Schutz des VMK zur Verfügung. Wenn das System über ein Trusted Platform Module (TPM) verfügt, das Version 1.2 der TPM-Spezifikation entspricht und über entsprechenden BIOS-Support verfügt, können Sie den VMK entweder mit dem TPM verschlüsseln, die Verschlüsselung des VMK über das System mithilfe eines im TPM und eines auf einem USB-Flashlaufwerk gespeicherten Schlüssels vornehmen oder den Schlüssel mithilfe eines im TPM gespeicherten Schlüssels und einer PIN verschlüsseln, die Sie beim Systemstart eingeben. Für Systeme, die nicht über ein TPM verfügen, bietet BitLocker die Option, den VMK mithilfe eines Schlüssels zu verschlüsseln, der auf einem externen USB-Flashlaufwerk gespeichert wird. Auf jeden Fall brauchen Sie ein unverschlüsseltes NTFS-Systemvolume von 1,5 GB Größe, bei dem es sich um das Volume handelt, in dem der Startmanager und die Startkonfigurationsdatenbank (Boot Configuration Database, BCD) gespeichert sind.

Der Vorteil bei Verwendung eines TPM besteht darin, dass BitLocker TPM-Funktionen verwendet, um sicherzustellen, dass der VMK nicht entschlüsselt und das Startvolume nicht entsperrt wird, wenn sich das BIOS oder die Systemstartdateien seit der Aktivierung von BitLocker geändert haben. Beim erstmaligen Verschlüsseln des Systemvolumes und jedes Mal, wenn Sie an einer der erwähnten Komponenten Aktualisierungen durchführen, berechnet BitLocker SHA-1-Hashes dieser Komponenten und speichert jeden Hash, der als Messung bezeichnet wird, in verschiedenen Plattformkonfigurationsregistern (PCR) des TPM mithilfe des TPM-Gerätetreibers (%Systemroot%\System32\Drivers\Tpm.sys). Er verwendet dann den TPM zum Versiegeln des VMK, ein Vorgang, bei dem ein privater, im TPM gespeicherter Schlüssel zum Verschlüsseln des VMK und der Werte verwendet wird, die in den PCRs zusammen mit anderen, von BitLocker an das TPM übergebenen Daten gespeichert sind. BitLocker speichert dann den versiegelten VMK und den verschlüsselten FVEK im Metadatenbereich des Volumes.

Wenn das System startet, misst es sein eigenes Hashing und den PCR-Code zum Laden und schreibt den Hash für das erste PCR des TPM. Es erstellt dann Hashwerte für das BIOS und speichert diese Messung im entsprechenden PCR. Das BIOS wiederum erstellt Hashwerte für die nächste Komponente in der Startsequenz, den Master Boot Record (MBR) des Startvolumes. Dieser Prozess wird fortgesetzt, bis der Betriebssystem-Lader gemessen ist. Jedes nachfolgende Codestück, das ausgeführt wird, ist für das Messen des Codes, das es lädt, und für das Speichern der Messungen im entsprechenden Register im TPM verantwortlich. Wenn der Benutzer schließlich entscheidet, welches Betriebssystem gestartet werden soll, liest der Startmanager (Bootmgr) den verschlüsselten VMK aus dem Volume und fordert das TPM auf, ihn zu entsiegeln. Nur wenn alle Messungen identisch mit den Messungen beim Versiegeln des VMK einschließlich der optionalen PIN sind, entschlüsselt das TPM den VMK erfolgreich.

Sie können sich dieses Schema als eine Überprüfungskette vorstellen, in der jede Komponente in der Startsequenz dem TPM die nächste Komponente beschreibt. Nur wenn alle Beschreibungen den ursprünglichen entsprechen, gibt das TPM sein Geheimnis preis. BitLocker schützt daher die verschlüsselten Daten, selbst wenn der Datenträger entfernt und in ein anderes System eingesetzt wird, das System mit einem anderen Betriebssystem gestartet wird oder die unverschlüsselten Dateien im Startvolume offen gelegt werden.

Überprüfen der Codeintegrität

Malware, die als Kernelmodusgerätetreiber implementiert wird, einschließlich Rootkits, wird auf derselben Berechtigungsstufe wie der Kernel ausgeführt, sodass sie besonders schwierig zu identifizieren und zu entfernen ist. Derartige Malware kann das Verhalten des Kernels und anderer Treiber so ändern, dass sie praktisch unsichtbar wird. Die Windows Vista-Codeintegrität für die Kernelmoduscodefunktion, die auch als Kernelmoduscodesignierung (KMCS) bezeichnet wird, lässt nur das Laden veröffentlichter und von Entwicklern digital signierter Gerätetreiber zu, wobei diese Entwickler von einigen wenigen Zertifizierungsstellen gründlich geprüft wurden. KMCS wird standardmäßig auf Windows Vista für 64-Bit-Systeme durchgesetzt.

Da Zertifizierungsstellen eine Gebühr für ihre Dienste erheben und grundlegende, eingehende Überprüfungen wie z. B. die Überprüfung der Identität eines Unternehmens durchführen, ist es schwieriger, anonyme Kernelmodusmalware herzustellen, die auf einem 64-Bit-Windows Vista-System ausgeführt wird. Wenn es Malware gelingt, den Überprüfungsprozess zu überwinden, hinterlässt sie potenziell Anhaltspunkte, die beim Entdecken der Malware auf einem gefährdeten System zum Autor zurückführen. KMCS bietet auch sekundäre Vorteile, beispielsweise die Bereitstellung der Kontaktinformationen für das Windows Online Crash Analysis-Team, wenn bei einem Treiber, der bei Kundensystemen zu Abstürzen führt, der Verdacht auf einen Fehler besteht, und das Entsperren von High Definition-Multimediainhalten, worauf im Folgenden näher eingegangen wird.

KMCS verwendet Kryptografietechnologien für öffentliche Schlüssel, die von Windows seit mehr als zehn Jahren eingesetzt werden, wobei der entsprechende Kernelmoduscode eine digitale Signatur umfassen muss, die von einer der vertrauenswürdigen Zertifizierungsstellen generiert wurde. Wenn ein Herausgeber dem Microsoft Windows Hardware Quality Laboratory (WHQL) einen Treiber sendet und der Treiber die Zuverlässigkeitstests besteht, ist Microsoft die Zertifizierungsstelle, die den Code signiert. Die meisten Herausgeber erhalten Signaturen über das WHQL, doch wenn ein Treiber nicht über ein WHQL-Testprogramm verfügt, der Herausgeber den Treiber nicht an das WHQL zu Testzwecken senden will oder der Treiber ein Systemstarttreiber ist, der jedes Mal beim Starten des Systems geladen wird, müssen die Herausgeber den Code selbst signieren. Dazu müssen sie zunächst ein codesigniertes Zertifikat von einer der Zertifizierungsstellen erhalten, die von Microsoft in Bezug auf die Kernelmoduscodesignierung als vertrauenswürdig identifiziert wurden. Der Autor versieht den Code dann digital mit einem Hashwert, signiert den Hash mit einem privaten Schlüssel und fügt das Zertifikat und den verschlüsselten Hash in den Code ein.

Beim Ladeversuch eines Treibers entschlüsselt Windows den im Code enthaltenen Hash mithilfe des im Zertifikat gespeicherten öffentlichen Schlüssels und überprüft dann, ob der Hash dem im Code enthaltenen entspricht. Die Echtheit des Zertifikats wird auf dieselbe Weise, aber mithilfe des öffentlichen Schlüssels der Zertifizierungsstelle geprüft, der in Windows enthalten ist.

Windows prüft auch, ob das zugeordnete Zertifikat mit einer der im Windows-Ladeprogramm und Betriebssystemkernel eingebetteten Stammzertifizierungsstellen verkettet ist. Versuche, einen nicht signierten 64-Bit-Treiber zu laden, sollten auf einem Produktionssystem nie stattfinden. Im Gegensatz zum Plug & Play-Manager, der einen Warndialog anzeigt, wenn er einen Treiber laden soll, der nicht über eine Signatur mit WQHL-Tests verfügt, schreibt ein 64-Bit-Windows Vista-System daher jedes Mal, wenn das Laden eines unsignierten Treibers gesperrt wird, im Hintergrund ein Ereignis in ein Anwendungsereignisprotokoll für Codeintegrität, ähnlich wie dem in Abbildung 5 dargestellten. 32-Bit-Windows Vista-Systeme prüfen die Treibersignaturen ebenfalls, lassen das Laden unsignierter Treiber jedoch zu. Bei einer Sperrung solcher Treiber würden aktualisierte Windows XP-Systeme beschädigt, bei denen auf Windows XP geladene Treiber erforderlich sind. Gleichzeitig wird der Support für Hardware ermöglicht, für die es nur Windows XP-Treiber gibt. Doch ein 32-Bit-Windows Vista-System schreibt Ereignisse ebenfalls in das Ereignisprotokoll für Codeintegrität, wenn es einen unsignierten Treiber lädt.

Abbildung 5** Ereignisse bei Ladeversuchen unsignierter Treiber **(Klicken Sie zum Vergrößern auf das Bild)

Da die Codesignatur häufig dazu dient, Code als streng getestete offizielle Veröffentlichung auszuweisen, wollen Herausgeber Code in der Regel keinen Signaturtests unterwerfen. Windows Vista verfügt daher über einen Testsignaturmodus, den Sie mit dem Bcdedit-Tool (das in meinem TechNet Magazin-Artikel im März 2007 beschrieben wurde) aktivieren bzw. deaktivieren können, wobei Kernelmodustreiber geladen werden, die digital mit einem Testzertifikat signiert werden, das von einer betriebsinternen Zertifizierungsstelle generiert ist. Dieser Modus ist für Programmierer während der Codeentwicklung gedacht. Wenn sich Windows in diesem Modus befindet, werden auf dem Desktop Markierungen wie jene in Abbildung 6 angezeigt.

Abbildung 6** Windows Vista-Testsignierungsmodus **

Geschützte Prozesse

Multimediainhalte der nächsten Generation wie HD-DVD, BluRay und andere Formate, die unter dem AACS (Advanced Access Content System) lizenziert sind, werden sich in den nächsten Jahren immer mehr durchsetzen. Windows Vista verfügt über eine Reihe von Technologien, die zusammen als Protected Media Path (PMP) bezeichnet werden und die gemäß AACS-Standard zur Wiedergabe solcher Inhalte erforderlich sind. PMP umfasst Protected User-Mode Audio (PUMA) und Protected Video Path (PVP), die zusammen Mechanismen für Audio- und Videotreiber sowie für Anwendungen zur Medienwiedergabe bieten, um zu verhindern, dass nicht genehmigte Software oder Hardware Inhalte im High Definition-Format aufzeichnet.

PUMA und PVP definieren Schnittstellen und Support speziell für Audio- und Videoplayer, Gerätetreiber und Hardware, doch PMP benötigt auch einen allgemeinen Kernelmechanismus, der in Windows Vista eingeführt wurde und als geschützter Prozess bezeichnet wird. Geschützte Prozesse basieren auf dem Standard-Windows-Prozesskonstrukt, das ein ausführbares Abbild während der Ausführung, seine DLLs, den Sicherheitskontext (das Konto, unter dem der Prozess und seine Sicherheitsberechtigungen ausgeführt werden) sowie die Threads kapselt, die Code innerhalb des Prozesses ausführen, aber bestimmte Zugriffsarten verhindern.

Standardprozesse implementieren ein Zugriffssteuerungsmodell, das mit der Berechtigung „Debuggen von Programmen“ vollständigen Zugriff des Besitzers auf den Prozess und die Administratorkonten ermöglicht. Vollständiger Zugriff ermöglicht es einem Benutzer, den Adressraum des Prozesses einschließlich des Codes und der im Prozess abgebildeten Daten anzuzeigen und zu ändern. Benutzer können auch Threads in den Prozess einfügen. Diese Zugriffsarten stimmen nicht mit Anforderungen von PMP überein, da sie es nicht autorisiertem Code ermöglichen würden, Zugriff auf High Definition-Inhalte und DRM-Schlüssel (Digital Rights Management, digitale Rechteverwaltung) zu erhalten, die in einem Prozess gespeichert sind, der den Inhalt wiedergibt.

Geschützte Prozesse schränken den Zugriff auf einen begrenzten Satz von Informations- und Prozessverwaltungsschnittstellen ein, zu denen das Abfragen des Abbildnamens des Prozesses und das Beenden oder Anhalten des Prozesses gehören. Der Kernel stellt jedoch Diagnoseinformationen für geschützte Prozesse über allgemeine Prozessabfragefunktionen zur Verfügung, die Daten in Bezug auf alle Prozesse auf einem System zurückgeben und daher keinen Direktzugriff auf den Prozess brauchen. Zugriffe, die Medien gefährden könnten, werden nur von anderen geschützten Prozessen zugelassen.

Um interne Gefährdungen zu verhindern muss der gesamte ausführbare Code, der in einen geschützten Prozess geladen wird, einschließlich seines ausführbaren Abbilds und seiner DLLs entweder von Microsoft (WHQL) mit einem PE-Kennzeichen (Protected Environment) oder, wenn es sich um einen Audiocodec handelt, vom Entwickler mit einem DRM-signierten Zertifikat von Microsoft signiert werden. Da der Kernelmoduscode vollständigen Zugriff auf alle Prozesse, einschließlich geschützter Prozesse, erhalten kann und ein 32-Bit-Windows-System das Laden von unsigniertem Kernelmoduscode zulässt, stellt der Kernel eine API für geschützte Prozesse bereit, um die „Reinheit“ der Kernelmodusumgebung abzufragen und das Ergebnis nur dann zum Entsperren von hochwertigen Inhalten zu verwenden, wenn kein unsignierter Code geladen wurde.

Identifizieren eines geschützten Prozesses

Es gibt keine speziellen APIs, die geschützte Prozesse identifizieren, doch Sie können solche Prozesse indirekt über die wenigen für sie vorhandenen Informationen und aufgrund der Tatsache identifizieren, dass diese Prozesse selbst von einem Administratorkonto aus nicht debuggt werden können. Der Audio Device Graph Isolation-Prozess (%Systemroot%\System32\Audiodg.exe) dient zur Wiedergabe von CSS (Content Scramble System)-codierten DVDs und ist im Bereich „Task-Manager“ als geschützter Prozess aufgrund der Tatsache erkenntlich, dass der Task-Manager die Status für Befehlszeilen, Virtualisierung und Datenausführungsverhinderung selbst dann nicht beschaffen kann, wenn er mit Administratorrechten ausgeführt wird.

Task-Manager bei der Anzeige des geschützten audiodg-Prozesses(Klicken Sie zum Vergrößern auf das Bild)

Address Space Load Randomization (Zufällige Anordnung beim Laden des Adressbereichs)

Trotz Maßnahmen wie der Datenausführungsverhinderung und verbesserter Überprüfung von Kompilierfehlern finden Autoren von Malware weiterhin Schwachstellen beim Pufferüberlauf, die es ihnen ermöglichen, Prozesse wie Internet Explorer®, Windows-Dienste und Drittanbieteranwendungen zu infizieren, um in einem System Fuß zu fassen. Doch selbst wenn es ihnen gelungen ist, einen Prozess zu infizieren, müssen sie Windows-APIs verwenden, um letztendlich ihr Ziel zu erreichen, d. h., um Benutzerdaten zu lesen oder eine permanente Präsenz durch Ändern von Benutzer- oder Systemkonfigurationseinstellungen herzustellen.

Das Verbinden einer Anwendung mit API-Einstiegspunkten, die von DLLs exportiert wurden, wird gewöhnlich vom Betriebssystem-Lader übernommen, doch diese Arten von Malwareinfektionen können die Vorteile der Laderdienste nicht nutzen. Dies war für Malware bei früheren Versionen von Windows kein Problem, weil bei jeder Windows-Veröffentlichung systemausführbare Abbilder und DLLs immer am gleichen Ort geladen wurden, sodass Malware annehmen konnte, dass sich die APIs an feststehenden Adressen befanden.

Mithilfe der Windows Vista-ASLR-Funktion (Address Space Load Randomization) ist es für Malware unmöglich zu wissen, wo sich die APIs befinden, da System-DLLs und ausführbare Dateien jedes Mal bei einem Systemstart an einem anderen Ort geladen werden. Zu Beginn des Startvorgangs wählt der Speicher-Manager einen zufälligen DLL-Bias zum Laden eines Abbilds unter einer von 256 an 64 KB ausgerichteten Adressen im oberen 16-MB-Bereich des Benutzermodusadressraums aus. Während DLLs, die das neue Kennzeichen für dynamisches Verschieben in ihrem Abbildheader enthalten haben, in den Prozess geladen werden, verpackt der Speicher-Manager sie in einem Speicher, wobei er mit der Biasadresse des Abbildladevorgangs beginnt und sich weiter nach unten vorarbeitet.

Ausführbare Dateien, bei denen das Kennzeichen gesetzt wurde, werden ähnlich behandelt und werden an einem zufälligen, an 64 KB ausgerichteten Punkt innerhalb von 16 MB der Adresse des Basisladevorgangs geladen, die in ihrem Abbildheader gespeichert ist. Wenn eine bestimmte DLL oder ausführbare Datei nach dem Entladen aus allen Prozessen, von denen sie verwendet wird, erneut geladen wird, wählt der Speicher-Manager erneut einen zufälligen Ort aus, an dem sie geladen wird. Abbildung 7 zeigt ein Beispiel für das Layout eines Adressbereichs für ein 32-Bit-Windows Vista-System einschließlich der Bereiche, in denen die ASLR die Bias- und ausführbare Ladeadresse des Abbildladevorgangs auswählt.

Abbildung 7** Die Wirkung von ASLR auf die ausführbare Datei und DLL-Ladeadressen **(Klicken Sie zum Vergrößern auf das Bild)

Nur Abbilder, bei denen das Kennzeichen für dynamische Verschiebung gesetzt wurde (dazu zählen alle Windows Vista-DLLs und ausführbaren Dateien), werden verlagert, da das Verschieben von Legacyabbildern bei internen Annahmen, von denen Entwickler bezüglich des Ladeorts ihrer Abbilder ausgegangen sind, zu Problemen führen könnte. Visual Studio® 2005 SP1 stellt Support zum Setzen des Kennzeichens zur Verfügung, sodass die Entwickler von Drittanbieteranwendungen ASLR umfassend nutzen können.

Die zufällige Anordnung von DLL-Ladeadressen an einem von 256 Orten macht es für Malware nicht unmöglich, den richtigen Ort einer API zu erraten, doch es hemmt die Geschwindigkeit, mit der sich ein Netzwerkwurm fortpflanzen kann, und hindert Malware daran, ihre einzige Chance zum Infizieren eines Systems wahrzunehmen. Zudem hat die Verschiebungsstrategie von ASLR den zusätzlichen Vorteil, dass Adressbereiche dichter gepackt sind als bei früheren Windows-Versionen, sodass größere Bereiche von freiem Speicher für zusammenhängende Speicherzuweisungen geschaffen werden. Dabei wird die Anzahl an Seitentabellen reduziert, die der Speicher-Manager zuweist, um das Layout des Adressbereichs verfolgen zu können und Fehlversuche des Übersetzungsnachschlagepuffers (Translation Lookaside Buffer, TBL) zu minimieren.

Verbesserungen bei der Dienstsicherheit

Windows-Dienste sind ideale Ziele für Malware. Viele bieten Netzwerkzugriff auf ihre Funktionen und legen möglicherweise den Zugriff auf ein System offen, was von einem Remotestandort ausgenutzt werden könnte. Zudem werden die meisten mit einer höheren Berechtigung als Standardbenutzerkonten ausgeführt, was bei einer Gefährdung durch Malware die Chance bietet, höhere Berechtigungen auf einem lokalen System zu gewähren. Aus diesem Grund begann Windows mit der Entwicklung von Änderungen, die bei Windows XP SP2 vorgenommen wurden. Berechtigungen und Zugriffe für Dienste werden nun ausschließlich auf Rollenbasis gewährt. So führte Windows  XP SP2 beispielsweise die Konten „Lokaler Dienst“ und „Netzwerkdienst“ ein, die nur eine Teilmenge der Berechtigungen für das Konto umfassen, auf denen die Dienste bisher ausgeführt wurden – das lokale Systemkonto. Dies minimiert den Zugriff bei Angriffen auf einen Dienst.

ASLR in Aktion

Die Auswirkungen von ASLR werden offensichtlich, wenn Sie die DLL-Ladeadressen für einen Prozess in zwei verschiedenen Startsitzungen mithilfe eines Tools wie Process Explorer von Sysinternals vergleichen. In diesen beiden Screenshots aus zwei verschiedenen Sitzungen wurde Ntdll.dll im Explorer zuerst unter der Adresse 0x77A30000 und dann unter der Adresse 0x77750000 geladen.

Verschiedene Basisadressen für ntdll.dll(Klicken Sie zum Vergrößern auf das Bild)

Verschiedene Basisadressen für ntdll.dll(Klicken Sie zum Vergrößern auf das Bild)

Im vorherigen Artikel wurde beschrieben, wie Dienste isoliert von Benutzerkonten in ihrer eigenen Sitzung ausgeführt werden, doch Windows Vista erweitert die Nutzung des Prinzips der niedrigsten Berechtigungsebene noch, indem Berechtigungen und der Zugriff auf die Dateien, Registrierungsschlüssel und Firewallports, die den meisten Diensten zugewiesen werden, weiter reduziert werden. In Windows Vista ist ein neues Gruppenkonto definiert, das als Dienstsicherheits-ID (Security Identifier, SID) bezeichnet wird und für jeden Dienst eindeutig ist. Der Dienst kann Berechtigungen für seine Ressourcen festlegen, sodass nur seine Dienstsicherheits-ID Zugriff hat und andere Dienste, die unter demselben Benutzerkonto ausgeführt werden, am Datenzugriff gehindert werden, wenn ein Dienst offen gelegt wird. Sie können sich die SID eines Diensts mithilfe des sc showsid-Befehls, gefolgt vom Dienstnamen, anzeigen lassen, wie in Abbildung 8 dargestellt.

Abbildung 8:** Anzeigen einer Dienstsicherheits-ID **(Klicken Sie zum Vergrößern auf das Bild)

Dienstsicherheits-IDs schützen den Zugriff auf Ressourcen, die im Besitz eines bestimmten Diensts sind, doch standardmäßig haben Dienste immer noch Zugriff auf alle Objekte, auf die das Benutzerkonto zugreifen kann, unter dem sie ausgeführt werden. Ein Dienst, der beispielsweise als lokales Dienstkonto ausgeführt wird, kann möglicherweise nicht auf Ressourcen zugreifen, die von einem anderen, als lokaler Dienst in einem anderen Prozess ausgeführten Dienst erstellt wurden, der seine Objekte mit Berechtigungen geschützt hat, die auf eine Dienstsicherheits-ID verweisen. Er kann jedoch immer noch alle Objekte lesen und schreiben, für die der lokale Dienst (und alle Gruppen, denen der lokale Dienst angehört wie z. B. die Dienstgruppe) Berechtigungen hat.

Windows Vista führt daher einen neuen eingeschränkten Diensttyp ein, der als Dienst mit eingeschränktem Schreiben bezeichnet wird und für einen Dienst nur den Schreibzugriff auf Objekte zulässt, die für seine Dienstsicherheits-ID, die Benutzergruppe „Alle“ und die SID zugänglich sind, die der Anmeldesitzung zugewiesen wurden. Dazu werden eingeschränkte SIDs verwendet, bei denen es sich um einen in Windows 2000 eingeführten SID-Typ handelt. Wenn der Prozess, der ein Objekt öffnet, ein Dienst mit eingeschränktem Schreiben ist, ändert sich der Algorithmus zur Zugriffsüberprüfung, sodass eine SID, die einem Prozess weder in eingeschränkter noch uneingeschränkter Form zugewiesen wurde, nicht verwendet werden kann, um dem Prozess Schreibzugriff für ein Objekt zu gewähren. Mit dem folgenden Befehl können Sie feststellen, ob ein Dienst eingeschränkt ist:

sc qsidtype [service]

Eine weitere Änderung erleichtert es einem Dienst, andere Dienste, die unter demselben Konto ausgeführt werden, daran zu hindern, auf erstellte Objekte zuzugreifen. In früheren Windows-Versionen war der Ersteller eines Objekts auch sein Besitzer, und Besitzer können die Berechtigungen ihrer Objekte lesen und ändern, sodass sie vollständigen Zugriff auf ihre eigenen Objekte haben. Windows Vista führt die neue Sicherheits-ID für Eigentümerrechte ein, die bei Vorhandensein in den Berechtigungen eines Objekts den Zugriff eines Besitzers auf sein eigenes Objekt einschränken kann – sogar das Recht, die Berechtigungen festzulegen und abzufragen.

Eine weitere Verbesserung des Dienstsicherheitsmodells in Windows Vista ermöglicht einem Dienstentwickler die genaue Angabe der Sicherheitsberechtigungen für die Ausführung eines Diensts, wenn der Dienst sich im System anmeldet. Wenn der Dienst beispielsweise Überwachungsereignisse generieren muss, könnte der Entwickler eine Überwachungsberechtigung aufführen.

Wenn der Dienststeuerungs-Manager einen Prozess startet, der einen oder mehrere Windows-Dienste hostet, erstellt er ein Sicherheitstoken (das Kernelobjekt, das ein Prozessbenutzerkonto, Gruppenmitgliedschaften und Sicherheitsberechtigungen aufführt) für den Prozess, das nur die Berechtigungen enthält, die für die Dienste im Prozess erforderlich sind. Wenn ein Dienst eine Berechtigung angibt, die für das Konto, unter dem er ausgeführt wird, nicht verfügbar ist, wird der Dienst nicht gestartet. Wenn beispielsweise keiner der Dienste, die in einem lokalen Dienstkontoprozess ausgeführt werden, die Berechtigung „Debuggen von Programmen“ benötigt, entfernt der Dienststeuerungs-Manager diese Berechtigung aus dem Sicherheitstoken des Prozesses. Wenn der Dienstprozess offen gelegt wird, kann bösartiger Code folglich keine Berechtigungen nutzen, die nicht ausdrücklich für die in diesem Prozess ausgeführten Dienste angefordert wurden. Der sc qprivs-Befehl meldet die Berechtigungen, die von einem Dienst angefordert wurden.

Schlussbemerkung

Damit ist mein dreiteiliger Einblick in die Änderungen beim Windows Vista-Kernel beendet. Es gibt Features und Verbesserungen, die ich nicht angesprochen habe, beispielsweise den neuen Arbeitsthreadpool für Anwendungsentwickler, neue Synchronisierungsmechanismen wie z. B. freigegebene Lese-/Schreibsperren, Dienstthreadtagging, Unterstützung für Online-NTFS-Datenträgerüberprüfung und Volumegrößenänderung sowie einen neuen Kernel-IPC-Mechanismus namens ALPC (Advanced Local Procedure Call). Weitere Informationen zu diesen und anderen Features finden Sie in der nächsten Ausgabe von Windows Internals, deren Veröffentlichung Ende 2007 geplant ist.

Anzeigen eines Diensts mit eingeschränktem Schreiben

Nur ein Diensthostingprozess in Windows Vista hostet eingeschränkte Dienste. Sie können ihn mit einem Tool zum Anzeigen von Prozessen wie dem Process Explorer als den Prozess mit der folgenden Befehlszeile identifizieren:

svchost -k LocalServiceNoNetwork

Zu den Diensten, die zur Ausführung in diesem Prozess konfiguriert sind, gehören: Basisfiltermodul, Diagnoserichtliniendienst, Windows-Firewall, Leistungsprotokolle und -Warnungen und das Startdienstprogramm für Windows Media® Center.

Dieser Bildschirm zeigt das Textformat der Dienstsicherheits-ID des Basisfiltermoduls, NT SERVICE\BFE, die einmal mit dem eingeschränkten Kennzeichen und einmal ohne aufgeführt ist, sodass der Prozess auf Ressourcen zugreifen kann, die für dieses Konto zugänglich sind. Der Prozess hat jedoch nicht unbedingt Zugriff auf andere Objekte, die normalerweise für das lokale Dienstkonto zugänglich sind. Da beispielsweise das NT AUTHORITY\SERVICE-Konto nicht im Prozesstoken mit dem eingeschränkten Kennzeichen enthalten ist, kann der Prozess keine Objekte ändern, die nur diesem Konto, aber keinen anderen Konten in dem Token, bei denen das eingeschränkte Kennzeichen gesetzt ist, Schreibzugriff gewähren.

Für die in diesem Prozess ausgeführten Dienste werden die Berechtigungen ebenfalls eingeschränkt, weil die am unteren Ende des Eigenschaftendialogs aufgeführten Berechtigungen lediglich eine Teilmenge der Berechtigungen sind, die dem lokalen Dienstkonto zur Verfügung stehen.

SID-Kennzeichen in einem Dienst(Klicken Sie zum Vergrößern auf das Bild)

Mark Russinovich ist Technical Fellow in der Platform and Services Division von Microsoft. Er ist Mitautor von Microsoft Windows Internals (Microsoft Press, 2004) und hält häufig Vorträge auf IT- und Entwicklerkonferenzen, einschließlich Microsoft Tech•Ed und PDC. Er wechselte bei der Übernahme des von ihm mitgegründeten Unternehmens Winternals Software zu Microsoft. Darüber hinaus gründete er Sysinternals, wo er viele populäre Dienstprogramme einschließlich Process Explorer, Filemon und Regmon veröffentlichte.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.