A.5 Das SUID-Bit
Häufig liegt kein zwingender Grund vor, bei einer Anwendung dauerhaft das SUID-Bit zu setzen. Das Sicherheitsrisiko ist dafür einfach zu hoch. Verwendet wird das SUID-Bit z. B., damit der Benutzer sein Passwort in passwd ändern kann. Hätte der User keine root-Rechte, so könnte nur Root das Passwort ändern. Hier ein solches Negativ-Beispiel, wie Sie eine Anwendung mit root-Rechten ausstatten:
$ gcc –o testprogramm testprogramm.c
$ su
Passwort:********
# chown root:root testprogramm
# chmod a+s testprogramm
# exit
SUID (Set User ID) und SGID (Set Group ID) werden durch ein s anstelle eines x bei den Eigentümer- und bei den Gruppenrechten ausgedrückt. Das s-Recht an einer ausführbaren Datei bedeutet, dass der Benutzer, der sie startet, während des Programmlaufes die UID des Dateibesitzers bzw. die GID der Besitzergruppe erhält. Das hängt davon ab, ob das s beim Besitzer oder der Besitzergruppe steht. Im Falle des Programms /bin/passwd wird man z. B. während des Programmlaufs zum Superuser. Wird das SGID-Recht auf ein Verzeichnis gegeben, so hat es eine andere Funktion. In diesem Fall erhalten alle Dateien, die in diesem Verzeichnis erstellt werden, automatisch die gleiche Gruppe, die auch dem Verzeichnis zugeordnet ist.
Aber wie machen das dann Programme wie bspw. KPPP zum Anwählen in das Internet. Es ist praktisch ausgeschlossen, ein Wählprogramm ohne das gesetzte SUID-Bit zu schreiben. Möglich ist es zwar schon, aber die Benutzerfreundlichkeit, gerade für Anfänger, würde damit nicht gerade erleichtert. Entnommen aus der Dokumentation von KDE, geht KPPP folgendermaßen vor:
|
Gleich nach dem Programmstart startet KPPP einen neuen Prozess. |
|
|
Der Masterprozess (Elternprozess) (der das GUI, Benutzerinteraktion u. Ä. verwaltet) legt den SUID-Status danach ab und läuft dann mit den normalen Benutzerprivilegien (und kann diese auch nicht wiedererlangen). |
|
|
Der Slaveprozess (Kindprozess) behält seine Privilegien bei und kümmert sich um alles, wofür man root-Rechte benötigt. Um diesen Teil sicher zu machen, werden hier keine Funktionen der Qt-Bibliotheken aufgerufen, sondern nur einfache Funktionen der C-Bibliothek. Der Quellcode für diesen Prozess ist kurz (etwa 500 Zeilen) und gut dokumentiert. Dadurch ist es einfach, Sicherheitslöcher zu entdecken. |
|
|
Master- und Slaveprozess kommunizieren über die Standard-IPC-Mechanismen. |
Wenn Sie also eine Anwendung erstellen, welche unbedingt SUID-Rechte benötigt, ist ein Studium des Quellcodes des KPPP zu empfehlen. Leider ist es nicht möglich, diese 500 Zeilen (aufgrund des Umfangs) hier abzudrucken.
Einen Überblick zu den Programmen, die das SUID- oder SGID-Bit gesetzt haben, können Sie (als root) in der Shell mit folgendem Aufruf erhalten:
# find / -perm +6000
Sie können jetzt ggf. die Programme, die Sie nicht mehr benötigen, entfernen, wobei dies schon tiefergreifende Kenntnisse voraussetzt, da das eine oder andere Kommando von einem anderen Kommando verwendet werden könnte. Aber auch das lässt sich relativ einfach ermitteln (hier anhand von ping):
# rpm -qf /bin/ping
iputils-ss020927–45
# rpm -q --whatrequires iputils-ss020927–45
kein Paket verlangt iputils-ss020927–45
#
Bezüglich der Abhängigkeit der Pakete untereinander lässt sich keine pauschale Beurteilung abgeben. Hier ist entweder das Lesen der Manual-Page oder Experimentierfreudigkeit angesagt. Im Falle wo Sie paranoid ggf. SUID sind, jedoch die Anwendung nicht entfernen wollen, nehmen Sie Ihr das SUID-Bit weg.
Sofern es sich also nicht vermeiden lässt, dass Sie ein Programm mit root-Rechten ausstatten müssen, sollten Sie diese Privilegien, sofern diese nicht mehr benötigt werden, mit dem Funktionsaufruf
setuid( getuid() );
wieder abgeben.
|
