setuid - setuid

Die Unix- Zugriffsrechte-Flags setuid und setgid (kurz für "set user ID" und "set group ID") ermöglichen es Benutzern, eine ausführbare Datei mit den Dateisystemberechtigungen des Besitzers bzw. der Gruppe der ausführbaren Datei auszuführen und das Verhalten in Verzeichnissen zu ändern. Sie werden häufig verwendet, um Benutzern eines Computersystems zu ermöglichen, Programme mit vorübergehend erhöhten Rechten auszuführen, um eine bestimmte Aufgabe auszuführen. Die bereitgestellten Berechtigungen für die angenommene Benutzer-ID oder Gruppen-ID sind zwar nicht immer erhöht, aber zumindest spezifisch.

Die Flags setuidund setgidwerden für Aufgaben benötigt, die andere Privilegien erfordern, als dem Benutzer normalerweise gewährt werden, z. B. die Möglichkeit, Systemdateien oder Datenbanken zu ändern, um sein Anmeldekennwort zu ändern. Einige der Aufgaben, die zusätzliche Berechtigungen erfordern, sind jedoch möglicherweise nicht sofort offensichtlich, wie zum Beispiel der pingBefehl, der Steuerpakete auf einer Netzwerkschnittstelle senden und auf diese warten muss .

Auswirkungen

Die Flags setuidund setgidhaben unterschiedliche Auswirkungen, je nachdem, ob sie auf eine Datei, ein Verzeichnis oder eine binäre ausführbare oder nicht binäre ausführbare Datei angewendet werden. Die Flags setuidund setgidwirken sich nur auf ausführbare Binärdateien und nicht auf Skripte (zB Bash, Perl, Python) aus.

Bei Einstellung auf eine ausführbare Datei

Wenn die setuidoder setgid-Attribute für eine ausführbare Datei festgelegt sind, führen alle Benutzer, die die Datei ausführen können, die Datei automatisch mit den Rechten des Dateibesitzers (normalerweise root ) und/oder der Dateigruppe aus, abhängig von den gesetzten Flags. Dies ermöglicht es dem Systemdesigner, die Ausführung von vertrauenswürdigen Programmen zuzulassen, die ein Benutzer ansonsten nicht ausführen dürfte. Diese sind möglicherweise nicht immer offensichtlich. Beispielsweise benötigt der Befehl ping möglicherweise Zugriff auf Netzwerkberechtigungen, auf die ein normaler Benutzer nicht zugreifen kann; Daher kann ihm das setuid-Flag gegeben werden, um sicherzustellen, dass ein Benutzer, der ein anderes System anpingen muss, dies tun kann, selbst wenn sein eigener Account nicht über die erforderliche Berechtigung zum Senden von Paketen verfügt.

Aus Sicherheitsgründen wird der aufrufende Benutzer in der Regel durch das System von einer Änderung das neue Verfahrens in irgendeiner Weise, wie durch die Verwendung verboten ptrace, LD_LIBRARY_PATHoder Senden von Signalen an es, die erhöhte Privilegien zu nutzen, auch wenn Signale vom Terminal noch nicht akzeptiert.

Die Bits setuidund setgidwerden normalerweise mit dem Befehl chmodgesetzt, indem die höherwertige Oktalziffer auf 4 für setuidoder 2 für gesetzt wird setgid. " " setzt die Bits und (4+2=6), wodurch die Datei für den Eigentümer (7) lese-/schreibbar/ausführbar und von der Gruppe (erste 1) und andere (zweite 1) ausführbar ist. Wenn ein anderer Benutzer als der Eigentümer die Datei ausführt, wird der Prozess mit den vom Eigentümer festgelegten Benutzer- und Gruppenberechtigungen ausgeführt. Wenn die Datei beispielsweise im Besitz von Benutzer und Gruppe ist , wird sie unabhängig davon ausgeführt, wer die Datei ausführt. chmod 6711 filesetuidsetgidrootwheelroot:wheel

