Entwurf des Windows-Integritätsmechanismus

  • Artikel

Der Windows-Integritätsmechanismus ist eine Erweiterung der Windows-Sicherheitsarchitektur, die auf dem Sicherheitsreferenzmonitor im Kernel basiert. Der Sicherheitsreferenzmonitor erzwingt die Zugriffssteuerung, indem Benutzer- und Gruppen-SIDs im Sicherheitszugriffstoken mit erteilten Zugriffsberechtigungen in der ACL der Sicherheitsbeschreibung eines Objekts verglichen werden. Der Integritätsmechanismus fügt dem Sicherheitszugriffstoken eine Integritätsebene und einen obligatorischen Bezeichnungszugriffssteuerungseintrag für die System-ACL (SACL) im Sicherheitsdeskriptor hinzu.

Die wichtigsten Teile des Integritätsmechanismus sind:

  • Vordefinierte Integritätsebenen und deren Darstellung.
  • Integritätsrichtlinien, die Zugriffsberechtigungen einschränken.
  • Integritätsebene, die dem Sicherheitszugriffstoken zugewiesen ist.
  • Obligatorischer Bezeichnungszugriffssteuerungseintrag.
  • Obligatorische Bezeichnungen, die Objekten zugewiesen sind.
  • Integritätseinschränkungen innerhalb der AccessCheck- und Kernelmodus-SeAccessCheck-APIs.

Jeder dieser Teile wird unten ausführlicher beschrieben. Der Windows-Integritätsmechanismus ist unabhängig von anderen Sicherheitsrichtlinienoptionen immer in Kraft. Die Überprüfungen der Integritätsebene sind wie die Zugriffssteuerungsprüfungen nicht optional. Es gibt keine Sicherheitsrichtlinienoptionen, um Integritätsstufenprüfungen zu deaktivieren. Obwohl der Integritätsmechanismus UAC unterstützt, bleibt der Integritätsmechanismus wirksam, wenn die UAC durch sicherheitsrelevante Gruppenrichtlinie deaktiviert wird.

Integritätsstufen

Windows definiert Integritätsebenen mithilfe einer SID. Die Verwendung einer SID zur Darstellung einer Integritätsstufe macht es sehr einfach, den Integritätsmechanismus in vorhandene Sicherheitsdatenstrukturen zu integrieren, ohne Dass Codeänderungen erforderlich sind. SIDs der Integritätsebene haben die folgende Form: S-1-16-xxxx. Tabelle 1 zeigt die Komponenten von SIDs auf Integritätsebene.

Tabelle 1 Sid-Bezeichner-Autoritätswerte

Wert BESCHREIBUNG

16

Stellt die obligatorische Bezeichnungsautorität (SECURITY_MANDATORY_LABEL_AUTHORITY) dar.

xxxx

Stellt das RID-Feld (Relative Identifier) dar, das die Integritätsebene darstellt. Rid ist ein Hexadezimalwert, der die Integritätsebene darstellt.

Es gibt vier primäre Integritätsebenen in Windows Vista mit vier entsprechenden Werten. Ein niedrigerer Wert gibt einen niedrigeren Integritätsgrad oder einen niedrigeren Grad an Vertrauenswürdigkeit an. Diese Werte werden in der Headerdatei winnt.h definiert. Tabelle 2 zeigt die definierten Integritätsstufen und die entsprechenden Werte.

Tabelle 2 Definierte Integritätsstufen und entsprechende Werte

Wert BESCHREIBUNG Symbol

0x0000

Nicht vertrauenswürdige Ebene

SECURITY_MANDATORY_UNTRUSTED_RID

0x1000

Niedrige Integritätsebene

SECURITY_MANDATORY_LOW_RID

0x2000

Mittlere Integritätsebene

SECURITY_MANDATORY_MEDIUM_RID

0x3000

Hohe Integritätsebene

SECURITY_MANDATORY_HIGH_RID

0x4000

Systemintegritätsebene

SECURITY_MANDATORY_SYSTEM_RID

Ein Beispiel für eine SID mit mittlerer Integritätsebene ist die folgende Zeichenfolge: S-1-16-8192. Der RID-Wert von 8192 ist das Dezimaläquivalent von 0x2000.

Die RIDs sind durch Intervalle von 0x1000 getrennt, um die Definition zusätzlicher Ebenen in der Zukunft zu ermöglichen. Die Trennung ermöglicht auch das Zuweisen einer Integritätsebene zu einem Prozess, der etwas höher als mittel ist: beispielsweise, um bestimmte Systementwurfsziele zu erreichen.

Den definierten SIDs auf Integritätsebene sind Zeichenfolgennamenswerte zugeordnet. Mithilfe der API LookupAccountSID werden Zeichenfolgennamen für jede SID der Integritätsebene zurückgegeben. Tabelle 3 zeigt die Zeichenfolgennamen für die Integritätsstufen.

Zeichenfolgennamen auf Integritätsebene in Tabelle 3

Integritätsgrad-SID Name

S-1-16-4096

Obligatorische Bezeichnung\Niedrige Obligatorische Ebene

S-1-16-8192

Obligatorische Bezeichnung\Mittel Obligatorische Ebene

S-1-16-12288

Obligatorische Bezeichnung\Hohe Obligatorische Ebene

S-1-16-16384

Obligatorische Bezeichnung\System obligatorische Ebene

Die Integritätsstufen werden auch als SID-Zeichenfolgen in der Security Descriptor Definition Language (SDDL) definiert. Die SDDL definiert das Zeichenfolgenformat, das die Funktionen ConvertSecurityDescriptorToStringSecurityDescriptor und ConvertStringSecurityDescriptorToSecurityDescriptor verwenden, um einen Sicherheitsdeskriptor als Textzeichenfolge zu beschreiben. Die Sprache definiert auch Zeichenfolgenelemente zum Beschreiben von Informationen in den Komponenten eines Sicherheitsdeskriptors. Die Verwendung der SDDL zum Definieren der Integritätsstufen macht es praktisch, die Integritätsebene eines Objekts zu definieren, wenn das Objekt erstellt wird. Weitere Informationen zu SID-Zeichenfolgen für Integritätsstufen finden Sie unter Ressourcen des Windows-Integritätsmechanismus. Die SDDL-Unterstützung für obligatorische Bezeichnungen wird in Anhang A: SDDL für obligatorische Bezeichnungen beschrieben.

Windows Vista verwendet SIDs der Integritätsebene im Sicherheitszugriffstoken, um die Integritätsebene des Antragstellers darzustellen, und verwendet SIDs der Integritätsebene in der obligatorischen Bezeichnung ACE in einem Sicherheitsdeskriptor, um die Objektintegritätsebene darzustellen.

Integritätsrichtlinien

Der Windows-Integritätsmechanismus verwendet einfache Richtlinien, um zu bestimmen, wie die obligatorischen Bezeichnungen für Objekte verwendet werden sollen, um die Zugriffsebene einzuschränken, die für Personen mit geringerer Integrität verfügbar ist. Dies bedeutet, dass die Richtlinien den Zugriff beschränken, den Objekte auf niedrigerer Integritätsebene auf Objekte mit höherer Integritätsebene haben dürfen. Tabelle 4 zeigt die beiden Richtlinienkategorien.

Tabelle 4 Integritätsrichtlinienkategorien

Category BESCHREIBUNG

Obligatorische Richtlinien für Zugriffstoken

Legen Sie im Zugriffstoken fest, wie obligatorische Richtlinien für den Antragsteller gelten, der im Zugriffstoken dargestellt wird.

Obligatorische Bezeichnungsrichtlinien

Legen Sie die obligatorische Bezeichnung ACE (unten beschrieben) für Objekte fest, und legen Sie fest, wie der Zugriff auf das Objekt eingeschränkt werden soll.

Die Integritätsrichtlinien werden verwendet, wenn die obligatorische Richtlinienüberprüfung beim Auswerten von Zugriffsberechtigungen für ein sicherungsfähiges Objekt durchgeführt wird. Die Richtlinien bestimmen, wie Zugriffsrechte auf Integritätsebenen eingeschränkt werden.

Obligatorische Zugriffstokenrichtlinien

Tabelle 5 zeigt die obligatorischen Zugriffstokenrichtlinien, die in Windows Vista definiert sind.

Tabelle 5 Obligatorische Zugriffstokenrichtlinien in Windows Vista

Richtlinie BESCHREIBUNG

TOKEN_MANDATORY_NO_WRITE_UP

Die Standardrichtlinie, die allen Zugriffstoken zugewiesen ist. Die Richtlinie schränkt den Schreibzugriff dieser Person auf jedes Objekt auf einer höheren Integritätsebene ein.

TOKEN_MANDATORY_NEW_PROCESS_MIN

Steuert das Verhalten beim Zuweisen der Integritätsebene zu untergeordneten Prozessen. Normalerweise erbt ein untergeordneter Prozess die Integritätsebene des übergeordneten Prozesses, wenn dem untergeordneten Prozess das Zugriffstoken für den übergeordneten Prozess zugewiesen wird. Mit der NEW_PROCESS_MIN-Richtlinie ist die Integritätsebene des untergeordneten Prozesses die Mindestintegritätsebene des übergeordneten Zugriffstokens oder die Objektintegritätsebene der ausführbaren Datei für den neuen Prozess. Diese Richtlinie ist standardmäßig in allen Zugriffstoken festgelegt.

