In vielen Systemen hat ein Root-Benutzer oder Hauptbenutzer die vollständige Kontrolle über das System. Subsystem für UNIX-basierte Anwendungen (Subsystem for UNIX-based Applications, SUA) erkennt keine Root-Benutzer. Bei der Entwicklung des POSIX-Standards (Portable Operating System Interface) wurde das Konzept des Root-Benutzers als administrative Angelegenheit betrachtet. Anstelle eines Root-Benutzers definiert der POSIX-Standard entsprechende Berechtigungen für einige Vorgänge.

Inhalt dieses Themas

"setuid" und "setgid"

Die Mechanismen setuid und setgid ermöglichen es, das ein ausgeführtes Programm bestimmte Aspekte eines Sicherheitsprinzipals übernehmen kann und nicht die Aspekte des Benutzers, der das Programm ausführt. Damit kann das Programm bei diesen Aspekten zwischen denen des aufrufenden Benutzers und denen eines anderen Sicherheitsprinzipals wechseln.

Die entsprechenden Berechtigungen sind anders. Während die Mechanismen setuid und setgid es einer Anwendung ermöglichen, die Antwort auf folgende Frage zu steuern: "Wer bist du?", wird mithilfe entsprechender Berechtigungen folgende Frage beantwortet: "Was kannst du tun?"

Subsystem für UNIX-basierte Anwendungen und Identitäten

In typischen UNIX-Umgebungen gibt es genau einen Benutzer, dem alle Berechtigungen erteilt werden. Dieser Benutzer, der normalerweise als root bezeichnet wird, hat uid == 0. In Subsystem für UNIX-basierte Anwendungen werden alle unterstützten Berechtigungen in einem bestimmten System den Benutzern erteilt, die Mitglied der Gruppe Administratoren oder der Gruppe Domänenadministratoren für dieses System sind. Sie müssen sich nicht als Administrator anmelden. Jeder Benutzer, der Mitglied der Gruppe Administratoren oder Domänenadministratoren ist, besitzt root-Berechtigungen. Nicht alle in POSIX oder UNIX definierten Berechtigungen stehen in SUA zur Verfügung, d. h., es gibt bestimmte Berechtigungen, die keinem Benutzer erteilt werden.

Entsprechende Berechtigungen werden im Allgemeinen für eine Vielzahl von Aktionen benötigt. Dazu gehören das Zugreifen auf das Dateisystem, das Senden von Signalen an andere Prozesse (Prozesssteuerung) oder das Ändern der gültigen Benutzerkennung (User Identifier, UID) oder Gruppenkennung (Group Identifier, GID) für einen Prozess, um die Möglichkeit für diesen Prozess, bestimmte Aktionen auszuführen, zu ändern.

Gemäß POSIX-Standard besitzt eine Datei Berechtigungen, die Bits zum Festlegen einer UID (setuid) und einer GID (setgid) beinhalten. Wenn für eine Datei eines oder beide Bits festgelegt sind und ein Prozess diese Datei ausführt wird, erhält der Prozess die UID oder GID der Datei. Bei vorsichtiger Verwendung ermöglicht dieser Mechanismus einem Benutzer ohne Administratorberechtigungen das Ausführen von Programmen, die mit höheren Berechtigungen des Besitzers oder der Gruppe der Datei ausgeführt werden. Bei unsachgemäßer Verwendung kann dies jedoch zu Sicherheitsrisiken führen, da Benutzer ohne Berechtigungen Aktionen ausführen können, die nur von einem Administrator ausgeführt werden sollten. Dieser Mechanismus wird deshalb von SUA nicht standardmäßig unterstützt. Wenn Sie stattdessen versuchen, eine Datei entweder mit festgelegtem setuid- oder setgid-Bit auszuführen, wird die Datei vom Subsystem für UNIX-basierte Anwendungen (SUA) nicht ausgeführt, und der Fehlercode ENOSETUID wird zurückgegeben.

Setup-Überlegungen für "setuid" im Subsystem für UNIX-basierte Anwendungen

Wenn Sie auf eine Anwendung angewiesen sind, die das standardmäßige POSIX-Verhalten erfordert, können Sie SUA so konfigurieren, dass Dateien, für die das Bit setuid oder setgid festgelegt ist, ausgeführt werden. Wenn SUA auf diese Weise konfiguriert wurde und eine Datei mit festgelegtem setuid- oder setgid-Bit von einem Prozess ausgeführt wird, werden von SUA lokale Sicherheitstoken für den Prozess generiert. Diese besitzen die Berechtigungen, die dem Besitzer oder der Gruppe der Datei zugewiesen sind. Da die Token lokal sind, werden sie von anderen Computern im Netzwerk nicht erkannt. Auch wenn die Datei einem Mitglied der Gruppe Domänenadministratoren gehört, bedeutet dies also, dass der Prozess nicht über vertrauenswürdigen Zugriff über Microsoft® Windows®-Netzwerke auf andere Computer in der Domäne verfügt. Stattdessen sind die Berechtigungen nur auf dem Computer gültig, auf dem der Prozess ausgeführt wird.

Beispiel: Ein Prozess führt eine Programmdatei mit festgelegtem setuid-Bit aus, deren Besitzer Mitglied der Gruppe Domänenadministratoren ist. Wenn das Programm versucht, das Kennwort eines Domänenbenutzers zu ändern, schlägt dieser Versuch fehl, weil die Sicherheitstoken des Prozesses lokal sind und somit von anderen Systemen in der Domäne nicht erkannt werden. Wenn das Programm andererseits versucht, das Kennwort eines lokalen Benutzers zu ändern, ist dieser Versuch erfolgreich, weil der Besitzer der Datei Mitglied der Gruppe Domänenadministratoren ist, die im Allgemeinen zur Gruppe Administratoren des lokalen Computers gehört. Informationen zum Konfigurieren von SUA zum Ausführen von Dateien mit festgelegtem setuid- oder setgid-Bit finden Sie in den Hilfedateien, die im Downloadpaket "Dienstprogramme und Software Development Kit (SDK) für Subsystem für UNIX-basierte Anwendungen" enthalten sind.

Für die Funktionen setuid(2), setgid(2) und chroot(2) muss ein Prozess die gültige UID besitzen, die dem Systemkonto, dem Administratorkonto für die lokale Domäne oder dem Administratorkonto für die Prinzipaldomäne entspricht. Das lokale Administratorkonto kann die UID oder GID nur auf eine andere ID in derselben Domäne ändern.

Für chown(1), chmod(1) und chgrp(1) muss ein Konto die Windows-Berechtigungen SE_BACKUP und SE_RESTORE besitzen, um make-Vorgänge für Dateien auszuführen, die im Besitz eines anderen Benutzers oder einer anderen Gruppe sind, oder um die Berechtigungen für eine Datei zu ändern, die im Besitz eines anderen Benutzers ist. Diese Berechtigungen gehören im Allgemeinen zu den Konten Administratoren und Sicherungs-Operatoren.

Siehe auch