Alle Macht dem User

Eine der großen Sünden an einem Unix ist das Arbeiten als "User root". Dies mag zwar gerade für Ein- und Umsteiger verlockend und bequem sein, ist aber auch ebenso bedenklich wie leichtsinnig.

Was ist so besonders an Root?

Der Root-Account, häufig auch "Superuser" genannt, ist unter Unix-Systemen ein besonders privilegisierter Pseudo-Account mit der UID 0 für systemadministrative Aufgaben. Diesem Nutzer ist quasi alles erlaubt und so gut wie alle Sicherheitsschutzmechanismen sind bedeutungslos für ihn. Die Allmächtigkeit des Nutzers root ist eine der größen Sicherheitsprobleme eines Unix-Systems. Für das System ist nicht der Name ("root"), sondern die User ID des Benutzers ausschlaggebend. Aus diesem Grund verbannt eine Umbenennung des Root-Accounts oder das Anlegen eines weiteren Nutzers mit der UID 0 nicht die Gefahren im Umgang mit Root-Rechten.

Der Root-Account wurde nicht als normaler Benutzeraccount für die gewöhnliche Systembenutzung entworfen. Er ist daher nicht der persönliche Account des Systemverwalters, sondern dient lediglich aufgrund seiner Beschaffenheit zur Erledigung bestimmter systemadministrativer Aufgaben.

Selbstschutz

Wer hat nicht einmal eine Datei gelöscht die besser nicht gelöscht worden wäre? Und falls nun jemand "Hier!" schreit - es ist wohl nur eine Frage der Zeit, bis dies doch einmal passiert. Die Userrechte schützen z.B. die systemweiten Konfigurationsdateien vor unberechtigten Userzugriffen, nicht aber vor einem verunglückten Tastendruck als "root". Ein User kann bei einem sauber aufgesetzten System maximal die Daten seines Homeverzeichnisses löschen, "root" hingegen neben den eigenen Dateien auch noch die persönlichen Daten aller anderen User - oder auch die gesamte System-Installation.

Virenschutz

Noch gibt es keine ernstzunehmenden Computerviren, die einem Unix schaden könnten - es müssen eben erst Rootrechte erlangt werden, um systemweite Manipulationen vornehmen zu können. Ändert sich nun das Userverhalten und der "User root" werkelt ständig, so haben einfachste Skripte - wie bereits in Unix-Newsgroups gepostet - ein leichtes Spiel.
Ebenso dramatisch wie ein Virus kann auch fehlerhafte Software sein - der Test eines Dateimanagers im Alpha- oder Betastadium als "root" kann leicht den gesamten Datenbestand kosten.

Wann User, wann "root"?

Aus genannten Gründen ist es daher langfristig sehr wichtig nicht als "root" zu arbeiten - hierzu dient der Useraccount, auf dem die tägliche Arbeit verrichtet wird. Der Rootaccount dient ausschließlich der Administration. Selbst ein Systemadministrator loggt sich bei einer X-Session (grafische Oberfläche) als User ein - dieser Zugang wird dann entsprechend eingerichtet, so dass er sein System von dort aus administrieren kann.

su

An der Eingabeaufforderung (Konsole oder xterm) kann mittels "su -" zu "root" gewechselt werden. Hier kann nun textbasiert als "User root" gelöscht, verschoben, editiert etc. werden - ein eventuell verwendetes xterm gehört aber nach wie vor dem User.

Beispiel:

wk@planet:~$ su -c "tail -f /var/log/messages"
Password:
[...]
Sep 15 15:40:03 planet -- MARK --
[...]

Zugriff auf den X-Server

Wer nun versucht ein X-Programm zu starten wird bitter enttäuscht werden, denn auch "root" darf nicht ohne weiteres einen fremden X-Server als Ausgabemedium missbrauchen - dies muss zuvor der User gestatten. Die eigenen "Schlüssel" hierzu liegen in der Datei "~/.Xauthority", und können über "xauth list" eingesehen werden. Will nun ein anderer User (in diesem Fall "root") auf unseren X-Server zugreifen, so benötigt er einen passenden Schlüssel: Diesen kann der User mit dem Befehl "xauth extract schluessel $DISPLAY" in einer Datei (in diesem Beispiel "schluessel") abspeichern, und "root" mit dem Befehl "xauth merge schluessel" dauerhaft seiner "~/.Xauthority" hinzufügen.