Die NEW_PROCESS_MIN-Richtlinie kann anhand eines Beispiels beschrieben werden. Angenommen, es gibt ein ausführbares Programm namens lowcalc.exe. Der Programmdatei wird eine Bezeichnung mit niedriger Integrität zugewiesen. Über eine Eingabeaufforderung führt der Benutzer lowcalc.exe aus. Der übergeordnete Prozess, cmd.exe, wird auf einer mittleren Integritätsebene ausgeführt. Da die Imagedatei lowcalc.exe eine Bezeichnung mit niedriger Integrität aufweist, legt die NEW_PROCESS_MIN-Richtlinie die Integritätsebene des neuen Prozesses lowcalc auf low fest. Dies wird im folgenden Beispiel im Abschnitt Entwerfen von Anwendungen zur Ausführung mit niedriger Integritätsstufe veranschaulicht.

Obligatorische Bezeichnungsrichtlinien

Die obligatorischen Bezeichnungsrichtlinien werden als Flags (Bits) im Feld Mask des obligatorischen Zugriffssteuerungseintrags für Bezeichnungen definiert. Diese Richtlinienflags bestimmen die Einschränkungen für Zugriffsberechtigungen, die für Themen mit niedrigerer Integrität gelten. Tabelle 6 zeigt die obligatorischen Bezeichnungsrichtlinien, die in Windows Vista definiert sind.

Tabelle 6 Obligatorische Bezeichnungsrichtlinien in Windows Vista

Richtlinie BESCHREIBUNG

SYSTEM_MANDATORY_POLICY_NO_WRITE_UP

Die Standardrichtlinie für alle obligatorischen Objektbezeichnungen. Das Flag entspricht der NO_WRITE_UP Zugriffstokenrichtlinie. Die Richtlinie schränkt den Schreibzugriff auf das Objekt durch einen Antragsteller mit einer niedrigeren Integritätsebene ein.

SYSTEM_MANDATORY_POLICY_NO_READ_UP

Schränkt den Lesezugriff auf das Objekt durch einen Antragsteller mit einer niedrigeren Integritätsebene ein. Die Richtlinie wird beispielsweise verwendet, um den Lesezugriff auf den Adressraum des virtuellen Speichers eines Prozesses einzuschränken.

SYSTEM_MANDATORY_POLICY_NO_EXECUTE_UP

Schränkt den Ausführungszugriff auf das Objekt durch einen Antragsteller mit einer niedrigeren Integritätsebene ein. Die Richtlinie wird beispielsweise verwendet, um Startaktivierungsberechtigungen für eine COM-Klasse durch Personen mit niedrigerer Integrität einzuschränken.

Diese definierten Richtlinien erfüllen die Designziele für Windows Vista. Die Architektur des Integritätsmechanismus ermöglicht eine zukünftige Erweiterung, indem zusätzliche Richtlinienoptionen definiert werden, die Zugriffsberechtigungen zwischen Subjekten und Objekten auf verschiedenen Integritätsebenen steuern.

Zuordnung von Integritätsrichtlinien zu generischen Rechten

Die obligatorische Richtlinienüberprüfung erfolgt im Rahmen der AccessCheck-Sicherheitsfunktion. AccessCheck (und SeAccessCheck im Kernelmodus) verfügt als einer der Funktionsparameter über eine GENERIC_MAPPING-Struktur. Die vom Aufrufer bereitgestellte generische Zuordnung ordnet objektspezifische Zugriffsrechte den generischen Kategorien Lesen, Schreiben und Ausführen zu. Die obligatorischen Bezeichnungsrichtlinien implementieren Einschränkungen für den zulässigen Zugriff basierend auf den generischen Kategorien. Bei einem bestimmten Objekttyp kommuniziert der GENERIC_MAPPING mit der obligatorischen Richtlinie, welche spezifischen Zugriffsrechte verboten sind.

Wenn die GENERIC_MAPPING Struktur, die an einen Aufruf von AccessCheck übergeben wird, alle Nullen (0) aufweist, ist die generische Zuordnung nicht definiert. Wenn die generische Zuordnung nicht definiert ist, schränkt die obligatorische Richtlinienüberprüfung alle Zugriffsrechte durch Subjekte mit niedrigerer Integrität ein. Ressourcenmanagern, die AccessCheck für die Sicherheit privater Objekte verwenden und eine GENERIC_MAPPING Struktur aller Nullen übergeben, werden Access Denied-Fehler angezeigt. Eine Codeänderung an der Resource Manager-Anwendung ist erforderlich, um objekttypspezifische Zugriffsrechte den generischen Zugriffsrechten zuzuordnen, die die obligatorische Richtlinie erzwingt.

Zuweisen von Integritätsebenen zu Zugriffstoken

Das Sicherheitszugriffstoken ist eine interne Datenstruktur, die vom Kernel verwendet wird. Das Sicherheitszugriffstoken enthält unterschiedliche Informationswerte, die Berechtigungen, Gruppenmitgliedschaften und anderen sicherheitsbezogenen Details entsprechen. Die Zugriffstokeninitialisierung erfolgt, wenn sich ein Benutzer interaktiv bei Windows anmeldet oder wenn eine Netzwerkauthentifizierung erfolgt. Wenn das Zugriffstoken initialisiert wird, werden die SID, Gruppen-SIDs und Berechtigungen des Benutzers zusätzlich zu anderen Werten hinzugefügt. Windows Vista weist die Integritätsebene für das Zugriffstoken zu, wenn das Zugriffstoken initialisiert wird.

Der Kernel weist jedem Prozess und Thread ein Zugriffstoken zu. Das primäre Zugriffstoken des Prozesses enthält die diesem Prozess zugeordnete Integritätsebene. Im Windows-Integritätsmechanismus wird die Integritätsebene des Prozesses als Antragstellerintegritätsebene bezeichnet. Wenn das Zugriffstoken einer Anwendung die SID mit mittlerer Integrität enthält, wird der Anwendungsprozess auf einer mittleren Integritätsebene ausgeführt. Mehreren Anwendungsprozessen, die unter demselben Benutzerkonto ausgeführt werden, wird das gleiche primäre Zugriffstoken zugewiesen. Auf diese Weise wird jeder Anwendung die gleiche Integritätsstufe zugewiesen.

Integritätsebenen werden Zugriffstoken basierend auf bestimmten Gruppen-SIDs zugewiesen, die in der TOKEN_GROUPS-Struktur vorhanden sind. Der Windows-Kernel weist eine Integritätsebene basierend auf bestimmten integrierten Benutzer- oder Gruppenkonten zu. Windows Vista weist ein Zugriffstoken zu, bei dem die LOKALE Systemkonto-SID die Integritätsebene des Systems darstellt, einem Zugriffstoken mit der lokalen Administratorgruppen-SID wird die Integritätsebene hoch zugewiesen, und einem Zugriffstoken für ein Standardbenutzerkonto wird die Integritätsebene mittel zugewiesen.

Tabelle 7 zeigt die Zuweisungen der Integritätsebene zum Zugriffstoken, basierend auf dem Vorhandensein bestimmter SIDs.

Tabelle 7 Integritätsebenen, die mit bestimmten SIDs verknüpft sind

SID im Zugriffstoken Zugewiesene Integritätsebene

LocalSystem

System

LocalService

System

NetworkService

System

Administrators

High

Sicherungsoperatoren

High

Netzwerkkonfigurations-Operatoren

High

Kryptografie-Operatoren

High

Authentifizierte Benutzer

Medium

Jeder (Welt)

Niedrig

Anonym

Nicht vertrauenswürdig

Integritätsebenen definieren unterschiedliche Stufen der Vertrauenswürdigkeit für Anwendungen, die auf verschiedenen Zugriffsebenen ausgeführt werden. Die meisten Anwendungen in Windows Vista werden auf einer Standardbenutzerzugriffsebene auf mittlerer Integritätsebene ausgeführt. Bei Anwendungen auf mittlerer Integritätsebene gibt es keine Einschränkungen hinsichtlich der Interaktion mit anderen Anwendungen und Daten auf mittlerer Integritätsebene. Bestimmte Aufgaben oder Anwendungen, die Administratorrechte erfordern, werden auf einer hohen Integritätsebene ausgeführt. Systemdienste werden auf der Systemintegritätsebene ausgeführt, da es Einschränkungen für die Interaktion mit dem Standarddesktop gibt und sie häufig mit leistungsstarken Systemberechtigungen ausgeführt werden. Einige Anwendungen, die für die Ausführung mit den wenigsten möglichen Rechten konzipiert wurden, z. B. internetgeschützter Modus Explorer, können mit einem niedrigen Integritätsgrad ausgeführt werden.

