Antworten:
Möglicherweise kennen Sie die normalen Lese-, Schreib- und Ausführungsberechtigungen für Dateien unter Unix.
In vielen Anwendungen ist diese Art der Berechtigungsstruktur - z. B. wenn einem bestimmten Benutzer entweder die vollständige Berechtigung zum Lesen einer bestimmten Datei oder überhaupt keine Berechtigung zum Lesen der Datei erteilt wird - zu grob. Aus diesem Grund enthält Unix ein weiteres Berechtigungsbit, das set-user-IDBit. Wenn dieses Bit für eine ausführbare Datei gesetzt ist, erhält dieser Benutzer jedes Mal, wenn ein anderer Benutzer als der Eigentümer die Datei ausführt, alle Lese- / Schreib- / Ausführungsrechte des Eigentümers für den Zugriff auf andere Dateien des Eigentümers!
Geben Sie ein, um das Set-User-ID-Bit für eine Datei festzulegen
chmod u+s filename
Stellen Sie sicher, dass Sie auch die Ausführungsberechtigung group-other festgelegt haben. Es wäre schön, auch eine Lesegenehmigung für eine andere Gruppe zu haben. All dies kann mit der einzigen Anweisung erfolgen
chmod 4755 filename
Es wird auch als gespeicherte UID bezeichnet. Bei einer gestarteten Datei mit einem Set-UID-Bit ist die gespeicherte UID die UID des Eigentümers der Datei. Andernfalls ist die gespeicherte UID die echte UID.
Diese UID wird verwendet, um die Berechtigungen des Prozesses zum Ausführen einer bestimmten Aktion auszuwerten. EUID kann entweder in Real UID oder Superuser UID geändert werden, wenn EUID! = 0 ist. Wenn EUID = 0 ist, kann es in irgendetwas geändert werden.
Ein Beispiel für ein solches Programm ist passwd. Wenn Sie es vollständig auflisten, werden Sie sehen, dass es das Set-UID-Bit hat und der Eigentümer "root" ist. Wenn ein normaler Benutzer, z. B. "mtk", ausgeführt wird passwd, beginnt er mit:
Real-UID = mtk
Effective-UID = mtk
Saved-UID = root
man credentialsist in diesem Fall eine gute Informationsquelle. Siehe auch diese Quest auf SO . Eine historische Erklärung finden Sie in diesem archivierten Beitrag .
Anstatt "set UID" und "effektive UID" als Mechanismus zu bezeichnen, sollte das gesamte Konzept der UIDs so genannt werden. Die Gründe für die Existenz der verschiedenen UIDs sind verschiedene Probleme bei der Trennung von Berechtigungen. Selbst normale (nicht privilegierte) Benutzer müssen manchmal Dinge tun (auf Ressourcen zugreifen), die nur privilegierte Benutzer können. Um dies einfach zu erreichen, können Programme ihre UIDs ändern. Es gibt 3 Arten davon:
echte UID - die UID, die einen Prozess besitzt
Effektive UID - die UID, unter der ein Prozess derzeit ausgeführt wird - bestimmt die tatsächlichen Fähigkeiten des Prozesses zu einem bestimmten Zeitpunkt. Dies pszeigt Ihnen auch das Feld USER.
gespeicherte Set-UID - Platzhalter zum Hin- und Herwechseln zwischen realen und effektiven UIDs
Die Notwendigkeit für die letzte ergibt sich aus der Tatsache, dass reguläre Benutzer nur zwischen diesen drei und nichts anderem wechseln können und ein Setuid-Programm normalerweise irgendwie wissen muss, wer der Benutzer war, der es geladen hat (und die tatsächliche UID sollte seitdem nicht geändert werden das würde noch mehr Chaos verursachen).
Die Expalanation von mtk ist gut.
Das passwdBeispiel ist eine Eskalation von Berechtigungen - passwd wird immer als root ausgeführt, da es Dateien ändern muss, die nur root ändern darf. Aus diesem Grund ist es wichtig, dass die ausführbare Datei passwd nicht zu Pufferüberläufen usw. neigt, sodass ein cleverer normaler Benutzer sie möglicherweise für Zwecke verwenden kann, für die dies nicht vorgesehen ist.
Ein weiterer Grund besteht darin, den Benutzer auf die gleiche Weise zu schützen, wie Sie es möglicherweise tun, suwenn Sie als Root angemeldet sind, um Ihre Berechtigungen für bestimmte Aufgaben zu verringern oder einzuschränken , und nicht zu eskalieren. Wenn ich beispielsweise die Berechtigung habe, einen Daemon-Dienst zu starten, der keinen Zugriff auf meine Inhalte erfordert und über eigene Inhalte verfügt, was alles ist, was er benötigt (z. B. einen Logger), bedeutet das Ausführen von suid, dass er nur Zugriff auf diese Inhalte hat und nicht meins oder sonst jemand.
Beachten Sie, dass es möglich ist, uid programmgesteuert zu setzen, auch wenn das suid-Bit in der ausführbaren Datei nicht gesetzt ist. Dies funktioniert jedoch nicht für die Eskalation. Das heißt, wenn Sie ein normaler Benutzer sind und ein Programm schreiben, das uid irgendwann selbst setzt, kann dieses Programm nicht zu root wechseln. Ich glaube, Apache funktioniert so. Es wird normalerweise von root gestartet und hat einen Prozess, der dann Kinder aufteilt, die die UID zu einem nicht privilegierten Benutzer wechseln (z. B. "httpd"). Diese untergeordneten Prozesse funktionieren auf dem eigentlichen Webserver.