Doch noch immer kann kein X-Programm gestartet werden, denn diesem muss erst noch mitgeteilt werden, welches Display verwendet werden soll. Hierfür sorgt die Shellvariable "DISPLAY" (vgl. "man X"), die "root" noch setzen muss (z.B. durch die Eingabe von "DISPLAY=:0.0; export DISPLAY"). Ein Beispiel, bei dem der Dateimanager "X-Files" mit Rootrechten in einer User-X-Session genutzt werden soll:

jo@planet ~> xauth extract xauth_jo $DISPLAY
jo@planet ~> su -
Password:
root@planet:~> xauth merge /home/jo/xauth_jo
xauth: creating new authority file /root/.Xauthority
root@planet:~> DISPLAY=:0.0; export DISPLAY
root@planet:~> X-Files
Starting X-Files...

Will man diese Einstellungen nicht jedesmal neu vornehmen sondern automatisch setzen lassen, so bietet sich für die Shellvariable $DISPLAY des "Users root" die Datei "/root/.bashrc" an (sofern die Bash verwendet wird). Der Schlüssel selber bleibt für künftige Sitzungen erhalten.
Da "root" jedoch die Daten des Users lesen kann, ist in diesem Fall ein auslesen, transportieren und einfügen des Schlüssels nicht erforderlich - so ist es möglich, statt dem Ex- und Importieren einfach die gesamte Datei "~/.Xauthority" des Users zu übernehmen. Beispiel:

jo@planet ~> su -
Password:
root@planet:~> cp /home/jo/.Xauthority /root/
root@planet:~> DISPLAY=:0.0; export DISPLAY
root@planet:~> X-Files
Starting X-Files...

Weniger dramatisch als das Kopieren oder Importieren fremder Zugangsdaten ist das Setzen der Umgebungsvariablen "XAUTHORITY", die "root" einfach auf die ".Xauthority" des Users zeigen lassen kann. Allerdings muss bei dieser Methode die Variable bei jedem Wechsel zum Rootaccount erneut gesetzt werden (vgl. $DISPLAY):

jo@planet ~> su -
Password:
root@planet:~> XAUTHORITY=/home/jo/.Xauthority; export XAUTHORITY
root@planet:~> DISPLAY=:0.0; export DISPLAY
root@planet:~> X-Files
Starting X-Files...

ssh

Eine weitere Möglichkeit grafische Programme mit Rootrechten auf dem Userdisplay erscheinen zu lassen bietet das Programm "ssh" - ein "remote login program", das bei entsprechender Konfiguration auch X-Connections unterstützt:

jo@planet ~> ssh -X root@localhost
root@localhost's password:
[ ... ]
root@planet:~> X-Files
Starting X-Files...

Eventuell muss hierfür noch in der lokalen ssh-Serverkonfiguration der Eintrag "X11Forwarding" auf "yes" gesetzt werden.

sudo

Wem es nun zu umständlich ist, sich nach dem Einloggen als User nochmals als "root" anzumelden, dem hilft das Tool "sudo". Hiermit kann man beliebige Befehle oder Programme bestimmten Usern zur Verwendung freigeben. Konfiguriert wird sudo unbedingt mit dem Wrapper "visudo", der einen per Default mit dem Texteditor "vi" konfrontiert. Gibt man hier eine Zeile wie

jo ALL=NOPASSWD:/usr/local/sbin/fetchnews

ein, so erlaubt das dem User "jo" "/usr/local/sbin/fetchnews" ohne Passworteingabe zu starten - er muss es nur über "sudo /usr/local/sbin/fetchnews" aufrufen. Für den Start von X-Programmen gilt aber auch hier das zu "su" beschriebene - "root" muss wissen, dass ein zuvor freigegebenes Display verwendet werden soll (xauth & $DISPLAY).

Wer seine Shell freigibt (diese aber bitte nur *mit* Passworteingabe freigeben), kann mittels sudo komfortabel eine Rootshell herbeirufen, bei der alle Einstellungen des Users erhalten bleiben. Auch muss - wie bei ssh - kein Zugriff auf den X-Server mehr konfiguriert werden. Hierzu dient bei sudo die Option "-s" ("sudo -s"):