Bestimmte Windows-Administratorrechte können einem Zugriffstoken nur mit mindestens einer hohen Integritätsstufe zugewiesen werden. Wenn die Integritätsebene des Zugriffstokens kleiner als hoch ist, sind bestimmte Administratorrechte nicht zulässig und werden aus dem Zugriffstoken entfernt. Einer hohen Integritätsstufe zugeordnete Administratorrechte sind:

  • SE_CREATE_TOKEN_PRIVILEGE
  • SE_TCB_PRIVILEGE
  • SE_TAKE_OWNERSHIP_PRIVILEGE
  • SE_BACKUP_PRIVILEGE
  • SE_RESTORE_PRIVILEGE
  • SE_DEBUG_PRIVILEGE
  • SE_IMPERSONATE_PRIVILEGE
  • SE_RELABEL_PRIVILEGE
  • SE_LOAD_DRIVER_PRIVILEGE

Anwendungen können einem doppelten Zugriffstoken beim Erstellen eines untergeordneten Prozesses eine niedrige Integritätsebene zuweisen. Windows führt möglicherweise einen Anwendungsprozess mit einem niedrigen Integritätsgrad aus, wenn die ausführbare Programmimagedatei eine niedrige obligatorische Bezeichnung aufweist. Diese Features werden weiter unten in diesem Artikel beschrieben.

Abrufen der Integritätsstufe für ein Zugriffstoken

Die Integritätsebene wird im Zugriffstoken mithilfe des Felds TOKEN_GROUPS gespeichert. Die TOKEN_GROUPS-Struktur ist eine Liste von SIDs und Attributen, die die Gruppenmitgliedschaften für dieses Benutzerkonto identifizieren. Die Zugriffstokenintegritätsebene wird auch in der Gruppenliste mithilfe eines SID-Attributs identifiziert. Die SID_AND_ATTRIBUTES-Struktur enthält die Integritätsgrad-SID, und die Integritätsebene wird mithilfe der Attribute SE_GROUP_INTEGRITY und SE_GROUP_INTEGRITY_ENABLED identifiziert.

Sie können die Zugriffstokenintegritätsebene aus dem Zugriffstoken abrufen, indem Sie die GetTokenInformation-API verwenden. GetTokenInformation verfügt über einen Parameter, der angibt, welche Zugriffstokeninformationsklasse abgerufen werden soll. Der parameter TOKEN_INFORMATION_CLASS verfügt über einen definierten Wert für die Integritätsebene TokenIntegrityLevel. Die zurückgegebene Datenstruktur ist ein TOKEN_MANDATORY_LABEL Typ.

So bestimmen Sie die Integritätsebene eines Prozesses

  1. Öffnen Sie ein Handle für das Zugriffstoken des Prozesses.

  2. Rufen Sie die Integritätsebene des Zugriffstokens ab.

  3. Vergleichen Sie die Integritätsebenen-SID mit den systemdefinierten INTEGRITÄTsebenen-RIDs.

Beispielcode zum Abrufen der Zugriffstokenintegritätsebene finden Sie in Anhang D.

Anzeigen der Integritätsebene für ein Zugriffstoken

Die Integritätsebene im Sicherheitszugriffstoken eines Prozesses kann mithilfe von Tools angezeigt werden, die die Sicherheitsdetails eines Prozesses verfügbar machen, z. B. prozessinterne Explorer aus SysInternals.com. Die folgenden Abbildungen zeigen die Anzeige von Process Explorer mit der Spalte Integritätsstufe, die der Ansicht (rechts) hinzugefügt wurde.

Abbildung 1 Integritätsebene in Prozess Explorer

Wenn wir uns die Sicherheitseigenschaften eines bestimmten Prozesses ansehen, z. B. explorer.exe, zeigt Process Explorer die Integritätsebene in der Liste der Gruppen an, die im Sicherheitszugriffstoken des Prozesses definiert sind. Die folgende Abbildung zeigt die obligatorische Bezeichnung/mittlere obligatorische Ebene, die dem Zugriffstoken für den Prozess zugewiesen ist, explorer.exe.

Abbildung 2 Explorer.exe als Prozess mit mittlerer Integritätsebene

Festlegen der Integritätsebene für ein Zugriffstoken

Anwendungen müssen in der Regel den Wert der Integritätsebene des Prozesses nicht ändern. Anwendungen müssen in der Regel keine Änderungen an den Werten im Sicherheitszugriffstoken vornehmen. Unter bestimmten Umständen können dienste, die lokale Clients mit unterschiedlichen Integritätsstufen unterstützen, Aufgaben mit einer niedrigeren Integritätsebene ausführen. Der Identitätswechsel ist eine Möglichkeit, wie ein Dienstthread auf einer niedrigeren Integritätsebene ausgeführt wird. Wenn ein Dienstthread die Identität eines lokalen Clients angibt, verfügt der Identitätswechselthread über den Sicherheitskontext des Clients, der die Integritätsebene des Clients enthält, wenn der Client auf demselben lokalen Computer ausgeführt wird.

Eine weitere Möglichkeit, wie eine Anwendung einen Vorgang ausführen kann, z. B. das Erstellen einer Gruppe von Dateien und Registrierungsschlüsseln, auf einer niedrigeren Integritätsebene besteht darin, den TokenIntegrityLevel für das aktuelle Threadzugriffstoken festzulegen. Die neue Integritätsebene darf nicht höher als die Integritätsebene im primären Zugriffstoken des Prozesses sein.

So legen Sie den Wert einer Zugriffstokenintegritätsebene für einen Thread fest

  1. Rufen Sie OpenThreadToken auf, um ein Handle für das Zugriffstoken abzurufen.

  2. Rufen Sie GetTokenInformation mit dem TOKEN_INFORMATION_CLASS Parameterwert von TokenIntegrityLevel auf, um die aktuelle Threadintegritätsebene zu speichern.

  3. Rufen Sie SetTokenInformation mit dem TOKEN_INFORMATION_CLASS Parameterwert von TokenIntegrityLevel auf.

Da es innerhalb eines Prozessadressraums zwischen Threads auf unterschiedlichen Integritätsebenen keine Sicherheitsgrenze gibt, müssen Anwendungsentwickler die potenziellen Sicherheitsrisiken berücksichtigen, wenn Code in einem Thread mit niedrigerer Integrität in einem Prozess mit höherer Integrität ausgeführt wird. Für die meisten Anwendungen ist es möglicherweise einfacher, einen separaten Prozess zu erstellen, der auf der niedrigeren Integritätsebene ausgeführt wird, um Aufgaben mit niedrigerer Integrität auszuführen.

Ein Beispiel für das Festlegen von TokenIntegrityLevel und das Erstellen eines Prozesses mit einer niedrigeren Integritätsebene finden Sie unter Festlegen der Integritätsebene für ein Zugriffstoken.

Obligatorische Bezeichnung ACE

Der Windows-Integritätsmechanismus definiert einen neuen ACE-Typ, die system obligatorische Bezeichnung ACE. Die obligatorische Bezeichnung ACE wird verwendet, um die obligatorische Bezeichnung eines Objekts im Sicherheitsdeskriptor des Objekts darzustellen. Die obligatorische Bezeichnung enthält die Integritätsebene und die zugeordnete Integritätsrichtlinie. Eine obligatorische Bezeichnung ACE wird nur in der System-ACL (SACL) des Sicherheitsdeskriptors verwendet. Die SACL ist ein separates Feld im Sicherheitsdeskriptor von der discretionary ACL (DACL).

Abbildung 3 Sicherheitsdeskriptorfelder

Die ACL nach Ermessen enthält Benutzer- und Gruppenzugriffsberechtigungen für das Objekt. Jeder Benutzer oder jede Gruppe kann Aktualisierungen an der DACL mit WRITE_DAC Objektzugriffsberechtigungen vornehmen. Ermessens-ACLs können häufiger und von verschiedenen Benutzern aktualisiert werden. Eines der Entwurfsziele des Integritätsmechanismus besteht darin, dass das Sicherheitssystem die Bezeichnung mit einem Objekt beibehalten sollte, nachdem eine obligatorische Bezeichnung auf das Objekt angewendet wurde. Das Erzwingen der entsprechenden obligatorischen Bezeichnung im Objektsicherheitsdeskriptor mit geringen oder keinen Auswirkungen auf Anwendungen, die für die Verwaltung von ACLs konzipiert sind, erfolgt durch Einfügen der obligatorischen Bezeichnung in die System-ACL, wo sie in erster Linie der Kontrolle des Sicherheitssystems unterliegt. Die obligatorische Bezeichnung ist logisch getrennt von den Systemüberwachungseinträgen in der SACL. Es ist nicht erforderlich, dass die obligatorische Bezeichnung den Systemüberwachungseinträgen in der SACL vorangestellt oder folgt.

Die obligatorische Bezeichnung ACE ähnelt einem Zugriffsberechtigungs-ACE, da sie einen ACE-Header, eine Zugriffsmaske und eine SID enthält. Der SID-Teil der obligatorischen Bezeichnung ACE enthält die Integritätsgrad-SID. Tabelle 8 zeigt die Felder im ACE-Header.

Tabelle 8 Im ACE-Header enthaltene Felder

ACE-Headerfeld Wert

AceType

SYSTEM_MANDATORY_LABEL_ACE_TYPE

AceFlags

Steuerelementflags, die die Vererbung des obligatorischen Bezeichnungs-ACE-Typs definieren

AceSize

Größe der obligatorischen Bezeichnung ACE