Die meisten Implementierungen des chmodBefehls unterstützen auch feinkörnigere, symbolische Argumente, um diese Bits zu setzen. Der vorzugsweise feinkörnige Modus wird in der folgenden Demonstration als " chmod ug+s"

Sicherheitsauswirkungen

Obwohl die setuidFunktion in vielen Fällen sehr nützlich ist, kann ihre unsachgemäße Verwendung ein Sicherheitsrisiko darstellen, wenn das setuidAttribut ausführbaren Programmen zugewiesen wird , die nicht sorgfältig entworfen wurden. Aufgrund möglicher Sicherheitsprobleme ignorieren viele Betriebssysteme das setuidAttribut, wenn es auf ausführbare Shell-Skripte angewendet wird .

Das Vorhandensein setuidausführbarer Dateien erklärt, warum der chrootSystemaufruf für Nicht- Root- Benutzer unter Unix nicht verfügbar ist . Weitere Informationen finden Sie unter Einschränkungen vonchroot .

Bei Einstellung auf ein Verzeichnis

Das Festlegen der setgidBerechtigung für ein Verzeichnis (" chmod g+s") bewirkt, dass neue Dateien und darin erstellte Unterverzeichnisse seine Gruppen-ID erben und nicht die primäre Gruppen-ID des Benutzers, der die Datei erstellt hat (die Eigentümer-ID ist nie betroffen, nur die Gruppen-ID). .

  1. Neu erstellte Unterverzeichnisse erben das setgidBit. Dadurch wird ein gemeinsamer Arbeitsbereich für eine Gruppe ermöglicht, ohne dass Gruppenmitglieder ihre aktuelle Gruppe explizit ändern müssen, bevor sie neue Dateien oder Verzeichnisse erstellen.
  2. wirkt sich nur auf die Gruppen-ID neuer Dateien und Unterverzeichnisse aus, die nach dem setgidSetzen des Bits erstellt wurden, und wird nicht auf vorhandene Entitäten angewendet.
  3. wirkt sich nicht auf die Gruppen-ID der Dateien aus, die an anderer Stelle erstellt und in das betreffende Verzeichnis verschoben werden. Die Datei trägt weiterhin die Gruppen-ID, die zum Zeitpunkt und Ort der Erstellung vorgenommen wurde.

Das Setzen des setgidBits auf vorhandene Unterverzeichnisse muss manuell erfolgen, mit einem Befehl wiefind /path/to/directory -type d -exec chmod g+s '{}' \;

Die setuidfür ein Verzeichnis festgelegten Berechtigungen werden auf den meisten UNIX- und Linux- Systemen ignoriert . Allerdings FreeBSD kann konfiguriert werden , zu interpretieren , setuidin einer ähnlichen Weise wie setgid, in welchem Fall es zwingt alle Dateien und Unterverzeichnisse in einem Verzeichnis erstellt von diesem Verzeichnis Eigentümer besessen werden - eine einfache Form der Vererbung. Dies wird im Allgemeinen auf den meisten von BSD abgeleiteten Systemen nicht benötigt , da Verzeichnisse standardmäßig so behandelt werden, als ob ihr setgidBit unabhängig vom tatsächlichen Wert immer gesetzt wäre. Wie in open(2), "Wenn eine neue Datei erstellt wird, wird ihr die Gruppe des Verzeichnisses zugewiesen, die sie enthält."

Beispiele

Berechtigungen prüfen

Berechtigungen einer Datei können in oktaler Form und/oder alphabetischer Form mit dem Kommandozeilen-Tool überprüft werden stat

[ torvalds ~ ] $ stat -c "%a %A" ~/test/
1770 drwxrwx--T

SUID

4701 auf einer ausführbaren Datei im Besitz von 'root' und der Gruppe 'root'

Ein Benutzer namens 'thompson' versucht, die Datei auszuführen. Die ausführbare Berechtigung für alle Benutzer wird gesetzt (die '1'), damit 'thompson' die Datei ausführen kann. Der Dateibesitzer ist 'root' und die SUID-Berechtigung ist gesetzt (die '4') - die Datei wird also als 'root' ausgeführt.