jo@planet ~> sudo -s
[ ... ]
password:
root@planet ~> X-Files
Starting X-Files...

super

Ähnlich wie "sudo" ist das Tool "super": Findet sich in dessen Konfigurationsdatei "/etc/super.tab" eine Zeile wie

fnews /usr/local/sbin/fetchnews jo,joe

so können die User "jo" und "joe" das Programm "fetchnews" ohne Passworteingabe starten - aufzurufen über "super fnews" (vgl. "man 5 super"). Ein alleiniger Aufruf von "super" listet dem User alle ihm über "super" genehmigten Programme auf.

Und wem "super Programmname" bzw. "sudo Programmname" noch immer zu umständlich ist, der legt sich z.B. ein Alias "fetchnews" für "sudo fetchnews" bzw. "super fnews" an.

Eintrag ins Startmenü

Bislang sind mehrere Eingaben in einer Shell notwendig, um ein grafisches Programm mit Rootrechten auf dem Userdesktop zu platzieren - zu viel für einen Menüeintrag. Aber auch hier kann man sich leicht helfen: Man kann einen kleinen Wrapper schreiben, in dem vor dem eigentlichen Programmstart sowohl $XAUTHORITY als auch $DISPLAY gesetzt werden - gibt man dieses Skript nun über "super" (oder "sudo") zur Verwendung ohne Passwortabfrage frei, so geht das mit einem einfachen Befehl. Beispiel für einen solchen Wrapper:

#!/bin/sh
XAUTHORITY=/home/username/.Xauthority; export XAUTHORITY
DISPLAY=:0.0; export DISPLAY
programm

Ein solches Skript abgespeichert unter

-rwxr-x--- root root /usr/local/sbin/dateiname

und aufgerufen über "sudo /usr/local/sbin/dateiname" startet das gewünschte Programm mit Rootrechten und ohne Passwortabfrage auf dem Userdesktop. Und da spätestens jetzt hinsichtlich Bedienung und Komfort kein Unterschied mehr zwischen User und "root" besteht - warum weiterhin noch die Risiken des Rootaccounts in Kauf nehmen?

Frontends, Wrapper und Tools

Mit "kdesu" (KDE-Tool) und "xsu" (GTK/GNOME-Anwendung) existieren grafische Tools, die neben dem Userwechsel auch den Zugriff auf den X-Server regeln.

Auch ist es mit einem kleinen Shellscript möglich, einen Wrapper um "su" zu schreiben, der den Zugriff auf den X-Server regelt. Beispiel:

#!/bin/sh
if [ $# -lt 2 ]
then echo "usage: `basename $0` clientuser command" >&2
  exit 2
fi
CLIENTUSER="$1"; shift
exec su - "$CLIENTUSER" -c "xauth add `xauth list \"$DISPLAY\"`; \
  exec env DISPLAY='$DISPLAY' "'"$SHELL"'" -c '$*'"

Ein weiteres Tool mit gleicher Funktionalität ist das von der SuSE-Distribution bekannte Tool "sux", das im WWW frei unter http://fgouget.free.fr/sux/ erhätlich ist.

weitere Informationen

Zum Thema Sicherheit mit Hinweisen auf den Umgang mit dem Rootaccount gibt es ein "Security-HOWTO", welches die lokale Festplatte in den Tiefen des Verzeichnisses "/usr/share/doc" bereithalten sollte. Aktuelle Versionen können über folgende Adressen bezogen werden:

• http://scrye.com/~kevin/lsh/
• ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/Security-HOWTO

Weiterer Artikel zum vernünftigen Umgang mit dem Rootaccount:

• Root und Sicherheit, Einloggen übers Netz

Wer mehr über den (Fremd-)Zugriff auf den X-Server erfahren möchte, dem sei das "Remote X Apps mini-HOWTO" empfohlen - dieses ist ebenfalls Bestandteil von "/usr/share/doc", sowie unter folgenden Adressen erhältlich:

• http://www.xs4all.nl/~zweije/xauth.html
• ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO/mini/Remote-X-Apps

Dieser Artikel ist mit einigen Ergänzungen im WWW zu finden unter http://www.theparallax.org/dcoul/user2root/.