Die obligatorische Bezeichnung ACE enthält ein Maske-Feld . Die Maske wird verwendet, um die obligatorischen Richtlinien zu definieren, die Einschränkungen für die Zugriffsberechtigungen festlegen, die für Prozesse (oder Subjekte) mit einer niedrigeren Integritätsstufe gelten. Eine Beispielrichtlinie, die in Windows Vista häufig verwendet wird, ist die richtlinie NO_WRITE_UP. Das NO_WRITE_UP Richtlinienflag in der ACE-Maske der obligatorischen Bezeichnung bedeutet, dass Personen mit einer niedrigeren Integritätsstufe (im Zugriffstoken) als die Integritätsgrad-SID in der obligatorischen Bezeichnung des Objekts nicht generischen Schreibzugriff auf das Objekt erhalten können.

Es gibt nur eine effektive obligatorische Bezeichnung für ein Objekt. Wenn ein Sicherheitsdeskriptor mehr als eine obligatorische Bezeichnung in der SACL erhält, ist die erste obligatorische Bezeichnung ACE in der SACL die effektive Bezeichnung für das Objekt.

Weitere Informationen zur obligatorischen Bezeichnung ACE finden Sie unter Ressourcen des Windows-Integritätsmechanismus.

Lesen der obligatorischen Bezeichnung ACE

Windows Vista verwendet die Sicherheitsfunktion GetSecurityInfo, um die obligatorischen Bezeichnungsinformationen aus einem Objekt zu lesen. GetSecurityInfo ruft die Besitzer-, Gruppen-, DACL- oder SACL-Informationen aus einem -Objekt ab. Der SECURITY_INFORMATION Parameter für GetSecurityInfo bestimmt, welcher Teil des Sicherheitsdeskriptors zurückgegeben wird. Windows Vista definiert einen neuen Wert für Sicherheitsinformationen, LABEL_SECURITY_INFORMATION, der verwendet wird, um die obligatorische Bezeichnung ACE aus der SACL zurückzugeben. Wenn der Aufruf von GetSecurityInfo SACL_SECURITY_INFORMATION angibt, werden nur die Systemüberwachungs-ACEs in der SACL zurückgegeben, nicht die obligatorische Bezeichnung ACE.

Die Zugriffsberechtigung, die zum Lesen der obligatorischen Bezeichnung ACE für ein Objekt erforderlich ist, ist das READ_CONTROL Standardzugriffsrecht. Normalerweise ist das ACCESS_SYSTEM_SECURITY Zugriffsrecht erforderlich, um Informationen in der SACL abzurufen oder festzulegen. ACCESS_SYSTEM_SECURITY wird nur gewährt, wenn die berechtigung SE_SECURITY_NAME im Zugriffstoken aktiviert ist. Das Lesen der obligatorischen Bezeichnung aus der SACL erfordert keine SE_SECURITY_NAME-Berechtigung oder das ACCESS_SYSTEM_SECURITY-Zugriffsrecht.

Festlegen der obligatorischen Bezeichnung ACE

Windows Vista verwendet die Sicherheitsfunktion SetSecurityInfo, um die obligatorischen Bezeichnungsinformationen für ein Objekt zu ändern. Die obligatorische Bezeichnung des Objekts wird vom Sicherheitssubsystem festgelegt, wenn das Objekt erstellt wird. Der SECURITY_INFORMATION Parameter für SetSecurityInfo muss LABEL_SECURITY_INFORMATION enthalten, um die obligatorische Bezeichnung im Sicherheitsdeskriptor zu ändern.

Die obligatorische Bezeichnung, die bei der Objekterstellung zugewiesen wird, ist in der Regel die richtige Integritätsstufe für ein Objekt, und es ist nicht erforderlich, die obligatorische Bezeichnung zu ändern. Es kann jedoch Anwendungsentwurfsanforderungen geben, um die Integritätsebene eines Objekts zu ändern, wenn die Anwendung so konzipiert ist, dass sie mehrere Clientprozesse mit unterschiedlichen Integritätsebenen unterstützt.

Die Berechtigungen, die zum Ändern der obligatorischen Bezeichnung ACE in der SACL eines Sicherheitsdeskriptors erforderlich sind, sind WRITE_OWNER. Das Schreiben der obligatorischen Bezeichnung in die SACL erfordert keine SE_SECURITY_NAME Berechtigung oder das zugriffsrecht ACCESS_SYSTEM_SECURITY. Die Integritätsebene in der obligatorischen Bezeichnung kann auf einen Wert festgelegt werden, der kleiner oder gleich der Integritätsebene des Antragstellers ist.

Die gängigste Änderung besteht darin, die Integritätsebene eines Objekts zu senken, damit ein Anwendungsprozess mit niedrigerer Integrität zugriff auf Änderungen hat. Beispielsweise muss eine Anwendung mit mittlerer Integritätsebene mit einem anderen Anwendungsprozess synchronisiert werden, der auf niedriger Integritätsebene ausgeführt wird. Der Prozess mit mittlerer Integrität erstellt ein benanntes Mutex-Objekt und weist ihm eine obligatorische Bezeichnung bei niedrig zu, damit ein Prozess mit niedriger Integrität den Mutex öffnen kann, um Ereignisse zu signalisieren.

Berechtigungen für erneutes Bezeichnen

Der Windows-Integritätsmechanismus definiert eine neue Windows-Sicherheitsberechtigung, SE_RELABEL_NAME. Wenn dies in einem Sicherheitszugriffstoken aktiviert ist, kann der Antragsteller die obligatorische Bezeichnung eines Objekts auf eine höhere Integritätsebene als die Integritätsebene im Zugriffstoken des Antragstellers festlegen. Die Standardsicherheitsrichtlinie für Windows Vista weist diese Berechtigung keinem Benutzer oder einer Gruppe zu. Die Berechtigung ist für Szenarien konzipiert, in denen ein Administratorprozess, der mit einer hohen Integritätsstufe ausgeführt wird, die obligatorische Bezeichnung für Objekte auf der Systemintegritätsebene ändern oder zuweisen muss. Windows Vista verfügt nicht über Aufgaben, die die Berechtigung zum erneuten Bezeichnen erfordern oder verwenden.

Wie Windows Objekten eine obligatorische Bezeichnung zuweist

Windows weist einem sicherungsfähigen Objekt beim Erstellen des Objektsicherheitsdeskriptors eine obligatorische Bezeichnung zu. Die Integritätsebene für ein neues Objekt wird auf eine von drei Arten zugewiesen:

  • Das Sicherheitssubsystem weist dem Objekt eine obligatorische Bezeichnung zu, wenn der Sicherheitsdeskriptor für das Objekt erstellt wird.
  • Der Erstellungsprozess gibt eine explizite obligatorische Bezeichnung als Sicherheitsattribute an, wenn das Objekt mithilfe einer Funktion erstellt wird, z. B. CreateFile.
  • Der übergeordnete Container definiert eine vererbbare obligatorische Bezeichnung ACE, die für untergeordnete Objekte gilt, die im Container erstellt werden.

Die einfachste Möglichkeit, zu verstehen, wie Objektintegritätsebenen zugewiesen werden, besteht darin, davon auszugehen, dass jedem Objekt eine obligatorische Bezeichnung mit der gleichen Integritätsebene wie die Integritätsebene des Antragstellers des Erstellungsprozesses (oder Threads) zugewiesen wird. Es gibt jedoch Ausnahmen von der allgemeinen Idee basierend auf Objekttyp und Betreffintegritätsebene. Die Ausnahmen sind das Ergebnis von Entwurfsentscheidungen, die erforderlich sind, um andere Systemanforderungen für eine konsistente Benutzeroberfläche zu unterstützen, wenn verschiedene Sicherheitsrichtlinien, z. B. UAC, aktiviert oder deaktiviert sind.

Obligatorische Bezeichnungen können auf alle sicherungsfähigen Objekte angewendet werden, die die Zugriffssteuerung basierend auf dem Sicherheitsdeskriptor haben. Es gibt viele Arten von sicherungsfähigen Objekten, einschließlich Prozess- und Threadobjekten, benannten Objekten und persistenten Objekten wie Dateien oder Registrierungsschlüsseln. Windows Vista weist allen Objekttypen keine expliziten obligatorischen Bezeichnungen zu, wenn Objekte erstellt werden. Die Objekttypen, denen das Sicherheitssubsystem bei der Objekterstellung obligatorische Bezeichnungen zuweist, sind:

  • Prozess
  • Thread
  • Zugriffstoken
  • Auftrag

Alle anderen Objekttypen verfügen entweder über eine implizite Standardbezeichnung oder eine geerbte obligatorische Bezeichnung. Denken Sie daran, dass während der Initialisierung des Zugriffstokens dem Sicherheitszugriffstoken, das während einer interaktiven Anmeldung erstellt wird, eine Integritätsebene zugewiesen wird. Der erste Prozess, der im Namen einer Benutzeranmeldung gestartet wird, ist userinit.exe, der den Shellprozess startet, explorer.exe. Userinit.exe wird von einem Systemdienst (Winlogon) gestartet, der einen Aufruf von CreateProcessAsUser verwendet und das Zugriffstoken für den interaktiven Anmeldebenutzer übergibt.

