Spezialberechtigungen verstehen und anwenden (SUID, SGID, Sticky Bit)
In diesem Schritt werden Sie die Spezialberechtigungen in Linux untersuchen: SUID (Set User ID), SGID (Set Group ID) und das Sticky Bit. Diese Berechtigungen bieten eine erweiterte Kontrolle über die Dateiausführung und das Verzeichnisverhalten.
Spezialberechtigungen werden durch eine zusätzliche Ziffer im oktalen Berechtigungsmodus dargestellt, die vor den Standard-drei Ziffern (Eigentümer, Gruppe, Andere) platziert wird.
- 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 Dateieigentümers ausgeführt, nicht mit denen des Benutzers, der sie ausgeführt hat. Dies wird häufig für Programme verwendet, die erhöhte Privilegien benötigen, um bestimmte Aufgaben auszuführen, wie z. B. der Befehl
passwd (der in /etc/shadow schreiben muss, einer Datei, die root gehört).
- In der
ls -l Ausgabe: Ein s erscheint anstelle der x (Ausführen)-Berechtigung des Eigentümers. Wenn der Eigentümer keine Ausführungsberechtigung hat, erscheint ein Großbuchstabe S.
- SGID (Set Group ID):
- Oktalwert: 2
- Auswirkung auf Dateien: Ähnlich wie SUID, aber die ausführbare Datei wird mit den Berechtigungen des Gruppeneigentümers der Datei ausgeführt.
- Auswirkung auf Verzeichnisse: Dateien und Unterverzeichnisse, die in einem SGID-fähigen Verzeichnis erstellt werden, erben die Gruppenzugehörigkeit dieses Verzeichnisses, anstatt der primären 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.
- In der
ls -l Ausgabe: Ein s erscheint anstelle der x (Ausführen)-Berechtigung der Gruppe. Wenn die Gruppe keine Ausführungsberechtigung hat, erscheint ein Großbuchstabe S.
- Sticky Bit:
- Oktalwert: 1
- Auswirkung auf Dateien: Keine Auswirkung.
- Auswirkung auf Verzeichnisse: Benutzer können Dateien in dem 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.
- In der
ls -l Ausgabe: Ein t erscheint anstelle der x (Ausführen)-Berechtigung der Anderen. Wenn Andere keine Ausführungsberechtigung haben, erscheint ein Großbuchstabe T.
Lassen Sie uns diese Spezialberechtigungen demonstrieren.
SUID Beispiel
Wir erstellen ein einfaches C-Programm, das versucht, eine eingeschränkte Datei zu lesen.
Erstellen Sie zuerst 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:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main() {
FILE *fp;
char buffer[256];
printf("Attempting to read /home/labex/project/secret_data.txt...\n");
fp = fopen("/home/labex/project/secret_data.txt", "r");
if (fp == NULL) {
perror("Error opening file");
return 1;
}
while (fgets(buffer, sizeof(buffer), fp) != NULL) {
printf("%s", buffer);
}
fclose(fp);
printf("Successfully read file.\n");
return 0;
}
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 die Meldung "Error opening file: Permission denied" sehen, da labex keinen Lesezugriff auf secret_data.txt hat.
Nun wollen wir read_secret root zuordnen und das SUID-Bit setzen.
sudo chown root:root ~/project/read_secret
sudo chmod u+s ~/project/read_secret
Überprüfen Sie die Berechtigungen:
ls -l ~/project/read_secret
Ausgabe:
-rwsr-xr-x 1 root root 17704 Jun 6 01:02 /home/labex/project/read_secret
Beachten Sie das s in der Berechtigung des Eigentümers. Führen Sie nun das Programm erneut als labex aus:
~/project/read_secret
Dieses Mal sollte es die Datei erfolgreich lesen (obwohl sie leer ist, wird kein Inhalt ausgegeben, aber die Meldung "Successfully read file." zeigt den Erfolg an). Dies liegt daran, dass das SUID-Bit das Programm mit den Berechtigungen von root ausführen ließ.
SGID Beispiel (auf Verzeichnis)
Lassen Sie uns ein freigegebenes Verzeichnis und eine neue Gruppe erstellen.
sudo groupadd shared_group
sudo mkdir ~/project/shared_dir
sudo chown labex:shared_group ~/project/shared_dir
sudo chmod 770 ~/project/shared_dir
Setzen Sie nun das SGID-Bit auf shared_dir:
sudo chmod g+s ~/project/shared_dir
Überprüfen Sie die Berechtigungen:
ls -ld ~/project/shared_dir
Ausgabe:
drwxrws--- 2 labex shared_group 6 Jun 6 01:02 /home/labex/project/shared_dir
Beachten Sie das s in der Berechtigung der Gruppe.
Erstellen Sie nun eine Datei in shared_dir:
touch ~/project/shared_dir/new_file.txt
Überprüfen Sie die Eigentümerschaft von new_file.txt:
ls -l ~/project/shared_dir/new_file.txt
Ausgabe:
-rw-r--r-- 1 labex shared_group 0 Jun 6 01:02 /home/labex/project/shared_dir/new_file.txt
Obwohl die primäre Gruppe von labex labex ist, hat new_file.txt die Gruppenzugehörigkeit shared_group von shared_dir aufgrund des SGID-Bits geerbt.
Sticky Bit Beispiel
Das Verzeichnis /tmp ist ein klassisches Beispiel für ein Verzeichnis, in dem das Sticky Bit gesetzt ist. Erstellen wir ein ähnliches Verzeichnis.
sudo mkdir ~/project/public_upload
sudo chmod 1777 ~/project/public_upload
Die 1 in 1777 ist der Oktalwert für das Sticky Bit. 777 gewährt dem Eigentümer, der Gruppe und Anderen volle Berechtigungen.
Überprüfen Sie die Berechtigungen:
ls -ld ~/project/public_upload
Ausgabe:
drwxrwxrwt 2 root root 6 Jun 6 01:02 /home/labex/project/public_upload
Beachten Sie das t in der Berechtigung der Anderen.
Lassen Sie uns nun simulieren, dass ein anderer Benutzer eine Datei in diesem Verzeichnis erstellt. Da wir nur den Benutzer labex haben, erstellen wir eine Datei als labex und versuchen dann, sie zu löschen, nachdem wir ihre Eigentümerschaft auf root geändert haben (was einen anderen Benutzer simuliert).
Erstellen Sie eine Datei als labex:
touch ~/project/public_upload/labex_file.txt
Ändern Sie die Eigentümerschaft auf root:
sudo chown root:root ~/project/public_upload/labex_file.txt
Versuchen Sie nun, labex_file.txt als labex zu löschen:
rm ~/project/public_upload/labex_file.txt
Sie sehen eine Aufforderung, ob Sie die schreibgeschützte Datei entfernen möchten, und nach der Bestätigung mit y erhalten Sie den Fehler "Operation not permitted". Dies liegt daran, dass das Sticky Bit Benutzer daran hindert, Dateien zu löschen, die ihnen nicht gehören, innerhalb dieses Verzeichnisses, obwohl labex Schreibberechtigung für das Verzeichnis public_upload hat. Nur root oder der Eigentümer von labex_file.txt (root in diesem Fall) können es löschen.
Um aufzuräumen, benötigen Sie sudo, um labex_file.txt zu entfernen:
sudo rm ~/project/public_upload/labex_file.txt
Aufräumen
Entfernen Sie die erstellten Dateien und Verzeichnisse sowie den Benutzer/die Gruppe:
sudo rm -f ~/project/secret_data.txt ~/project/read_secret.c ~/project/read_secret
sudo rm -rf ~/project/shared_dir ~/project/public_upload
sudo groupdel shared_group
