Alle Macht dem User

von Jo Moskalewski, Version vom 24.01.2001

Eine der grossen Suenden an einem Unix ist das Arbeiten als "User root". Dies mag zwar gerade fuer Ein- und Umsteiger verlockend und bequem sein, ist aber auch ebenso bedenklich wie leichtsinnig.

Selbstschutz

Wer hat nicht einmal eine Datei geloescht die besser nicht geloescht worden waere? Und falls nun jemand "Hier!" schreit - es ist wohl nur eine Frage der Zeit, bis dies doch einmal passiert. Die Userrechte schuetzen z.B. die systemweiten Konfigurationsdateien vor unberechtigten Userzugriffen, nicht aber vor einem verunglueckten Tastendruck als "root". Ein User kann bei einem sauber aufgesetzten System maximal die Daten seines Homeverzeichnisses loeschen, "root" hingegen neben den eigenen Dateien auch noch die persoenlichen Daten aller anderen User - oder auch die gesamte System-Installation.

Wer nicht als "root" eingeloggt ist kann nur geringen Schaden anrichten.

Virenschutz

Noch gibt es keine ernstzunehmenden Computerviren, die einem Unix schaden koennten - es muessen eben erst Rootrechte erlangt werden, um systemweite Manipulationen vornehmen zu koennen. Aendert sich nun das Userverhalten und der "User root" werkelt staendig, 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.

Programme ohne Rootrechte koennen keine systemweiten Schaeden anrichten.

Wann User, wann "root"?

Aus genannten Gruenden ist es daher langfristig sehr wichtig nicht als "root" zu arbeiten - hierzu dient der Useraccount, auf dem die taegliche Arbeit verrichtet wird. Der Rootaccount dient ausschliesslich der Administration. Selbst ein Systemadministrator loggt sich bei einer X-Session (grafische Oberflaeche) als User ein - dieser Zugang wird dann entsprechend eingerichtet, so dass er sein System von dort aus administrieren kann.

Als "root" ist man nur so kurz wie moeglich eingeloggt.

su

An der Eingabeaufforderung (Konsole oder XTerm) kann mittels "su -" zu "root" gewechselt werden. Hier kann nun textbasiert als "User root" geloescht, verschoben, editiert etc. werden - ein eventuell verwendetes XTerm gehoert aber nach wie vor dem User.

Zugriff auf den X-Server

Wer nun versucht ein X-Programm zu starten wird bitter enttaeuscht werden, denn auch "root" darf nicht ohne weiteres einen fremden X-Server als Ausgabemedium missbrauchen - dies muss zuvor der User gestatten. Die eigenen "Schluessel" hierzu liegen in der Datei "~/.Xauthority", und koennen ueber "xauth list" eingesehen werden. Will nun ein anderer User (in diesem Fall "root") auf unseren X-Server zugreifen, so benoetigt er einen passenden Schluessel: 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" hinzufuegen.

Doch noch immer kann kein X-Programm gestartet werden, denn diesem muss erst noch mitgeteilt werden, welches Display verwendet werden soll. Hierfuer 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 fuer die Shellvariable $DISPLAY des "Users root" die Datei "/root/.bashrc" an (sofern die Bash verwendet wird). Der Schluessel selber bleibt fuer kuenftige Sitzungen erhalten.
Da "root" jedoch die Daten des Users lesen kann, ist in diesem Fall ein auslesen, transportieren und einfuegen des Schluessels nicht erforderlich - so ist es moeglich, statt dem Ex- und Importieren einfach die gesamte Datei "~/.Xauthority" des Users zu uebernehmen. 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 Moeglichkeit 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 unterstuetzt:

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

sudo

Wem es nun zu umstaendlich 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 ueber "sudo /usr/local/sbin/fetchnews" aufrufen. Fuer 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

Aehnlich 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 koennen die User "jo" und "joe" das Programm "fetchnews" ohne Passworteingabe starten - aufzurufen ueber "super fnews" (vgl. "man 5 super"). Ein alleiniger Aufruf von "super" listet dem User alle ihm ueber "super" genehmigten Programme auf.

Und wem "super Programmname" bzw. "sudo Programmname" noch immer zu umstaendlich ist, der legt sich z.B. ein Alias "fetchnews" fuer "sudo fetchnews" bzw. "super fnews" an.

Eintrag ins Startmenue

Bislang sind mehrere Eingaben in einer Shell notwendig, um ein grafisches Programm mit Rootrechten auf dem Userdesktop zu platzieren - zu viel fuer einen Menueeintrag. 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 ueber "super" (oder "sudo") zur Verwendung ohne Passwortabfrage frei, so geht das mit einem einfachen Befehl. Beispiel fuer 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 ueber "sudo /usr/local/sbin/dateiname" startet das gewuenschte Programm mit Rootrechten und ohne Passwortabfrage auf dem Userdesktop. Und da spaetestens jetzt hinsichtlich Bedienung und Komfort kein Unterschied mehr zwischen User und "root" besteht - warum weiterhin noch die Risiken des Rootaccounts in Kauf nehmen?

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 koennen ueber folgende Adressen bezogen werden:

Und wer mehr ueber den (Fremd-)Zugriff auf den X-Server erfahren moechte, dem sei das "Remote X Apps mini-HOWTO" empfohlen - dieses ist ebenfalls Bestandteil von "/usr/share/doc", sowie unter folgenden Adressen erhaeltlich:

Dieses Posting ist mit kleinen Ergaenzungen im WWW zu finden unter http://www.jmos.net/user2root/.

Jo Moskalewski - news@jmos.net