Verstehen und Anwenden spezieller Berechtigungen (SUID, SGID, Sticky Bit)
In diesem Schritt untersuchen Sie spezielle Berechtigungen in Linux: SUID (Set User ID), SGID (Set Group ID) und das Sticky Bit. Diese Berechtigungen bieten erweiterte Kontrolle über die Dateiausführung und das Verzeichnisverhalten.
Spezielle Berechtigungen werden durch eine zusätzliche Ziffer im Oktal-Berechtigungsmodus dargestellt, die vor den Standard-drei Ziffern (Besitzer, Gruppe, Andere) steht.
- SUID (Set User ID):
- Oktalwert: 4
- Auswirkung auf Dateien: Wenn eine ausführbare Datei mit SUID ausgeführt wird, wird sie mit den Berechtigungen des Dateibesitzers ausgeführt, nicht mit den Berechtigungen des Benutzers, der sie ausgeführt hat. Dies wird häufig für Programme verwendet, die erhöhte Berechtigungen benötigen, um bestimmte Aufgaben auszuführen, wie z. B. den Befehl
passwd (der auf /etc/shadow schreiben muss, eine Datei, die von root besitzt).
- Ausgabe von
ls -l: Ein s erscheint anstelle des x (Ausführen)-Berechtigungszeichens des Besitzers. Wenn der Besitzer keine Ausführungsberechtigung hat, erscheint ein großes S.
- SGID (Set Group ID):
- Oktalwert: 2
- Auswirkung auf Dateien: Ähnlich wie SUID, aber die ausführbare Datei wird mit den Berechtigungen des Gruppenbesitzers der Datei ausgeführt.
- Auswirkung auf Verzeichnisse: Dateien und Unterverzeichnisse, die innerhalb eines SGID-aktivierten Verzeichnisses erstellt werden, erben die Gruppenmitgliedschaft dieses Verzeichnisses und nicht die primäre Gruppe des Benutzers, der sie erstellt hat. Dies ist sehr nützlich für freigegebene Verzeichnisse, in denen alle Dateien zu einer bestimmten Gruppe gehören sollen.
- Ausgabe von
ls -l: Ein s erscheint anstelle des x (Ausführen)-Berechtigungszeichens der Gruppe. Wenn die Gruppe keine Ausführungsberechtigung hat, erscheint ein großes S.
- Sticky Bit:
- Oktalwert: 1
- Auswirkung auf Dateien: Keine Auswirkung.
- Auswirkung auf Verzeichnisse: Benutzer können Dateien im Verzeichnis erstellen, aber sie können nur Dateien löschen oder umbenennen, die ihnen gehören. Dies verhindert, dass Benutzer Dateien anderer Benutzer in einem freigegebenen Verzeichnis (z. B.
/tmp) löschen oder verschieben.
- Ausgabe von
ls -l: Ein t erscheint anstelle des x (Ausführen)-Berechtigungszeichens anderer Benutzer. Wenn andere Benutzer keine Ausführungsberechtigung haben, erscheint ein großes T.
Demonstrieren wir diese speziellen Berechtigungen.
SUID-Beispiel
Wir erstellen ein einfaches C-Programm, das versucht, eine eingeschränkte Datei zu lesen.
Erstellen Sie zunächst eine Datei, die nur root lesen kann:
sudo touch ~/project/secret_data.txt
sudo chmod 600 ~/project/secret_data.txt
sudo chown root:root ~/project/secret_data.txt
Überprüfen Sie die Berechtigungen:
ls -l ~/project/secret_data.txt
Ausgabe:
-rw------- 1 root root 0 Jun 6 17:36 /home/labex/project/secret_data.txt
Erstellen Sie nun ein C-Programm read_secret.c, das versucht, diese Datei zu lesen:
nano ~/project/read_secret.c
Fügen Sie den folgenden Code in read_secret.c ein:
// ... (C-Code)
Speichern und beenden Sie nano (Strg+S, Strg+X).
Kompilieren Sie das Programm:
gcc ~/project/read_secret.c -o ~/project/read_secret
Versuchen Sie nun, es als labex auszuführen:
~/project/read_secret
Sie sollten eine Fehlermeldung "Error opening file: Permission denied" erhalten, da labex keinen Lesezugriff auf secret_data.txt hat.
Machen wir nun read_secret von root besitzen und setzen das SUID-Bit.
// ... (Befehle zum Ändern des Besitzers und Setzen des SUID-Bits)
Überprüfen Sie die Berechtigungen:
// ... (Ausgabe von ls -l)
Beachten Sie das s im Berechtigungsset des Besitzers. Führen Sie das Programm jetzt erneut als labex aus:
// ... (Ausführung des Programms)
Diesmal sollte es die Datei erfolgreich lesen (obwohl sie leer ist, sodass kein Inhalt gedruckt wird, aber die Meldung "Successfully read file." zeigt den Erfolg). Dies liegt daran, dass das SUID-Bit das Programm mit den Berechtigungen von root ausführen ließ.
SGID-Beispiel (auf Verzeichnis)
Erstellen wir ein freigegebenes Verzeichnis und eine neue Gruppe.
// ... (Befehle zum Erstellen der Gruppe und des Verzeichnisses)
Setzen Sie nun das SGID-Bit auf shared_dir:
// ... (Befehl zum Setzen des SGID-Bits)
Überprüfen Sie die Berechtigungen:
// ... (Ausgabe von ls -ld)
Beachten Sie das s im Berechtigungsset der Gruppe.
Erstellen Sie nun eine Datei innerhalb von shared_dir:
// ... (Befehl zum Erstellen der Datei)
Überprüfen Sie die Besitzerverhältnisse von new_file.txt:
// ... (Ausgabe von ls -l)
Obwohl die primäre Gruppe von labex labex ist, hat new_file.txt die Gruppenmitgliedschaft shared_group von shared_dir aufgrund des SGID-Bits geerbt.
Sticky Bit-Beispiel
Das Verzeichnis /tmp ist ein klassisches Beispiel für ein Verzeichnis mit gesetztem Sticky Bit. Erstellen wir ein ähnliches Verzeichnis.
// ... (Befehl zum Erstellen des Verzeichnisses)
Das 1 in 1777 ist der Oktalwert für das Sticky Bit. 777 gewährt volle Berechtigungen an Besitzer, Gruppe und andere.
Überprüfen Sie die Berechtigungen:
// ... (Ausgabe von ls -ld)
Beachten Sie das t im Berechtigungsset anderer Benutzer.
Löschen wir nun die Datei als labex, nachdem wir sie als root erstellt haben (simulieren eines anderen Benutzers).
// ... (Befehle zum Erstellen, Ändern des Besitzers und Löschen der Datei)
Sie erhalten eine Fehlermeldung "Operation not permitted". Dies liegt daran, dass das Sticky Bit verhindert, dass Benutzer Dateien löschen, die ihnen nicht gehören, selbst wenn labex Schreibrechte für das Verzeichnis hat. Nur root oder der Besitzer von labex_file.txt kann sie löschen.
Zum Bereinigen benötigen Sie sudo, um labex_file.txt zu entfernen:
// ... (Befehl zum Löschen der Datei mit sudo)
Bereinigung
Entfernen Sie die erstellten Dateien und Verzeichnisse sowie den Benutzer/die Gruppe:
// ... (Befehle zum Löschen der Dateien und Verzeichnisse)