CreateProcessAsUser erstellt unter anderem ein Prozessobjekt und einen anfänglichen Thread. Wenn das Prozessobjekt erstellt wird, wird dem Sicherheitsdeskriptor für diesen Prozess die Integritätsebene des Zugriffstokens zugewiesen, das dem neuen Prozess als primäres Zugriffstoken zugewiesen ist. Wenn userinit.exe CreateProcess aufruft, um die Shell zu starten, wird das Prozessobjekt für explorer.exe initialisiert. Das Prozessobjekt enthält einen Sicherheitsdeskriptor und ein primäres Zugriffstoken. Die obligatorische Bezeichnung für den explorer.exe Prozess wird auf die Integritätsebene des Erstellungsprozesses festgelegt, userinit.exe, die mittel ist. Das primäre Zugriffstoken für explorer.exe wird vom erstellenden übergeordneten Prozess geerbt, userinit.exe und weist die Integritätsebene medium auf. Wenn der explorer.exe Prozess einen neuen Thread erstellt, erhält das Threadobjekt einen Sicherheitsdeskriptor, und das Sicherheitssubsystem weist dem Threadobjekt basierend auf der Integritätsebene des Erstellungsprozesses eine Integritätsebene zu. Den Threadobjekten innerhalb des explorer.exe-Prozesses wird die Integritätsebene medium zugewiesen, d. h. die Integritätsebene des primären Zugriffstokens des Erstellungsprozesses.

Hinweis

Ein Zugriffstokenobjekt ist ein sicherungsfähiges Objekt mit einem eigenen Sicherheitsdeskriptor. Der Sicherheitsdeskriptor des Tokens wird verwendet, um den zulässigen Zugriff während der OpenProcessToken- oder OpenThreadToken-Funktionen zu bestimmen. Das Zugriffstokenobjekt verfügt über eine obligatorische Bezeichnung im Sicherheitsdeskriptor für das Zugriffstokenobjekt. Das Zugriffstoken enthält auch eine SID der Integritätsebene in der Liste der Zugriffstokengruppen, die die Integritätsebene des Antragstellers darstellt.

Durch das Zuweisen obligatorischer Bezeichnungen zu Prozess-, Thread-, Token- und Auftragsobjekten verhindert der Integritätsmechanismus, dass Prozesse für denselben Benutzer mit niedrigeren Integritätsebenen auf diese Objekttypen zugreifen und deren Inhalt oder Verhalten ändern, z. B. das Einfügen einer DLL oder das Annehmen eines Zugriffstokens auf höherer Ebene.

Standardintegritätsstufe

Nicht allen Objekttypen wird im Sicherheitsdeskriptor eine obligatorische Bezeichnung ACE zugewiesen. Wenn im Sicherheitsdeskriptor eine obligatorische Bezeichnung ACE vorhanden ist, wird dies als explizite obligatorische Bezeichnung bezeichnet. Wenn kein obligatorischer Bezeichnungs-ACE vorhanden ist, verwendet das Sicherheitssubsystem während der obligatorischen Richtlinienüberprüfung eine implizite obligatorische Bezeichnung für dieses Objekt. Die standardmäßige obligatorische Bezeichnung weist allen sicherungsfähigen Objekten eine mittlere Integritätsebene zu. Wenn im Sicherheitsdeskriptor keine obligatorische Bezeichnung definiert ist, gilt die implizite obligatorische Bezeichnung für alle Objekttypen.

Die Standardobjektintegritätsebene medium in Kombination mit der obligatorischen Standardrichtlinie von NO_WRITE_UP schränkt den Änderungszugriff auf alle Objekte durch Prozesse ein, deren Integritätsgrad kleiner als medium ist. Die standardmäßige obligatorische Bezeichnung und Richtlinie verhindert, dass nicht vertrauenswürdige Prozesse mit niedriger Integrität Benutzer- oder Systemdateien oder Registrierungsschlüssel auf dem System ändern, die andernfalls freien Schreibzugriff in der DACL zulassen.

Die NTFS-Dateisystemobjekte und Registrierungsschlüssel werden nicht automatisch bezeichnet, wenn sie erstellt werden. Diese Objekte verfügen nach dem Upgrade von einer früheren Version von Windows auf Windows Vista nicht über obligatorische Bezeichnungen. Dateien in Nicht-NTFS-Dateisystemen (CDFS oder FAT32), die keine Sicherheitsbeschreibungen haben, sind keine sicherungsfähigen Objekte und verfügen nicht über eine Integritätsebene. Jeder Sicherheitsdeskriptor muss über eine implizite obligatorische Bezeichnung verfügen.

Prozesse mit einer Integritätsebene des Antragstellers auf oder höher erstellen Dateien und Registrierungsschlüssel ohne explizite Bezeichnung. Folglich weisen das Dateisystem und die Registrierungsobjekte, die von einem Prozess mit hoher Oder Systemintegritätsstufe erstellt werden, eine implizite Mittelbezeichnung auf. Anwendungen, die obligatorische Bezeichnungen verwenden, können beim Erstellen von Objekten explizite Bezeichnungen definieren. Windows Vista weist dem Dateisystem oder der Registrierung jedoch standardmäßig keine Bezeichnungen zu, die höher als die mittlere Integritätsebene sind. Dies bedeutet nicht, dass diese Objekte notwendigerweise für Änderungen durch Prozesse mit niedrigerer Integrität offen sind. Die geerbte (oder standardmäßige) zugriffskontrollierte Liste für Dateisystem- oder Registrierungsobjekte, die von einem Prozess auf hoher oder Systemebene erstellt wurden, gewährt schreibzugriff nur Mitgliedern der Gruppe Administratoren oder lokalen System- oder Dienstkonten.

Eine Reihe von Entwurfseinschränkungen, die mithilfe der standardmäßigen impliziten obligatorischen Bezeichnung des Mediums erforderlich sind, anstatt eine explizite obligatorische Bezeichnung basierend auf der Integritätsebene des Antragstellers für die meisten Objekttypen zuzuweisen. Ein bestimmtes Beispiel basiert auf der Möglichkeit, die Benutzerkontensteuerung mithilfe einer lokalen Sicherheitsrichtlinie zu aktivieren oder zu deaktivieren. Wenn die UAC deaktiviert ist, werden für einen Benutzer, der Mitglied der lokalen Administratorgruppe ist, alle Prozesse mit einem Zugriffstoken für vollständige Berechtigungen auf hoher Integritätsebene ausgeführt. Wenn alle Objekte explizit auf der Integritätsebene des Antragstellers bezeichnet werden, wird allen Dateien wie Dokumenten und Kalkulationstabellen, die der Benutzer erstellt, eine hohe Integritätsebene zugewiesen. Die hohe Bezeichnung erscheint angemessen, obwohl die geerbten DACL-Berechtigungen für das Benutzerprofil eine ausreichende Zugriffssteuerung für den Benutzerzugriff bieten. Wenn die UAC jedoch von einem lokalen Computer oder Gruppenrichtlinie aktiviert wird, wird den meisten Prozessen, die vom gleichen Benutzer ausgeführt werden, ein gefiltertes Sicherheitszugriffstoken mit mittlerer Integritätsebene zugewiesen. Nachdem UAC aktiviert wurde, kann der Benutzer keine Dateien öffnen, die erstellt wurden, als UAC deaktiviert wurde. Eine Anwendung mit mittlerer Integrität, die versucht hat, die Dokumente mit hoher Integrität des Benutzers zu öffnen, erhält den Fehler Zugriff verweigert.

Wenn ein Prozess mit einer Betreffintegritätsebene ausgeführt wird, die kleiner als die Standardintegritätsstufe medium ist, verfügt dieser Prozess über eingeschränkte Zugriffsberechtigungen für alle Objekte, die über eine implizite mittlere Integritätsebene verfügen. Prozesse mit einer niedrigen Integritätsebene können kein Objekt mit einer expliziten oder impliziten Integritätsebene von mittel oder höher ändern, unabhängig von den Zugriffsrechten, die dem Sicherheitsprinzipal in der DACL gewährt werden. Daher werden alle Objekte, die von einem Prozess erstellt werden, deren Integritätsebene für Antragsteller kleiner als die Standardebene (mittel) ist, explizit vom Sicherheitssubsystem bezeichnet. Zugriffsbeschränkungen für Prozesse mit niedriger Integrität sind in Windows Vista möglich, da alle Anwendungen in der Regel auf der mittleren Integritätsebene ausgeführt werden und die Anwendungskompatibilitätsprobleme minimal sind. Anwendungen, die bei niedriger Integrität ordnungsgemäß ausgeführt werden, erfordern in der Regel bestimmte Entwurfsänderungen, um mit eingeschränktem Zugriff ordnungsgemäß zu funktionieren. Die Entwurfsänderungen werden im Abschnitt unten unter Entwerfen von Anwendungen erläutert, die mit einer niedrigen Integritätsstufe ausgeführt werden.

Bezeichnen von Objekten, die von niedrigen Themen erstellt wurden

