SUID (Set User ID), SGID (Set Group ID) und Sticky Bits sind spezielle Berechtigungen unter Linux, die auf ausführbare Dateien und Verzeichnisse angewendet werden können. Sie bieten erweiterte Möglichkeiten, bringen aber auch potenzielle Risiken mit sich. Wir beleuchten hier die Vorteile und Fallstricke dieser Berechtigungen.
Verbreitete Verwendung
Die Integration von Sicherheitsmechanismen in ein Mehrbenutzerbetriebssystem ist komplex. Ein grundlegendes Konzept, wie Passwörter, verdeutlicht dies. Passwörter müssen sicher gespeichert werden, damit das System bei jeder Anmeldung prüfen kann, ob das eingegebene Passwort mit dem gespeicherten übereinstimmt. Da Passwörter entscheidende Schlüssel sind, müssen sie geschützt werden.
Unter Linux werden gespeicherte Passwörter auf zweifache Weise geschützt: Sie werden verschlüsselt und der Zugriff auf die Datei, in der sie gespeichert sind, ist auf Benutzer mit Root-Rechten beschränkt. Dies führt zu einem Problem: Wenn nur Root-Benutzer auf die Passwortdatei zugreifen können, wie können normale Benutzer ihre Passwörter ändern?
Erhöhung der Berechtigungsstufe
In der Regel werden Programme unter Linux mit den gleichen Berechtigungen ausgeführt wie der Benutzer, der das Programm startet. Wenn der Root-Benutzer den Befehl `passwd` ausführt, um ein Passwort zu ändern, geschieht dies mit Root-Rechten. Das bedeutet, dass der `passwd`-Befehl uneingeschränkt auf die Passwörter in der Datei `/etc/shadow` zugreifen kann.
Ideal wäre ein System, bei dem jeder Benutzer das Programm `passwd` starten kann, dieses Programm aber weiterhin die erhöhten Rechte des Root-Benutzers besitzt. Dadurch könnte jeder Benutzer sein eigenes Passwort ändern.
Genau das ermöglicht das SUID-Bit (Set User ID). Es bewirkt, dass Programme und Befehle mit den Rechten des Dateibesitzers und nicht mit den Rechten des ausführenden Benutzers ausgeführt werden.
Die Erweiterung der Programmrechte
Es gibt jedoch noch eine weitere Herausforderung: Der Benutzer muss daran gehindert werden, sich in die Passwörter anderer einzumischen. Linux nutzt das SUID-System, um Anwendungen temporär erhöhte Berechtigungen zu geben – aber das ist nur ein Teil der Sicherheitsgeschichte.
Der Mechanismus, der verhindert, dass Benutzer das Passwort anderer ändern, ist im `passwd`-Programm selbst implementiert, nicht im Betriebssystem oder dem SUID-System.
Programme, die mit erhöhten Rechten ausgeführt werden, können zu Sicherheitsrisiken führen, wenn sie nicht unter dem Gesichtspunkt „Sicherheit durch Design“ entwickelt wurden. Das bedeutet, dass die Sicherheit oberste Priorität haben sollte. Es ist keine gute Idee, ein Programm zu entwickeln und dann nachträglich zu versuchen, es abzusichern.
Der größte Vorteil von Open-Source-Software ist, dass Sie den Quellcode selbst überprüfen oder auf vertrauenswürdige Peer-Reviews zurückgreifen können. Im Quellcode des `passwd`-Programms finden Sie Prüfungen, die feststellen, ob der ausführende Benutzer der Root-Benutzer ist. Bestimmte Aktionen sind nur erlaubt, wenn der Benutzer Root-Rechte besitzt (oder `sudo` verwendet).
Hier ist der Code, der überprüft, ob ein Benutzer Root-Rechte hat.
Das folgende Beispiel zeigt, wie dies berücksichtigt wird. Da der Root-Benutzer jedes Passwort ändern kann, muss das Programm nicht die gleichen Prüfungen durchführen, um festzustellen, welche Passwörter der Benutzer ändern darf. Für den Root-Benutzer werden diese Prüfungen übersprungen und die Prüffunktion beendet.
Bei den grundlegenden Linux-Befehlen und -Dienstprogrammen können Sie davon ausgehen, dass sie mit Blick auf die Sicherheit entwickelt wurden und der Code wiederholt geprüft wurde. Natürlich gibt es immer noch das Risiko unbekannter Sicherheitslücken. Es gibt jedoch in der Regel schnell Patches und Updates, um neue Schwachstellen zu beheben.
Software von Drittanbietern, insbesondere wenn sie nicht Open Source ist, sollte sehr vorsichtig mit SUID verwendet werden. Das bedeutet nicht, dass Sie es nicht tun sollten, aber Sie sollten sicherstellen, dass Ihr System keinen Risiken ausgesetzt wird. Es ist nicht ratsam, die Rechte eines Programms zu erhöhen, das sich und den ausführenden Benutzer nicht korrekt verwaltet.
Linux-Befehle mit SUID
Hier sind einige Linux-Befehle, die das SUID-Bit verwenden, um dem Befehl erweiterte Rechte zu verleihen, wenn er von einem normalen Benutzer ausgeführt wird:
ls -l /bin/su
ls -l /bin/ping
ls -l /bin/mount
ls -l /bin/umount
ls -l /usr/bin/passwd
Die rot markierten Dateinamen zeigen an, dass das SUID-Bit gesetzt ist.
Die Berechtigungen für eine Datei oder ein Verzeichnis werden normalerweise durch drei Gruppen von drei Zeichen dargestellt: `rwx`. Diese stehen für Lesen, Schreiben und Ausführen. Wenn der Buchstabe vorhanden ist, ist diese Berechtigung erteilt. Wenn ein Bindestrich (-) anstelle des Buchstabens vorhanden ist, wurde diese Berechtigung nicht erteilt.
Es gibt drei Gruppen dieser Berechtigungen (von links nach rechts): die für den Dateibesitzer, für Mitglieder der Dateigruppe und für andere. Wenn das SUID-Bit für eine Datei gesetzt ist, steht ein „s“ für die Ausführungsberechtigung des Eigentümers.
Wenn das SUID-Bit für eine Datei gesetzt ist, die keine Ausführungsrechte besitzt, wird dies durch ein großes „S“ angezeigt.
Ein Beispiel: Der normale Benutzer `dave` gibt den Befehl `passwd` ein:
passwd
Der Befehl `passwd` fordert `dave` auf, ein neues Passwort einzugeben. Wir können den Befehl `ps` verwenden um Details zu laufenden Prozessen anzuzeigen.
Wir verwenden `ps` mit `grep` in einem anderen Terminalfenster und suchen nach dem `passwd`-Prozess. Wir verwenden `ps` auch mit den Optionen `-e` (jeder Prozess) und `-f` (Vollformat).
Wir geben den folgenden Befehl ein:
ps -e -f | grep passwd
Es werden zwei Zeilen ausgegeben, wobei die zweite Zeile den `grep`-Prozess darstellt, der nach Befehlen mit der Zeichenkette „passwd“ sucht. Die erste Zeile ist jedoch die, die uns interessiert, da sie den `passwd`-Prozess darstellt, der von `dave` gestartet wurde.
Wir können sehen, dass der `passwd`-Prozess so läuft, als wäre er vom Root-Benutzer gestartet worden.
Setzen des SUID-Bits
Das SUID-Bit kann einfach mit `chmod` geändert werden. Der symbolische Modus `u+s` setzt das SUID-Bit, während `u-s` es löscht.
Um einige der Konzepte des SUID-Bits zu verdeutlichen, haben wir ein kleines Programm namens `htg` erstellt. Es befindet sich im Home-Verzeichnis des Benutzers `dave`, und das SUID-Bit ist nicht gesetzt. Wenn es ausgeführt wird, werden die realen und effektiven Benutzer-IDs (UID) angezeigt.
Die reale UID gehört dem Benutzer, der das Programm gestartet hat. Die effektive ID ist das Konto, mit dem sich das Programm verhält, als wäre es gestartet worden.
Wir geben Folgendes ein:
ls -lh htg
./htg
Wenn wir die lokale Kopie des Programms ausführen, sehen wir, dass sowohl die reale als auch die effektive ID auf `dave` gesetzt sind. Es verhält sich also wie ein normales Programm.
Wir kopieren es in das Verzeichnis `/usr/local/bin`, damit andere es verwenden können.
Wir geben Folgendes ein, verwenden `chmod`, um das SUID-Bit zu setzen, und prüfen dann, ob es gesetzt wurde:
sudo cp htg /usr/local/bin
sudo chmod u+s /usr/local/bin/htg
ls -hl /usr/local/bin/htg
Das Programm wird also kopiert und das SUID-Bit wird gesetzt. Wir führen es wieder aus, aber diesmal die Kopie im Ordner `/usr/local/bin`:
htg
Obwohl `dave` das Programm gestartet hat, wird die effektive ID auf den Root-Benutzer gesetzt. Wenn `mary` das Programm startet, geschieht das Gleiche, wie unten gezeigt:
htg
Die reale ID ist `mary` und die effektive ID ist `root`. Das Programm wird mit den Berechtigungen des Root-Benutzers ausgeführt.
Das SGID-Bit
Das SGID (Set Group ID)-Bit ist dem SUID-Bit sehr ähnlich. Wenn das SGID-Bit in einer ausführbaren Datei gesetzt ist, wird die effektive Gruppe auf die Gruppe der Datei gesetzt. Der Prozess wird mit den Berechtigungen der Mitglieder der Dateigruppe ausgeführt, nicht mit den Berechtigungen des ausführenden Benutzers.
Wir haben unser `htg`-Programm optimiert, um auch die effektive Gruppe anzuzeigen. Wir ändern die Gruppe des `htg`-Programms in die Standardgruppe des Benutzers `mary`, `mary`. Wir verwenden auch die symbolischen Modi `u-s` und `g+s` mit `chown`, um das SUID-Bit zu entfernen und das SGID zu setzen.
Dazu geben wir Folgendes ein:
sudo chown root:mary /usr/local/bin/htg
sudo chmod u-s,g+s /usr/local/bin/htg
ls -lh /usr/local/bin/htg
Sie können das SGID-Bit, das durch das `s` gekennzeichnet ist, in den Gruppenberechtigungen sehen. Beachten Sie auch, dass die Gruppe auf `mary` gesetzt ist und der Dateiname jetzt gelb markiert ist.
Bevor wir das Programm ausführen, prüfen wir, zu welchen Gruppen `dave` und `mary` gehören. Wir verwenden den Befehl `id` mit der Option `-G` (Gruppen), um alle Gruppen-IDs auszugeben. Dann führen wir das `htg`-Programm als `dave` aus.
Wir geben die folgenden Befehle ein:
id -G dave
id -G mary
htg
Die ID der Standardgruppe für `mary` ist `1001` und die effektive Gruppe des `htg`-Programms ist `1001`. Obwohl es von `dave` gestartet wurde, läuft es mit den Berechtigungen der Mitglieder der Gruppe `mary`. Es ist so, als ob `dave` der Gruppe `mary` beigetreten wäre.
Wenden wir das SGID-Bit auf ein Verzeichnis an. Zuerst erstellen wir ein Verzeichnis namens `work` und ändern dann seine Gruppe in `geek`. Dann setzen wir das SGID-Bit im Verzeichnis.
Wenn wir `ls` verwenden, um die Einstellungen des Verzeichnisses zu überprüfen, verwenden wir auch die Option `-d` (Verzeichnis), damit wir die Details des Verzeichnisses sehen und nicht dessen Inhalt.
Wir geben die folgenden Befehle ein:
sudo mkdir work
sudo chown dave:geek work
sudo chmod g+s work
ls -lh -d work
Das SGID-Bit und die Gruppe `Geek` werden gesetzt. Diese wirken sich auf alle Elemente aus, die innerhalb des Arbeitsverzeichnisses erstellt werden.
Wir geben Folgendes ein, um in das Arbeitsverzeichnis zu wechseln, ein Verzeichnis namens `demo` zu erstellen und seine Eigenschaften zu überprüfen:
cd work
mkdir demo
ls -lh -d demo
Das SGID-Bit und die Gruppe `Geek` werden automatisch auf das Verzeichnis `demo` angewendet.
Geben wir Folgendes ein, um eine Datei mit dem Befehl `touch` zu erstellen und ihre Eigenschaften zu überprüfen:
touch useful.sh
ls -lh useful.sh
Die Gruppe der neuen Datei wird automatisch auf `Geek` gesetzt.
Das Sticky Bit
Der Sticky Bit hat seinen Namen von seinem historischen Zweck. Wenn er für eine ausführbare Datei festgelegt ist, signalisiert er dem Betriebssystem, dass die Textteile der ausführbaren Datei im Swap gespeichert werden sollen, um die Wiederverwendung zu beschleunigen. Unter Linux wirkt sich das Sticky Bit nur auf ein Verzeichnis aus – das Setzen auf eine Datei ist nicht sinnvoll.
Wenn Sie das Sticky Bit für ein Verzeichnis festlegen, können Benutzer innerhalb dieses Verzeichnisses nur Dateien löschen, die ihnen gehören. Sie können keine Dateien löschen, die einem anderen Benutzer gehören, unabhängig davon, welche Kombination von Dateiberechtigungen für die Dateien festgelegt ist.
Auf diese Weise können Sie ein Verzeichnis erstellen, das jeder – und die von ihm gestarteten Prozesse – als gemeinsam genutzten Speicherort für Dateien nutzen kann. Die Dateien sind geschützt, da niemand die Dateien anderer Personen löschen kann.
Wir erstellen ein Verzeichnis namens `shared`. Wir verwenden den symbolischen Modus `o+t` mit `chmod`, um das Sticky Bit in diesem Verzeichnis zu setzen. Dann sehen wir uns die Berechtigungen für dieses Verzeichnis sowie die Verzeichnisse `/tmp` und `/var/tmp` an.
Wir geben die folgenden Befehle ein:
mkdir shared
sudo chmod o+t shared
ls -lh -d shared
ls -lh -d /tmp
ls -lh -d /var/tmp
Wenn das Sticky Bit gesetzt ist, wird das Ausführungsbit des Satzes von Dateiberechtigungen „andere“ auf `t` gesetzt. Der Dateiname wird ebenfalls blau hervorgehoben.
Die Ordner `/tmp` und `/var/tmp` sind zwei Beispiele für Verzeichnisse, in denen alle Dateiberechtigungen für Besitzer, Gruppe und andere gesetzt sind (deshalb sind sie grün hervorgehoben). Sie dienen als gemeinsame Orte für temporäre Dateien.
Mit diesen Berechtigungen sollte theoretisch jeder alles tun können. Das Sticky Bit überschreibt dies jedoch, und niemand kann eine Datei löschen, die ihm nicht gehört.
Wichtige Punkte
Hier ist eine kurze Checkliste der oben besprochenen Punkte, auf die Sie später zurückgreifen können:
- SUID funktioniert nur bei Dateien.
- Sie können SGID auf Verzeichnisse und Dateien anwenden.
- Sie können das Sticky Bit nur auf Verzeichnisse anwenden.
- Wenn die Zeichen `s`, `g` oder `t` in Großbuchstaben erscheinen, wurde das Ausführungsbit (`x`) nicht gesetzt.