MutexSecurity-Klasse

Ein MutexSecurity-Objekt gibt Zugriffsrechte für einen benannten Systemmutex an. Darüber hinaus wird angegeben, wie Zugriffsversuche überwacht werden. Zugriffsrechte auf den Mutex werden als Regeln ausgedrückt, wobei jede Zugriffsregel durch ein MutexAccessRule-Objekt dargestellt wird. Jede Überwachungsregel wird durch ein MutexAuditRule-Objekt dargestellt.

Dadurch wird das zugrunde liegende Sicherheitssystem von Windows gespiegelt, in dem alle sicherungsfähigen Objekte maximal über jeweils eine freigegebene Zugriffssteuerungsliste (DACL – Discretionary Access Control List) verfügen, die den Zugriff auf das gesicherte Objekt steuert, sowie maximal eine Systemzugriffssteuerungsliste (SACL – System Access Control List), die angibt, welche Zugriffsversuche überwacht werden. Bei DACL und SACL handelt es sich um geordnete Listen von ACEs (Access Control Entries, Zugriffssteuerungseinträge), die den Zugriff und die Überwachung für Benutzer und Gruppen angeben. Ein MutexAccessRule-Objekt oder MutexAuditRule-Objekt kann u. U. mehrere ACEs darstellen.

Hinweis
Ein Mutex-Objekt kann einen lokalen Mutex oder einen benannten Systemmutex darstellen. Die Windows-Zugriffssteuerungssicherheit ist nur für benannte Systemmutexe sinnvoll.

Die Klassen MutexSecurity, MutexAccessRule und MutexAuditRule blenden die Implementierungsdetails von ACLs und ACEs aus. Mithilfe dieser Klassen können Sie die siebzehn verschiedenen ACE-Typen und die komplexen Aufgaben bei der ordnungsgemäßen Verwaltung der Vererbung und der Weitergabe von Zugriffsrechten ignorieren. Diese Objekte sollen darüber hinaus auch die folgenden häufigen Zugriffssteuerungsfehler verhindern:

• Das Erstellen einer Sicherheitsbeschreibung mit einer NULL-DACL. Mithilfe eines NULL-Verweises auf eine DACL können beliebige Benutzer einem Objekt Zugriffsregeln hinzufügen. Dadurch werden Denial-of-Service-Angriff ermöglicht. Ein neues MutexSecurity-Objekt beginnt immer mit einer leeren DACL, wodurch allen Benutzern der Zugriff verweigert wird.

• Das Verstoßen gegen die kanonische Reihenfolge der ACEs. Wenn die ACE-Liste in der DACL keine kanonische Reihenfolge aufweist, erhalten Benutzer möglicherweise unbeabsichtigt Zugriff auf das gesicherte Objekt. Verweigerte Zugriffsrechte müssen z. B. immer vor gewährten Zugriffsrechten angeordnet werden. MutexSecurity-Objekte behalten intern die richtige Reihenfolge bei.

• Das Bearbeiten von Sicherheitsbeschreibungsflags, das nur vom Ressourcen-Manager gesteuert werden soll.

• Das Erstellen ungültiger Kombinationen von ACE-Flags.

• Das Bearbeiten von geerbten ACEs. Vererbung und Weitergabe werden vom Ressourcen-Manager als Reaktion auf die von Ihnen vorgenommenen Änderungen an den Zugriffs- und Überwachungsregeln behandelt.

• Das Einfügen von bedeutungslosen ACEs in ACLs.

Die einzigen von .NET-Sicherheitsobjekten nicht unterstützten Funktionen sind gefährliche Aktivitäten. Diese sollten von den meisten Anwendungsprogrammierern vermieden werden. Als gefährliche Aktivitäten gelten u. a.:

• Aufgaben auf niedriger Ebene, die normalerweise vom Ressourcen-Manager ausgeführt werden.

• Das Hinzufügen oder Entfernen von Zugriffssteuerungseinträgen ohne Beibehaltung der kanonischen Reihenfolge.

Um die Windows-Zugriffssteuerungssicherheit für einen benannten Mutex zu ändern, rufen Sie mithilfe der Mutex.GetAccessControl-Methode das MutexSecurity-Objekt ab. Ändern Sie das Sicherheitsobjekt durch Hinzufügen und Entfernen von Regeln, und fügen Sie es dann mithilfe der Mutex.SetAccessControl-Methode erneut an.

Wichtig
Änderungen an einem MutexSecurity-Objekt wirken sich erst dann auf die Zugriffsebenen für den benannten Mutex aus, wenn die Mutex.SetAccessControl-Methode aufgerufen wird, um dem benannten Mutex das geänderte Sicherheitsobjekt zuzuweisen.

