der Benutzer root
Für die Systemadministration ist ein root-Zugriff erforderlich, der auch ein zentraler Punkt für die Systemsicherheit ist. Die richtige Pflege des root-Kontos ist eine entscheidende Aufgabe.
Da root nur ein weiterer Benutzer ist, kann man sich in den meisten Systemen direkt als root-Benutzer anmelden. Dies erweist sich jedoch als eine schlechte Idee, weshalb z.B. Ubuntu sie standardmäßig verbietet.
Zuerst hinterlassen root-Logins keine Aufzeichnungen darüber, welche Operationen als root ausgeführt wurden. Das ist schon schlimm genug, wenn man dann merkt, dass man abends zuvor etwas „kaputt“ gemacht hat und sich nicht erinnern kann, was man geändert hat; es ist noch schlimmer, wenn ein Zugriff nicht autorisiert war und man versucht herauszufinden, was ein Eindringling mit dem System gemacht hat. Ein weiterer Nachteil ist, dass das Login-as-Root-Szenario keine Aufzeichnung darüber hinterlässt, wer die Arbeit tatsächlich erledigt hat. Wenn mehrere Personen Zugriff auf das Root-Konto haben, kann man nicht erkennen, wer es wann benutzt hat.
der Befehl su (substitute user identity)
Eine etwas bessere Möglichkeit, auf das root-Konto zuzugreifen, ist die Verwendung des Befehls su.
Wenn der Befehl ohne Argumente aufgerufen wird, fragt su nach dem root-Passwort und startet dann eine root-Shell. Root-Privilegien bleiben in Kraft, bis man die Shell durch Eingabe von oder des Exit-Befehls beendet. su zeichnet die als root ausgeführten Befehle nicht auf, erstellt aber einen Log-Eintrag, der angibt, wer wann root wurde.
Der Befehl su kann auch andere Identitäten als root einnehmen. Manchmal ist er der einzige Weg, das Problem eines Benutzers zu reproduzieren oder zu debuggen, sein Konto zu benutzen, so dass man die Umgebung reproduziert, in der das Problem auftritt.
Wenn man das Passwort von jemandem kennt, kann man direkt auf das Konto dieser Person zugreifen, indem man su - <Benutzername> ausführt. Wie bei einem „su to root“ wird man nach dem Passwort für den Benutzernamen gefragt. Die Option – (Dash) bewirkt, dass su die Shell im Login-Modus öffnet.
Die genauen Auswirkungen des Login-Modus variieren je nach Shell, aber der Login-Modus ändert normalerweise die Anzahl oder Identität der Dateien, die die Shell beim Start liest. Beispielsweise liest bash die ~/.bash_profile im Login-Modus und ~/.bashrc im Non-Login-Modus. Bei der Diagnose von Problemen anderer Benutzer hilft es, ihre Login-Umgebungen durch den Einsatz im Login-Modus so genau wie möglich zu reproduzieren.
Auf einigen Systemen erlaubt das root-Passwort ein su oder ein Login für jedes beliebige Konto. Bei anderen muss man zuerst ein su explizit auf root durchführen, bevor man zu einem anderen Konto „suen“ kann; der Benutzer root kann su zu jedem Konto ohne Eingabe eines Passworts.
Auf den meisten Systemen muss man Mitglied der Gruppe „wheel“ sein, um su verwenden zu können.
Mittlerweile dürfte su aber weitgehend durch sudo abgelöst worden sein. su ist für Notfälle reserviert. Es ist auch hilfreich in Situationen, in denen sudo nicht mehr funktioniert oder falsch konfiguriert wurde.
der Befehl sudo: eingeschränktes su
Ohne eines der Zugriffskontrollsysteme, die hier beschrieben werden, ist es schwierig, jemandem zu ermöglichen, eine Aufgabe (z.B. Backups) auszuführen, ohne dieser Person den freien Zugriff auf das Systems zu ermöglichen. Und wenn das root-Konto von mehreren Administratoren verwendet wird, hat man wirklich nur eine vage Vorstellung davon, wer es verwendet oder was getan wurde.
Die am häufigsten verwendete Lösung für diese Probleme ist ein Programm namens sudo. Es ist die an erster Stelle empfohlene Zugriffsmöglichkeit auf das root-Konto.
sudo nimmt eine Befehlszeile als Argument, die als root (oder als anderer eingeschränkter Benutzer) ausgeführt werden soll. sudo verwendet die Datei /etc/sudoers, die die Personen auflistet, die berechtigt sind, sudo zu verwenden, und die Befehle, die sie auf jedem Host ausführen dürfen. Wenn der vorgeschlagene Befehl zulässig ist, fragt sudo nach dem eigenen Passwort des Benutzers und führt den Befehl aus.
Beispiel /etc/sudoers
Ein sehr ausführliches Beispiel für eine sudoers-Datei zeigt verschiedene Möglichkeiten der Rechte-Vergabe für Benutzer und Gruppierungen:
# Sample /etc/sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#
##
# User alias specification
##
User_Alias FULLTIMERS = millert, mikef, dowdy
User_Alias PARTTIMERS = bostley, jwfox, crawl
User_Alias WEBMASTERS = will, wendy, wim
##
# Runas alias specification
##
Runas_Alias OP = root, operator
Runas_Alias DB = oracle, sybase
##
# Host alias specification
##
Host_Alias SPARC = bigtime, eclipse, moet, anchor:\
SGI = grolsch, dandelion, black:\
ALPHA = widget, thalamus, foobar:\
HPPA = boa, nag, python
Host_Alias CUNETS = 128.138.0.0/255.255.0.0
Host_Alias CSNETS = 128.138.243.0, 128.138.204.0/24, 128.138.242.0
Host_Alias SERVERS = master, mail, www, ns
Host_Alias CDROM = orion, perseus, hercules
##
# Cmnd alias specification
##
Cmnd_Alias DUMPS = /usr/sbin/dump, /usr/sbin/rdump, /usr/sbin/restore, \
/usr/sbin/rrestore, /usr/bin/mt
Cmnd_Alias KILL = /usr/bin/kill
Cmnd_Alias PRINTING = /usr/sbin/lpc, /usr/bin/lprm
Cmnd_Alias SHUTDOWN = /usr/sbin/shutdown
Cmnd_Alias HALT = /usr/sbin/halt
Cmnd_Alias REBOOT = /usr/sbin/reboot
Cmnd_Alias SHELLS = /sbin/sh, /usr/bin/sh, /usr/bin/csh, /usr/bin/ksh, \
/usr/local/bin/tcsh, /usr/bin/rsh, \
/usr/local/bin/zsh
Cmnd_Alias SU = /usr/bin/su
Cmnd_Alias VIPW = /usr/sbin/vipw, /usr/bin/passwd, /usr/bin/chsh, \
/usr/bin/chfn
##
# Override built-in defaults
##
Defaults syslog=auth
Defaults>root !set_logname
Defaults:FULLTIMERS !lecture
Defaults:millert !authenticate
Defaults@SERVERS log_year, logfile=/var/log/sudo.log
##
# User specification
##
# root und users in der Gruppe wheel können alles auf jedem Rechner als beliebiger Benutzer ausführen
root ALL = (ALL) ALL
%wheel ALL = (ALL) ALL
# Vollzeit-Sysadmins können alles auf jeder Maschine ohne Passwort ausführen
FULLTIMERS ALL = NOPASSWD: ALL
# Teilzeit-Sysadmins dürfen alles ausführen, brauchen aber ein Passwort
PARTTIMERS ALL = ALL
# jack darf alles auf Maschinen in CSNETS
jack CSNETS = ALL
# lisa kann jeden Befehl ausführen auf jedem Host in CUNETS (a class B network)
lisa CUNETS = ALL
# operator kann Wartungsbefehle ausführen und alles in /usr/oper/bin/
operator ALL = DUMPS, KILL, SHUTDOWN, HALT, REBOOT, PRINTING,\
sudoedit /etc/printcap, /usr/oper/bin/
# joe darf su nur für operator
joe ALL = /usr/bin/su operator
# pete darf Passwörter ändern für jeden, außer für root, auf den hp Servern
pete HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root
# bob kann auf den sparc- und sgi-Maschinen alles für die Benutzer laufen lassen,
# die aufgeführt sind im Runas_Alias "OP" (z.B.: root and operator)
bob SPARC = (OP) ALL : SGI = (OP) ALL
# jim darf alles auf Rechnern in der biglab Netzgruppe
jim +biglab = ALL
# users in der secretaries Gruppe können Drucker verwalten sowie
# User hinzufügen und löschen
+secretaries ALL = PRINTING, /usr/bin/adduser, /usr/bin/rmuser
# fred kann Befehle ausführen als oracle oder sybase ohne Passwort
fred ALL = (DB) NOPASSWD: ALL
# auf den alpha Maschinen, john darf su für jeden ausführen, außer für root,
# und Optionen sind nicht erlaubt
john ALPHA = /usr/bin/su [!-]*, !/usr/bin/su *root*
# jen darf auf allen Rechnern alles ausführen, außer auf denen im Host_Alias "SERVERS"
jen ALL, !SERVERS = ALL
# jill darf alle Befehle im Verzeichnis /usr/bin/ ausführen,
# mit Ausnahme derer in den Aliasen SU und SHELLS.
jill SERVERS = /usr/bin/, !SU, !SHELLS
# steve darf alle Befehle ausführen im Verzeichnis /usr/local/op_commands/ als User operator.
steve CSNETS = (operator) /usr/local/op_commands/
# matt darf Prozesse auf seiner Workstation "killen" (beenden), wenn sie sich aufhängt haben
matt valkyrie = KILL
# users im User_Alias WEBMASTERS (will, wendy, and wim) dürfen jeden Befehl ausführen
# als User www (which owns the web pages) oder mit su auf www
# or simply su to www.
WEBMASTERS www = (www) ALL, (root) /usr/bin/su www
# jeder darf mount/unmount eine cd-rom auf den Maschinen im alias CDROM
ALL CDROM = NOPASSWD: /sbin/umount /CDROM,\
/sbin/mount -o nosuid\,nodev /dev/cd0a /CDROMEs sollte darauf geachtet werden, dass Befehle in der Datei sudoers mit vollständigen Pfadnamen angegeben werden, um zu verhindern, dass Personen ihre eigenen Programme und Skripte als root ausführen können.
Obwohl hier keine Beispiele gezeigt werden, ist es möglich, auch die Argumente anzugeben, die für jeden Befehl zulässig sind.
Um die sudoers-Datei manuell zu ändern, verwendet man den Befehl visudo, der sicherstellt, dass niemand sonst die Datei bearbeitet, der einen Editor aufruft (vi oder den Editor, den man in der EDITOR-Umgebungsvariablen angeben hat) und dann die Syntax der bearbeiteten Datei vor dem Speichern überprüft. Dieser letzte Schritt ist besonders wichtig, da eine ungültige sudoers-Datei einen daran hindern könnte, erneut sudo zu starten, um die Fehler zu beheben.
sudo führt ein Protokoll über die ausgeführten Befehlszeilen, die Hosts, auf denen sie ausgeführt wurden, die Personen, die sie ausgeführt haben, die Verzeichnisse, aus denen sie ausgeführt wurden, und die Zeiten, zu denen sie aufgerufen wurden. Diese Informationen können von syslog protokolliert oder in eine Datei der Wahl erstellt werden. Unter RedHat ist das Standard-Logfile /var/log/secure.
sudo Vor- und Nachteile
Der Einsatz von sudo hat folgende Vorteile:
Die Nachweisführung wird durch die Befehlsprotokollierung erheblich verbessert.
Benutzer können bestimmte Aufgaben erledigen, ohne unbegrenzte root-Rechte zu haben.
Das echte Root-Passwort ist nur einem oder zwei Personen bekannt sein.
Die Verwendung von sudo ist schneller als die Verwendung von su oder das Login als root.
Die Privilegien können entzogen werden, ohne dass das root-Passwort geändert werden muss.
Eine konsistente Liste aller Benutzer mit root-Rechten wird geführt.
Die Wahrscheinlichkeit, dass eine root-Shell unbeaufsichtigt bleibt, wird verringert.
Eine einzelne Datei kann den Zugriff für ein ganzes Netzwerk steuern.
sudo hat auch ein paar Nachteile. Der Schlimmste ist, dass jede Verletzung der Sicherheit des persönlichen Kontos eines „Sudoers“ gleichbedeutend sein kann mit der Verletzung des root-Kontos selbst. Man kann nicht viel tun, um dieser Bedrohung entgegenzuwirken, außer die „Sudoers“ zu warnen, ihre eigenen Konten zu schützen, wie sie es mit dem root-Konto tun würden.
Da das System anfällig für katastrophale Bedrohungen ist, wenn das Root-Konto angegriffen wird, besteht ein großer Nachteil der sudobasierten Zugriffskontrolle darin, dass sich die potenzielle Angriffsfläche erweitert und die Konten aller Administratoren umfasst.
sudo funktioniert gut als Werkzeug für gut gesinnte Administratoren, die allgemeinen Zugriff auf root-Rechte benötigen. Es ist auch hervorragend geeignet, Nichtadministratoren zu erlauben, einige bestimmte Operationen durchzuführen. Trotz einer Konfigurationssyntax, die etwas anderes vermuten lässt, ist es leider kein sicherer Weg, begrenzte unabhängige Bereiche zu definieren oder bestimmte Operationen außerhalb bestimmter Grenzen zu ermöglichen.