Anwendungen können mit der CreateProcessAsUser-Funktion auf einer niedrigen Integritätsebene gestartet werden. Ein niedriger Prozess wird von CreateProcessAsUser mit den folgenden Informationen zur Integritätsstufe initialisiert:

  • Das neue Prozessobjekt wird mit einem Sicherheitsdeskriptor erstellt, der eine obligatorische Bezeichnung mit niedriger Integrität enthält.
  • Für diesen Prozess wird ein neues Threadobjekt mit einem Sicherheitsdeskriptor erstellt, der eine obligatorische Bezeichnung mit niedriger Integrität enthält.
  • Dem neuen Prozess wird ein primäres Zugriffstoken zugewiesen. Das Zugriffstokenobjekt verfügt über einen Sicherheitsdeskriptor mit einer obligatorischen Bezeichnung bei niedrig, und das Zugriffstoken enthält ein TokenIntegrityLevel mit einer SID mit niedriger Integrität, die die Integritätsebene des Antragstellers darstellt.

Angenommen, der Prozess mit niedriger Integrität wird ausgeführt und möchte einen Thread erstellen. Zum Erstellen eines Threads muss ein eigenes Prozessobjekt für den Schreibzugriff geöffnet werden, um ein neues Threadobjekt zu erstellen. Wenn die obligatorische Bezeichnung für das Prozessobjekt mittel wäre, würde der niedrige Betreff den Prozess nicht öffnen und wäre nicht in der Lage, einen neuen Thread zu erstellen. Da das Prozessobjekt auch mit niedriger Integrität bezeichnet wird, kann der Antragsteller mit niedriger Integrität den Prozess für den Schreibzugriff öffnen und ein neues Threadobjekt erstellen. Das Beispiel zeigt, warum es wichtig ist, dass die obligatorischen Bezeichnungen für das Prozessobjekt, die Threadobjekte und das Sicherheitszugriffstoken auf derselben Integritätsebene konsistent sind.

Hinweis

Dies gilt für alle Integritätsstufen, nicht nur für low-Themen.

Angenommen, der low-Prozess erstellt eine temporäre Datei. Die Anwendung ruft CreateFile auf, um eine neue Datei zu erstellen, einige Daten zu schreiben und die Datei zu schließen. Später möchte der low-Prozess dieselbe Datei erneut öffnen, um Daten anzufügen. Wenn die temporäre Datei eine implizite obligatorische Standardbezeichnung auf mittlerer Integritätsebene aufweist, kann der niedrige Prozess die Datei, die er zuvor erstellt hat, nicht erneut öffnen, um den Zugriff zu ändern. Das gleiche Problem kann bei jedem sicherungsfähigen Objekt auftreten, das ein Antragsteller mit einer Integritätsebene unterhalb der Standardebene des Mediums erstellt. Daher wird allen sicherungsfähigen Objekten, die von einem Antragsteller mit einem Integritätsgrad unterhalb der Standardebene erstellt werden, automatisch eine explizite obligatorische Bezeichnung zugewiesen. Anders ausgedrückt: Alle Kernelobjekte, Registrierungsschlüssel und Dateisystemobjekte werden explizit mit niedrig bezeichnet, wenn die Integritätsebene des Antragstellers niedrig ist.

Erstellen eines Objekts mit einer bestimmten obligatorischen Bezeichnung

Die meisten Windows-Anwendungen müssen nicht "integritätsfähig" sein. Das Sicherheitssubsystem erstellt automatisch Objekte und weist ihnen eine obligatorische Bezeichnung zu. Da die meisten Anwendungen auf einer mittleren Integritätsebene ausgeführt werden und die Standardobjektintegritätsebene mittel ist, ändert die Integritätsrichtlinie die zulässige Zugriffssteuerung für die meisten Anwendungen nicht. Einige Anwendungen, z. B. Dienste, sind jedoch so konzipiert, dass sie Clientanwendungen auf verschiedenen Integritätsebenen unterstützen. Der Dienst wird möglicherweise mit einer höheren Integritätsebene als der Client ausgeführt und möchte neue Objekte, die im Auftrag des Clients erstellt wurden, explizit auf einer niedrigeren Integritätsebene bezeichnen. Die Integritätsebene des Objekts kann durch den Erstellungsprozess festgelegt werden. Die Einschränkung besteht darin, dass die Integritätsebene für das neue Objekt kleiner oder gleich der Integritätsebene des Erstellungsprozesses sein muss.

So erstellen Sie ein Objekt mit einer bestimmten obligatorischen Bezeichnung
  1. Erstellen Sie einen SDDL-Sicherheitsdeskriptor, der eine niedrige obligatorische Bezeichnung definiert, z. B.:
    #define LOW_INTEGRITY_SDDL_SACL_W L"S:(ML;;NW;;;LW)"
  2. Konvertieren Sie die SDDL-Zeichenfolge mithilfe von ConvertStringSecurityDescriptorToSecurityDescriptor in einen Sicherheitsdeskriptor.
  3. Weisen Sie den Sicherheitsdeskriptor mit der niedrigen obligatorischen Bezeichnung einer Sicherheitsattributestruktur zu.
  4. Übergeben Sie den Sicherheitsattribute-Parameter an den Aufruf, um ein Objekt zu erstellen, z. B. CreateFile.

Obligatorische Bezeichnungsvererbung

Windows Vista bezeichnet Dateien und Verzeichnisse im NTFS-Dateisystem nicht explizit. Wie bereits erwähnt, verwendet das Sicherheitssubsystem eine implizite obligatorische Bezeichnung mit einer Standardebene von Medium für Objekte, die keine obligatorische Bezeichnung im Sicherheitsdeskriptor aufweisen.

Anwendungen können so konzipiert werden, dass sie mit einer niedrigen Integritätsstufe ausgeführt werden. Internet im geschützten Modus Explorer ist ein Beispiel für eine Windows Vista-Anwendung, die für die Ausführung mit niedriger Integrität konzipiert ist. Anwendungen mit niedriger Integrität benötigen möglicherweise Ordner im Dateisystem, in denen sie temporäre Dateien oder Anwendungsdaten schreiben können. Im Fall von Internet Explorer im geschützten Modus wird der Ordner Temporäre Internetdatei im Benutzerprofil verwendet. Wie kann eine Anwendung mit geringem Wert in einen Dateisystemordner schreiben? Dem Ordner muss eine explizite obligatorische Bezeichnung zugewiesen werden, die schreibzugriff aus einem Prozess mit niedriger Integrität zulässt.

Abhängig vom Anwendungsentwurf gibt es möglicherweise andere zusammenarbeitende Prozesse, die dateien zum Ordner hinzufügen, der von der Anwendung mit niedriger Integrität verwendet wird. Wenn die anderen Prozesse ebenfalls mit niedriger Integrität ausgeführt werden, wird den von diesen Prozessen erstellten Dateien automatisch eine niedrige obligatorische Bezeichnung zugewiesen. Wenn der andere Partnerprozess jedoch über eine höhere Integrität verfügt, erstellt der Partnerprozess (ein Dateisynchronisierungsdienst oder Benutzer-Agent) möglicherweise Dateien im ordner low, die nicht automatisch als niedrig bezeichnet werden. Der Partnerprozess erstellt eine mittlere Datei in dem Ordner, der von der low-Anwendung verwendet wird, die von der anwendung mit geringem Wert nicht geändert oder gelöscht werden kann.

Der Integritätsmechanismus ermöglicht einem Ordner mit einer niedrigen obligatorischen Bezeichnung untergeordnete Objekte, Dateien und Unterordner, die jeweils eine andere, höhere obligatorische Bezeichnung aufweisen, da jedes Dateisystemobjekt über einen eindeutigen Sicherheitsdeskriptor verfügt. Es gibt viele Szenarien, in denen die Absicht besteht, dass für einen Ordner, dem eine niedrige obligatorische Bezeichnung zugewiesen ist, allen Dateien im Ordner eine niedrige obligatorische Bezeichnung zugewiesen werden muss, damit sie von einem niedrigen Prozess geändert werden können. Der Integritätsmechanismus unterstützt dies, indem obligatorische Bezeichnungs-ACEs vom übergeordneten Container auf Untercontainer und untergeordnete Objekte vererbt werden können.

Die obligatorische Ace-Typdatenstruktur enthält einen ACE-Header mit einem AceFlags-Feld. Das Feld AceFlags wird verwendet, um Vererbungsflags für den ACE-Typ zu definieren, die mit Vererbungsflags für andere ACE-Typen identisch sind, z. B. den Access Allowed ACE-Typ, der für den freien Zugriff verwendet wird. Obligatorische Bezeichnungs-ACEs können als vererbbar definiert werden, für Containererbung (CI) und/oder Objekterbung (Object Inherit, OI). Obligatorische Bezeichnungs-ACEs können nicht inherit_only (E/A) sein. Wenn einem Container ein vererbbarer obligatorischer Bezeichnungs-ACE zugewiesen ist, gilt die obligatorische Bezeichnung für den Container selbst und für die untergeordneten Objekte, für die die Vererbung gilt.