Sie können die Zugriffssteuerungssicherheit aus einem Mutex in einen anderen kopieren, indem Sie mithilfe der Mutex.GetAccessControl-Methode ein MutexSecurity-Objekt abrufen, das die Zugriffs- und Überwachungsregeln für den ersten Mutex darstellt. Verwenden Sie anschließend die Mutex.SetAccessControl-Methode oder einen Konstruktor, der ein MutexSecurity-Objekt akzeptiert, um diese Regeln dem zweiten Mutex zuzuweisen.

Benutzer, die SDDL (Security Descriptor Definition Language) verwenden, können mithilfe der SetSecurityDescriptorSddlForm-Methode Zugriffsregeln für einen benannten Mutex festlegen und mithilfe der GetSecurityDescriptorSddlForm-Methode eine Zeichenfolge abrufen, die die Zugriffsregeln im SDDL-Format darstellt. Dies wird nicht für Neuentwicklungen empfohlen.

Hinweis
Sicherheit wird für Synchronisierungsobjekte für Windows 98 oder Windows Millennium Edition nicht unterstützt.

Im folgenden Codebeispiel wird die Aufteilung in Allow-Regeln und in Deny-Regeln veranschaulicht. Außerdem wird die Kombination von Rechten in kompatiblen Regeln dargestellt. Im Beispiel wird ein MutexSecurity-Objekt erstellt. Außerdem werden Regeln hinzugefügt, die dem aktuellen Benutzer eine Reihe von Rechten gewähren und verweigern, und das erhaltene Regelpaar wird angezeigt. Anschließend werden dem aktuellen Benutzer im Beispiel neue Rechte gewährt und das Ergebnis wird angezeigt, das die Zusammenführung der neuen Rechte mit der vorhandenen Allow-Regel darstellt.

Hinweis
In diesem Beispiel wird das Sicherheitsobjekt nicht an ein Mutex-Objekt angefügt. Beispiele, in denen Sicherheitsobjekte angefügt werden, finden Sie unter Mutex.GetAccessControl und Mutex.SetAccessControl.

using System;
using System.Threading;
using System.Security.AccessControl;
using System.Security.Principal;

public class Example
{
    public static void Main()
    {
        // Create a string representing the current user.
        string user = Environment.UserDomainName + "\\" + 
            Environment.UserName;

        // Create a security object that grants no access.
        MutexSecurity mSec = new MutexSecurity();

        // Add a rule that grants the current user the 
        // right to enter or release the mutex.
        MutexAccessRule rule = new MutexAccessRule(user, 
            MutexRights.Synchronize | MutexRights.Modify, 
            AccessControlType.Allow);
        mSec.AddAccessRule(rule);

        // Add a rule that denies the current user the 
        // right to change permissions on the mutex.
        rule = new MutexAccessRule(user, 
            MutexRights.ChangePermissions, 
            AccessControlType.Deny);
        mSec.AddAccessRule(rule);

        // Display the rules in the security object.
        ShowSecurity(mSec);

        // Add a rule that allows the current user the 
        // right to read permissions on the mutex. This rule
        // is merged with the existing Allow rule.
        rule = new MutexAccessRule(user, 
            MutexRights.ReadPermissions, 
            AccessControlType.Allow);
        mSec.AddAccessRule(rule);

        ShowSecurity(mSec);
    }

    private static void ShowSecurity(MutexSecurity security)
    {
        Console.WriteLine("\r\nCurrent access rules:\r\n");

        foreach(MutexAccessRule ar in 
            security.GetAccessRules(true, true, typeof(NTAccount)))
        {
            Console.WriteLine("        User: {0}", ar.IdentityReference);
            Console.WriteLine("        Type: {0}", ar.AccessControlType);
            Console.WriteLine("      Rights: {0}", ar.MutexRights);
            Console.WriteLine();
        }
    }
}

/*This code example produces output similar to following:

Current access rules:

        User: TestDomain\TestUser
        Type: Deny
      Rights: ChangePermissions

        User: TestDomain\TestUser
        Type: Allow
      Rights: Modify, Synchronize


Current access rules:

        User: TestDomain\TestUser
        Type: Deny
      Rights: ChangePermissions

        User: TestDomain\TestUser
        Type: Allow
      Rights: Modify, ReadPermissions, Synchronize
 */

.NET Framework

.NET Framework Client Profile

Windows 7, Windows Vista SP1 oder höher, Windows XP SP3, Windows XP SP2 x64 Edition, Windows Server 2008 (Server Core wird nicht unterstützt), Windows Server 2008 R2 (Server Core wird mit SP1 oder höher unterstützt), Windows Server 2003 SP2

Referenz