Der Grund, warum eine ausführbare Datei als 'root' ausgeführt wird, besteht darin, dass sie bestimmte Dateien ändern kann, zu denen der Benutzer normalerweise nicht berechtigt wäre, ohne dem Benutzer vollen Root-Zugriff zu gewähren.

Eine Standardverwendung davon kann mit der /usr/bin/passwdBinärdatei gesehen werden. /usr/bin/passwdändern muss /etc/passwdund /etc/shadowdie Kontoinformationen und Passwort-Hashes für alle Benutzer speichern, und diese können nur vom Benutzer 'root' geändert werden.

[ thompson ~ ] $ stat -c "%a %U:%G %n" /usr/bin/passwd
4701 root:root /usr/bin/passwd

[ thompson ~ ] $ passwd
passwd: Changing password for thompson

Der Eigentümer des Prozesses ist nicht der Benutzer, der die ausführbare Datei ausführt, sondern der Eigentümer der ausführbaren Datei

SGID

2770 in einem Verzeichnis namens 'music', das dem Benutzer 'root' und der Gruppe 'engineers' gehört

Ein Benutzer namens 'torvalds', der in erster Linie der Gruppe 'torvalds' aber sekundär der Gruppe 'engineers' angehört, erstellt ein Verzeichnis namens 'electronic' unter dem Verzeichnis namens 'music'. Der Gruppenbesitz des neuen Verzeichnisses namens 'elektronisch' erbt 'Ingenieure'. Dies ist das gleiche, wenn Sie eine neue Datei namens 'imagine.txt' erstellen.

Ohne SGID wäre der Gruppenbesitz des neuen Verzeichnisses/der neuen Datei 'torvalds' gewesen, da dies die primäre Gruppe des Benutzers 'torvalds' ist.

[ torvalds ~ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds ~ ] $ stat -c "%a %U:%G %n" ./music/
2770 root:engineers ./music/

[ torvalds ~ ] $ mkdir ~/music/electronic

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/electronic/
torvalds:engineers ./music/electronic/

[ torvalds ~ ] $ echo 'NEW FILE' > ./music/imagine.txt

[ torvalds ~ ] $ stat -c "%U:%G %n" ./music/imagine.txt
torvalds:engineers ./music/imagine.txt

[ torvalds ~ ] $ touch ~/test

[ torvalds ~ ] $ stat -c "%U:%G %n" ~/test
torvalds:torvalds ~/test

Klebriges Bit

1770 in einem Verzeichnis namens 'videogames', das dem Benutzer 'torvalds' und der Gruppe 'engineers' gehört.

Ein Benutzer namens 'torvalds' erstellt eine Datei namens 'tekken' im Verzeichnis namens 'videogames'. Ein Benutzer namens 'wozniak', der ebenfalls zur Gruppe 'engineers' gehört, versucht, die Datei 'tekken' zu löschen, kann dies jedoch nicht, da er nicht der Eigentümer ist.

Ohne Sticky Bit hätte 'wozniak' die Datei löschen können, denn das Verzeichnis namens 'videogames' erlaubt das Lesen und Schreiben durch 'Ingenieure'. Eine Standardverwendung davon kann im /tmpOrdner eingesehen werden .

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./videogames/
1770  torvalds:engineers  ./videogames/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > videogames/tekken

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak ~/ ] $ cd /home/shared/videogames

[ wozniak /home/shared/videogames/ ] $ rm tekken
rm: cannot remove ‘tekken’: Operation not permitted

Klebebit mit SGID

3171 in einem Verzeichnis namens 'blog' im Besitz der Gruppe 'engineers' und des Benutzers 'root'