Ein Beispiel für eine vererbbare obligatorische Bezeichnung ist die niedrige obligatorische Bezeichnung in einem der Ordner, die unter jedem Benutzerprofil erstellt werden: %USERPROFILE%\AppData\LocalLow. Diesem Ordner wird eine niedrige obligatorische Bezeichnung zugewiesen, wenn das Profil initialisiert wird und als Ordner der obersten Ebene vorgesehen ist, der von Anwendungen mit niedriger Integrität standardmäßig schreibbar ist. Die folgende Abbildung zeigt die vererbbare obligatorische Bezeichnung im Ordner AppData\LocalLow, die mit dem Befehl Icacls angezeigt wird. Weitere Informationen dazu, wie Icacls obligatorische Bezeichnungen unterstützt, finden Sie in Anhang B: Icacls und Dateiintegritätsebenen.

Die Vererbungsflags in der obligatorischen Bezeichnung geben an, dass ace (OI) und (CI) ACE mit einer obligatorischen NO_WRITE_UP (NW)-Richtlinie ist. Alle Unterordner, die unter dem Ordner AppData\LocalLow erstellt werden, erben die vererbbare Bezeichnung.

Abbildung 4 Vererbbare niedrige obligatorische Bezeichnung

Wenn eine neue Datei oder ein neuer Unterordner aus einem mittleren Prozess erstellt wird, erbt das neue Objekt die niedrige obligatorische Bezeichnung. Im folgenden Beispiel wird die Eingabeaufforderung im Prozess mit mittlerer Integritätsebene ausgeführt. Eine Datei, newfile.txt, und der neue Ordner Temp wird im Ordner LocalLow erstellt, und beide Objekte erben die niedrige obligatorische Bezeichnung vom übergeordneten Container. Icacls gibt an, dass die obligatorische Bezeichnung mit der Bezeichnung (I) geerbt wird.

Abbildung 5 Erben einer obligatorischen Bezeichnung für ein untergeordnetes Objekt

Die Vererbung für obligatorische Bezeichnungen gewährleistet die Konsistenz der Integritätsebene von Objekten, die unter einem Teil des Dateisystemnamespace erstellt werden.

Vererbung und explizite Bezeichnungen

Objekte, die in einem Container erstellt wurden, der über eine vererbbare obligatorische Bezeichnung verfügt, erben die obligatorische Bezeichnung vom Container. Der Prozess, der ein neues Objekt erstellt, z. B. eine Datei, kann jedoch eine explizite obligatorische Bezeichnung im Parameter "Sicherheitsattribute" für die create-Funktion bereitstellen, z. B. CreateFile.

Wenn der Erstellungsprozess eine explizite Bezeichnung als Parameter für die Objekterstellungsfunktion bereitstellt, erhält das neue Objekt die explizite obligatorische Bezeichnung, die vom Aufrufer bereitgestellt wird, und erbt nicht vom übergeordneten Container. Die explizite obligatorische Bezeichnung kann eine Integritätsebene haben, die nicht höher ist als der Antragstellerprozess, der das Objekt erstellt. Die Integritätsebene in der expliziten obligatorischen Bezeichnung, die vom Antragsteller bereitgestellt wird, kann höher sein als die Integritätsebene in der vererbbaren obligatorischen Bezeichnung des übergeordneten Containers.

Einschränkung für reines Erben

Nur Erben (E/A) ist ein Flag in einem Zugriffssteuerungseintrag, das angibt, dass der ACE den Zugriff auf das Objekt, an das es angefügt ist, nicht steuert. Nur vererbte ACEs werden in der Regel Containerobjekten zugewiesen. Der nur vererbte ACE ist für den Container selbst nicht wirksam. Sie gilt vielmehr für untergeordnete Objekte des Containers. Es gibt eine Einschränkung für Themen, deren Integritätsgrad kleiner als die Standardeinstellung für das Festlegen INHERIT_ONLY Bezeichnungen für neue Objekte ist. Wenn es sich bei der für ein neues Containerobjekt übergebenen expliziten Bezeichnung um eine INHERIT_ONLY Bezeichnung handelt, deren Ebene kleiner als die Standardebene ist, wird die Bezeichnung als ungültig betrachtet und ignoriert. Die Begründung für diese Einschränkung ist, dass ein niedriger Betreff einen Container erstellt und versucht, eine INHERIT_ONLY Bezeichnung für den Container auf niedrig festzulegen. Wenn die INHERIT_ONLY Bezeichnung akzeptiert würde, wäre die effektive Integritätsebene für den Container die implizite Standardebene des Mediums.

Darüber hinaus können Die Teilnehmer keine INHERIT_ONLY Bezeichnung mit einer Integritätsebene definieren, die höher als die Integritätsebene des Antragstellers ist. Beispielsweise kann ein mittlerer Antragsteller keine INHERIT_ONLY Bezeichnung mit einem Integritätsgrad von hoch definieren.

Geschützte SACL- und Bezeichnungsvererbung

SDDL unterstützt das Definieren einer geschützten SACL, die eine explizite obligatorische Bezeichnung enthalten kann. Die geschützte SACL legt das SE_SACL_PROTECTED-Flag im Feld SECURITY_DESCRIPTOR_CONTROL des Sicherheitsdeskriptors fest. Die logische Trennung von LABEL_SECURITY_INFORMATION und SACL_SECURITY_INFORMATION in Bezug auf Zugriffsrechte ist nicht vollständig im Hinblick auf das Verhalten einer geschützten SACL. Obligatorische Bezeichnungen werden in der SACL gespeichert. Eine geschützte SACL impliziert, dass auch die obligatorische Bezeichnung geschützt ist.

Wenn das SE_SACL_PROTECTED-Flag im SECURITY_DESCRIPTOR_CONTROL festgelegt ist, ist auch die obligatorische Bezeichnung geschützt.

  • Wenn keine obligatorische Bezeichnungs-ACE in der geschützten SACL vorhanden ist, wird kein vererbbarer obligatorischer Bezeichnungs-ACE aus dem Container angewendet (das neue Objekt verfügt über eine implizite obligatorische Standardbezeichnung).
  • Wenn in der geschützten SACL eine obligatorische Bezeichnungs-ACE vorhanden ist, wirken sich Änderungen an der vererbbaren Bezeichnung ACE für den Container nicht auf dieses Objekt aus.

Weitere Informationen zur SDDL finden Sie unter Anhang A: SDDL für obligatorische Bezeichnungen oder Windows-Integritätsmechanismusressourcen.

Funktionsweise von Zugriffsüberprüfungen mit obligatorischer Richtlinie

Die AccessCheck-Funktion erzwingt die obligatorische Richtlinie. AccessCheck vergleicht den angegebenen Sicherheitsdeskriptor mit dem angegebenen Zugriffstoken und gibt im AccessStatus-Parameter an, ob der Zugriff gewährt oder verweigert wird. Die AccessCheck-Funktion vergleicht zunächst die Integritätsebene im ClientToken mit der obligatorischen Bezeichnung in der SACL von pSecurityDescriptor , um basierend auf der obligatorischen Richtlinie zu bestimmen, welche Zugriffsrechte nicht verfügbar sind. Nach der obligatorischen Richtlinienüberprüfung vergleicht AccessCheck den gewünschten Zugriff mit den in der DACL gewährten Zugriffsrechten.

Die obligatorische Standardrichtlinie verhindert, dass Prozesse mit niedriger Integrität generischen Schreibzugriff auf Objekte mit höherer Integrität erhalten. Beispielsweise wird einem Prozess mit niedriger Integrität standardmäßig der generische Schreibzugriff auf ein Objekt mit einer höheren Integritätsebene verweigert. Wenn pSecurityDescriptor keinen obligatorischen ACE enthält, wird von einem impliziten obligatorischen ACE ausgegangen, der dem Objekt eine mittlere Integritätsebene zuweist. Der GenericMapping-Parameter bestimmt, welche Zugriffsrechte dem generischen Schreibzugriff zugeordnet sind. Wenn der GenericMapping-Parameter alle Nullen aufweist, gewährt die Integritätsprüfung keine spezifischen Zugriffsrechte für einen ClientToken mit niedrigerer Integrität. Nachdem die Integritätsprüfung die generischen Zugriffsrechte ermittelt hat, die dem Aufrufer basierend auf der obligatorischen Richtlinie zur Verfügung stehen, wird die DACL des Sicherheitsdeskriptors mit ClientToken verglichen, um die verbleibenden gewährten Zugriffsrechte zu ermitteln.

Benutzeroberflächenberechtigungsisolation (User Interface Privilege Isolation, UIPI) und Integrität

Die Benutzeroberflächenberechtigungsisolation (User Interface Privilege Isolation, UIPI) implementiert Einschränkungen im Windows-Subsystem, die verhindern, dass Anwendungen mit niedrigeren Berechtigungen Fensternachrichten senden oder Hooks in Prozessen mit höheren Berechtigungen installieren. Anwendungen mit höheren Berechtigungen dürfen Fensternachrichten an Prozesse mit niedrigeren Berechtigungen senden. Die Einschränkungen werden in den Nachrichtenfunktionen SendMessage und zugehörigen Fenstern implementiert. Nicht alle Fensternachrichten, die von einem Prozess mit niedrigeren Berechtigungen an einen Prozess mit höheren Berechtigungen gesendet werden, werden blockiert. Im Allgemeinen können Nachrichten vom Typ "Lese", z. B. WM_GETTEXT, von einer niedrigeren Berechtigung an ein Fenster mit höheren Berechtigungen gesendet werden. Schreibtypmeldungen, z. B. WM_SETTEXT, werden jedoch blockiert.

Die Benutzeroberflächenberechtigungsstufe befindet sich auf Prozessebene und gilt für alle Fenster, die vom Prozess erstellt wurden. Das USER-Subsystem wird initialisiert, wenn der Prozess den ersten Aufruf der Windows-Grafikgeräteschnittstelle (GDI) vornimmt. Während der Prozessinitialisierung ruft das USER-Subsystem das Sicherheitssubsystem auf, um die Integritätsebene zu bestimmen, die im primären Sicherheitszugriffstoken des Prozesses zugewiesen ist. Nachdem das BENUTZER-Subsystem die Benutzeroberflächenberechtigungsstufe während der Prozessinitialisierung festgelegt hat, ändert sie sich nicht. Das Festlegen von TokenIntegrityLevel für einen Thread auf einen niedrigeren Wert wirkt sich nicht auf die Benutzeroberflächenberechtigungsstufe des Prozesses oder die fenster, die von diesem Prozess oder Thread geöffnet werden, aus.

UIPI beeinträchtigt oder ändert das Verhalten von Fenstermessagings zwischen Anwendungen auf derselben Berechtigungs- oder Integritätsebene nicht. UIPI verhindert, dass Prozesse mit niedrigeren Berechtigungen auf Prozesse mit höheren Berechtigungen zugreifen, indem das folgende Verhalten blockiert wird. Ein Prozess mit niedrigeren Berechtigungen kann nicht:

  • Führen Sie eine Fensterhandlevalidierung eines Prozesses aus, der mit höheren Rechten ausgeführt wird.
  • Verwenden Sie SendMessage oder PostMessage, um Anwendungsfenster mit höheren Rechten auszuführen. Diese APIs geben einen Erfolg zurück, löschen die Fenstermeldung jedoch im Hintergrund.
  • Verwenden Sie Threadhooks, um einen Prozess anzufügen, der mit höheren Rechten ausgeführt wird.
  • Verwenden Sie Journalhooks, um einen Prozess zu überwachen, der mit höheren Rechten ausgeführt wird.
  • Führen Sie die Einschleusung der Dll (Dynamic Link Library) in einen Prozess aus, der mit höheren Rechten ausgeführt wird.

Wenn UIPI aktiviert ist, werden die folgenden freigegebenen USER-Ressourcen weiterhin von Prozessen mit unterschiedlichen Berechtigungsstufen gemeinsam genutzt.

  • Desktopfenster, das tatsächlich die Bildschirmoberfläche besitzt
  • Schreibgeschützter freigegebener Arbeitsspeicher für den Desktopheap
  • Globale Atomtabelle
  • Zwischenablage

Das Zeichnen auf dem Bildschirm ist eine weitere Aktion, die nicht von UIPI blockiert wird. Das GDI-Modell (USER/Graphics Device Interface) lässt keine Kontrolle über Malflächen zu. Daher ist es möglich, dass eine Anwendung, die mit weniger Rechten ausgeführt wird, die Oberfläche des Anwendungsfensters für eine Anwendung mit höheren Rechten über zeichnen kann.

UIAccess für Benutzeroberflächenautomatisierungsanwendungen

Die Automatisierung der Microsoft-Benutzeroberfläche ist das Windows Vista-Modell, das Barrierefreiheitsanforderungen mit Verbesserungen gegenüber dem früheren Modell unterstützt, das als Microsoft Active Accessibility (MSAA) bezeichnet wird. Anwendungen, die zur Unterstützung barrierefreier Benutzerfreundlichkeit entwickelt wurden, steuern das Verhalten anderer Windows-Anwendungen im Namen des Benutzers. Wenn alle Anwendungen (der Automatisierungsclient und der Server) als Standardbenutzer ausgeführt werden, d. h. auf einer mittleren Integritätsebene, beeinträchtigen die UIPI-Einschränkungen das Ui-Automatisierungsmodell nicht.

Es kann jedoch vorkommen, dass ein Administrator eine Anwendung mit erhöhten Berechtigungen basierend auf UAC im Admin Genehmigungsmodus ausführt. Das Benutzeroberflächenautomatisierungsprogramm ist nicht in der Lage, die Grafikoberfläche von Anwendungen mit erhöhten Rechten auf dem Desktop zu steuern, ohne die Von UIPI implementierten Einschränkungen zu umgehen. Die Möglichkeit, UIPI-Einschränkungen für SendMessage über Berechtigungsstufen hinweg zu umgehen, ist für Benutzeroberflächenautomatisierungsprogramme verfügbar, die ein spezielles Sicherheitsattribute im Anwendungsmanifest des Programms verwenden, das als UIAccess bezeichnet wird.

Im Folgenden ist ein Beispiel für einen Anwendungsmanifesteintrag für ein UIAccess-Programm aufgeführt.

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"> 
  <security> 
    <requestedPrivileges> 
    <requestedExecutionLevel 
      level="asInvoker" 
      UIAccess="true" /> 
    </requestedPrivileges> 
  </security> 
</trustInfo>

Durch Angabe von UIAccess="true" im attribut requestedPrivileges gibt die Anwendung eine Anforderung an, UIPI-Einschränkungen beim Senden von Fensternachrichten über Berechtigungsstufen hinweg zu umgehen. Windows Vista implementiert die folgenden Richtlinienüberprüfungen, bevor eine Anwendung mit UIAccess-Berechtigungen gestartet wird.

  • Die Anwendung muss über eine digitale Signatur verfügen, die mithilfe eines digitalen Zertifikats überprüft werden kann, das bis zu einem vertrauenswürdigen Stamm im Zertifikatspeicher der vertrauenswürdigen Stammzertifizierungsstellen des lokalen Computers verkettet wird.
  • Die Anwendung muss in einem lokalen Ordner-Anwendungsverzeichnis installiert werden, das nur von Administratoren geschrieben werden kann, z. B. im Verzeichnis Programme. Die zulässigen Verzeichnisse für die Anwendungen der Benutzerflächenautomatisierung sind:
    • %ProgramFiles% und die dazugehörigen Unterverzeichnisse
    • %WinDir% und die dazugehörigen Unterverzeichnisse, außer einigen Unterverzeichnissen, die ausgeschlossen sind, da Standardbenutzer über Schreibzugriff verfügen

Zu den %WinDir%-Unterverzeichnissen, die ausgeschlossen sind, gehören:

  • \Debuggen
  • \PCHealth
  • \Registrierung
  • \System32\ccm
  • \System32\com
  • \System32\FxsTmp
  • \System32\Spool
  • \System32\Aufgaben

Windows Vista bietet eine Sicherheitseinstellung für die lokale Computerrichtlinie und für Gruppenrichtlinie, um die Anforderung anzupassen, dass UIAccess-Programme von sicheren Standorten gestartet werden müssen. Die Einstellung wird unter den Sicherheitsoptionen unter lokale Richtlinien für die lokalen Sicherheitsrichtlinien definiert. Die Sicherheitsrichtlinie lautet wie folgt:

Benutzerkontensteuerung: Erhöhte Rechte nur für UIAccess-Anwendungen, die an sicheren Orten installiert sind

Diese Einstellung ist standardmäßig aktiviert. Ein Administrator kann sie jedoch deaktivieren, wenn es Situationen gibt, in denen UIAccess-Anwendungen (Barrierefreie Technologie), die aus Ordnern gestartet werden müssen, nicht durch schreibgeschützten Administratorzugriff geschützt sind.

Wenn die Benutzeroberflächenautomatisierungsanwendung, die UIAccess anfordert, die Anforderungen für die UIAccess-Einstellung erfüllt, startet Windows Vista die Anwendung mit der Möglichkeit, die meisten UIPI-Einschränkungen zu umgehen. Wenn die Benutzeroberflächenautomatisierungsanwendung die Sicherheitseinschränkungen nicht erfüllt, wird die Anwendung ohne UIAccess-Rechte gestartet und kann nur mit Anwendungen mit derselben oder niedrigerer Berechtigungsstufe interagieren.

Ein Prozess, der mit UIAccess-Rechten gestartet wird:

  • Verfügt über die Möglichkeit, das Vordergrundfenster festzulegen.
  • Kann jedes Anwendungsfenster mithilfe der SendInput-Funktion steuern.
  • Verfügt über Leseeingaben für alle Integritätsebenen mit Hooks auf niedriger Ebene, Roheingabe, GetKeyState, GetAsyncKeyState und GetKeyboardInput.
  • Kann Journalhaken festlegen.
  • Verwenden von AttachThreadInput zum Anfügen eines Threads an eine Eingabewarteschlange mit höherer Integrität

Anwendungen, die mit UIAccess-Rechten für einen Standardbenutzer gestartet werden, erhalten einen etwas höheren Wert der Integritätsebene im Zugriffstoken. Die Zugriffstokenintegritätsstufe für die UIAccess-Anwendung für einen Standardbenutzer ist der Wert der mittleren Integritätsebene sowie ein Inkrement von 0x10. Die höhere Integritätsebene für UIAccess-Anwendungen verhindert, dass andere Prozesse auf demselben Desktop auf der mittleren Integritätsebene das UIAccess-Prozessobjekt öffnen.