Ein Benutzer namens 'torvalds', der in erster Linie der Gruppe 'torvalds' aber sekundär der Gruppe 'engineers' angehört, erstellt eine Datei oder ein Verzeichnis namens 'thoughts' innerhalb des Verzeichnisses 'blog'. Ein Benutzer namens 'wozniak', der auch zur Gruppe 'engineers' gehört, kann die Datei oder das Verzeichnis namens 'thoughts' nicht löschen, umbenennen oder verschieben, da er nicht der Eigentümer ist und das Sticky-Bit gesetzt ist. Wenn 'Gedanken' jedoch eine Datei ist, kann 'wozniak' sie bearbeiten.

Sticky Bit hat die letzte Entscheidung. Wenn Sticky Bit und SGID nicht gesetzt wurden, könnte der Benutzer 'wozniak' die Datei 'thoughts' umbenennen, verschieben oder löschen, da das Verzeichnis mit dem Namen 'blog' das Lesen und Schreiben nach Gruppen erlaubt und wozniak zur Gruppe gehört, und die Standard- Umask 0002 ermöglicht das Bearbeiten neuer Dateien nach Gruppen. Sticky Bit und SGID könnten mit etwas wie einer schreibgeschützten umask oder einem nur anhängenden Attribut kombiniert werden.

[ torvalds /home/shared/ ] $ groups torvalds
torvalds : torvalds engineers

[ torvalds /home/shared/ ] $ stat -c "%a  %U:%G  %n" ./blog/
3171  root:engineers  ./blog/

[ torvalds /home/shared/ ] $ echo 'NEW FILE' > ./blog/thoughts

[ torvalds /home/shared/ ] $ su - wozniak
Password:

[ wozniak ~/ ] $ cd /home/shared/blog

[ wozniak /home/shared/blog/ ] $ groups wozniak
wozniak : wozniak engineers

[ wozniak /home/shared/blog/ ] $ stat -c "%a  %U:%G  %n" ./thoughts
664  torvalds:engineers  ./thoughts

[ wozniak /home/shared/blog/ ] $ rm thoughts
rm: cannot remove ‘thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts /home/wozniak/
mv: cannot move ‘thoughts’ to ‘/home/wozniak/thoughts’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ mv thoughts pondering
mv: cannot move ‘thoughts’ to ‘pondering’: Operation not permitted

[ wozniak /home/shared/blog/ ] $ echo 'REWRITE!' > thoughts

[ wozniak /home/shared/blog/ ] $ cat thoughts
REWRITE!

Sicherheit

Entwickler entwerfen und Programme implementieren , die diesen Bit auf ausführbare Dateien sorgfältig zu vermeiden , um Sicherheitslücken einschließlich verwenden Pufferüberschreitungen und Pfad Injektion . Erfolgreiche Buffer-Overrun-Angriffe auf anfällige Anwendungen ermöglichen es dem Angreifer, beliebigen Code unter den Rechten des ausgenutzten Prozesses auszuführen. Für den Fall, dass ein anfälliger Prozess das setuidBit verwendet, um als ausgeführt zu werden root, wird der Code mit Root-Rechten ausgeführt, was dem Angreifer effektiv Root-Zugriff auf das System gibt, auf dem der anfällige Prozess ausgeführt wird.

Von besonderer Bedeutung bei einem setuidProzess ist die Umgebung des Prozesses. Wenn die Umgebung von einem privilegierten Prozess nicht ordnungsgemäß bereinigt wird, kann ihr Verhalten von dem nicht privilegierten Prozess geändert werden, der sie gestartet hat. Zum Beispiel NYS an einem Punkt einen verletzlich war auszunutzen Verwendung setuidund eine Umgebungsvariable , die nicht vertrauenswürdige Code aus erlaubte die Ausführung gemeinsam benutzte Bibliotheken .

Geschichte

Das setuidGebiss wurde von Dennis Ritchie erfunden und in su. Sein Arbeitgeber, damals Bell Telephone Laboratories , meldete 1972 ein Patent an; das Patent wurde 1979 unter der Patentnummer US 4135240  "Protection of data file content " erteilt . Das Patent wurde später gemeinfrei gemacht .

Siehe auch

Verweise

Externe Links