Aus Linux-Forum Wiki

Inhaltsverzeichnis 1 Zweck 2 Abgrenzung zum su Kommando 3 Der Befehl selbst 4 Grobe interne Funktionsweise 5 Die Konfigurationsdatei 5.1 Grundsätzlicher Aufbau 5.2 Aliases 5.3 Was hat es mit der Hostangabe auf sich? 5.4 Beschreibungssätze 5.4.1 Beispiel: wheel-Gruppe 5.4.2 Beispiel: Systemupgrades als User 6 Einschränkungsmöglichkeiten 6.1 Ausführungsbeschränkungen 6.1.1 Shellescapes 6.2 Generelle Optionen 6.2.1 Optionssyntax 6.2.2 Beispiele 6.2.3 Einige Optionen 6.2.3.1 Benachrichtigung 6.2.3.2 Limits und Sperren bzw. Freigaben 6.2.3.3 Ticketing (Caching) 7 Einige Warnhinweise 7.1 Ticketing 7.2 Zielbenutzer root 8 Ausklang 9 Kritik?

Zweck

Der Zweck von sudo ist es, einfach Befehle unter anderen Benutzerkonten auszuführen.

Anders als su ist sudo über die Datei (/etc/sudoers) sehr fein und relativ sicher konfigurierbar. Dort wird festgehalten, welcher Benutzer auf welchem Host welche Befehle als welcher Benutzer mit welchen Einschränkungen oder Eigenschaften ausführen darf.

sudo kann, wenn man es korrekt konfiguriert, einen loginfähigen Systemadministratoraccount überflüssig machen. Dies wird zum Beispiel bei Ubuntu-Linux so gemacht. Der root Benutzer kann sich nicht anmelden, per sudo ist aber eine begrenzte Benutzergruppe in der Lage, Befehle als root auszuführen. Ob und in welcher genauen Form eine solche Einstellung Sinn ergibt, bleibt natürlich dem jeweiligen Administrator vorbehalten.

Abgrenzung zum su Kommando

Das su-Kommando ist dazu gedacht, ohne grosse Konfiguration das Starten eines Prozesses (oder per Default einer Shell) unter anderen Benutzerkonten zu ermöglichen. Dies ist auch nicht (ausser für root) Passwortlos möglich.

Weiterhin gibt es keinerlei Möglichkeiten, Einschränkungen wie zum Beispiel erlaubte Programme, zu vergeben.

su gehört in dieselbe Kategorie wie sg bzw. newgrp: Es ist ein kleines Tool, um schnell den Benutzeraccount zu wechseln. Es ist aufgrund seiner Einschränkungen nicht für den großflächigen Einsatz geeignet, da von den Zielbenutzerkonten die Passwörter bekannt sein müssen.

Kleiner Dämpfer: Wenn man sich mit PAM beschäftigt, kann man su natürlich in gewisser Weise passwortlos konfigurieren. Aufgrund der fehlenden Konfigurationsmöglichkeit, würde dies allerdings ein sehr hohes Sicherheitsrisiko darstellen.

Der Befehl selbst

Der sudo Befehl selbst wird wie in der Manpage beschrieben benutzt. Grundform ist:

 sudo BEFEHL ARGUMENTE...

Damit wird der Befehl BEFEHL mit den Argumenten ARGUMENTE als Defaultbenutzer (normalerweise root) ausgeführt. Ob das so funktioniert, hängt natürlich von der Konfiguration in der Datei /etc/sudoers ab.

Wenn man nicht den Defaultbenutzer als Zielbenutzer haben will, so gibt man den gewünschten Account mit -u an:

 sudo -u BENUTZER BEFEHL ARGUMENTE...

Es gibt noch eine ganze Reihe von weiteren Kommandozeilenoptionen. Einige werden wir nachher noch kennenlernen, aber eine genaue Übersicht gibt es in der zugehörigen Manpage. Die meisten von ihnen ergeben erst Sinn wenn man ungefähr weiss wie sudo tickt.

Grobe interne Funktionsweise

sudo ist grundsätzlich erstmal ein Programm, dass mit root-Rechten laufen muss. Daher ist es im Dateisystem mit SUID ("set user ID on execution") gekennzeichnet (siehe auch Dateirechte (klassisch)). Nur Programmen die als root laufen ist es gestattet, beliebig den Benutzer zu wechseln.

Nach dem Aufruf wird sudo etwa folgendes tun:

• Auswerten der Kommandozeilenparameter (was will der Benutzer?)
• Vergleichen mit der Konfiguration (was darf der Benutzer?)
• OK: Ausführung gemäss Konfiguration (nach eventuellem Schalten zum Zielbenutzer)
• Nicht OK: Abweisung bzw. Frage nach Zielpasswort und/oder Sicherheitsbenachrichtigung per Mail

Die Konfigurationsdatei

Die Konfigurationsdatei beschreibt, wie oben schon erwähnt, welcher Benutzer was unter welchen Voraussetzungen per sudo machen darf. Normal ist es /etc/sudoers und sollte nur mit dem Programm visudo bearbeitet werden (startet einen Editor, sperrt die Datei und macht vor dem endgültigen Speichern eine Syntaxprüfung).

Neben den Beschreibungssätzen und Aliases gibt es auch noch generelle Optionen. Einige davon werden weiter unten beschrieben.

Grundsätzlicher Aufbau

Da sudo für eine grosse Anzahl von Benutzern, Hosts und Befehlen konzipiert ist, werden normalerweise Aliases gesetzt, die später dann nur verwendet werden. Wenn die Aliases sprechend sind ("SHUTDOWN_KOMMANDOS" anstatt "XYZ"), dann erhöht sich dadurch natürlich auch die Lesbarkeit.

Der grundsätzliche Aufbau eines Beschreibungssatzes ist

 BENUTZER  HOSTNAME = (ZIELBENUTZER) EINSTELLUNGEN: BEFEHL

• BENUTZER ist der aufrufende Benutzer ("Wer darf..."). Hier können auch System- bzw. Netzwerkgruppen angegeben werden.
• HOSTNAME ist der Name des Systems auf dem sudo aufgerufen wird ("Von wo...")
• ZIELBENUTZER ist der Benutzeraccount unter dem der angegebene Befehl ausgeführt werden darf ("Als was/wer...")
• EINSTELLUNGEN sind einige Flags die für die angegebenen Befehle noch Feineinstellungen mitgeben ("Mit welchen Einschränkungen oder Eigenschaften...")
• BEFEHL ist die Kommandozeile die ausgeführt werden darf ("Was...")

So kann man auch den Satz in der Einleitung oben ein bisschen ableiten:

• Wer darf
• von wo
• als was
• mit welchen Einschränkungen oder Eigenschaften
• was

ausführen?

Das kann und darf natürlich etwas komplexer ausfallen. Für alle oben genannten Dinge kann eine Liste angegeben werden (mehrere BENUTZER, mehrere HOSTNAME, ...). Und hier kommen dann auch - der Lesbarkeit wegen - die Aliases ins Spiel (ausser für EINSTELLUNGEN). Man definiert zum Beispiel eine Liste von Befehlen in einem Alias, und nutzt diesen Alias (oder mehrere) dann im Beschreibungssatz.

Die genaue Syntaxbeschreibung ist der Manpage zu entnehmen. Man kann noch ein paar Spielereien wie Angaben über mehrere Zeilen oder mehrere Beschreibungssätze für einen Benutzer machen. Dieser Artikel soll die Manpage nicht ersetzen, sondern eine Grundlageneinführung darstellen.

Aliases

Die Aliasdefinitionen haben die Form

 ALIASTYP ALIASNAME = ALIASINHALT

Der Typ des Alias ist

• User_Alias Benutzer oder Benutzerliste
• Runas_Alias Zielbenutzer oder Zielbenutzerliste
• Host_Alias Hostname oder Hostnamenliste
• Cmnd_Alias Befehl oder Befehlsliste

Beispiel:

 Cmnd_Alias SHUTDOWN_KOMMANDOS =  /sbin/shutdown, !/sbin/init, !/sbin/init *, /sbin/init 0, /sbin/halt

Hier am Beispiel von /sbin/init, sieht man auch implizite Einschränkungen, die man für die Befehlssyntax machen kann. Hier werden Negation (Ausrufezeichen) und Wildcards verwendet, um genau anzugeben welche Parameter an /sbin/init übergeben werden dürfen und welche nicht. Übrig bleibt hier nur "/sbin/init 0", was normalerweise einen Systemshutdown auslöst. Andere Parameter (oder garkeine) dürfen hier nicht gegeben werden.

Auch gibt es für alle Typen den vordefinierten Alias ALL, dieser bedeutet, je nach Typ, alle Möglichkeiten (z.B. "alle Befehle", "von allen Hosts", ...).

Erlaubte Namen: Aliasnamen beginnen mit Grossbuchstaben und enthalten nur Grossbuchstaben, Ziffern und den Underscore ("_").

Was hat es mit der Hostangabe auf sich?

sudo ist wie schon gesagt, für einen grossflächigen Einsatz konzipiert. Auch wenn gerade aktuelle Desktopumgebungen wie KDE oder GNOME dazu neigen, immer nur den einzelnen Rechner ohne Netzwerkverbund zu betrachten (und damit einen Grossteil ihrer Flexibilität aufgeben!) sollte niemals vergessen werden, dass UNIX schon sehr lange ein netzwerkfähiges Betriebssystem ist. Alle interessanten Dinge sollten so geschrieben werden, dass man sie ohne grosse Probleme in einem gesamten Rechnerverbund nutzen kann.

Darüberhinaus kann sudo seine Konfiguration auch aus einem LDAP-Directory auslesen, was das Verteilen der Konfigurationsdatei auf die einzelnen Rechner unnötig macht.

Man kann eine Konfigurationsdatei erstellen, die von allen Rechnern im Netzwerk gleich genutzt wird. Der Hosteintrag ist dazu da, um Einschränkungen auf bestimmte Rechner zu geben.

Beispiel: Ein Benutzergruppe webadmin darf per sudo den Rechner www herunterfahren, aber keine anderen Rechner. Hier wäre eine Hostangabe von www sinnvoll.

Wenn man keine Verwendung für eine solche Angabe hat (Einzelplatzkonfiguration) sollte man einfach den Alias ALL verwenden.

Beschreibungssätze

Die einzelnen Beschreibungssätze werden nach dem oben erwähnten Schema aus Aliases oder direkten Angaben zusammengesetzt.

Wenn sudo zu einer angeforderten Sache mehrere Beschreibungssätze findet, so wird der letzte passende verwendet. Dies ist nicht immer der, der am genauesten passt. Man sollte sich daher gut überlegen, in welcher Reihenfolge man die Beschreibungssätze eingibt.

Beispiel: wheel-Gruppe

Ein einfaches Beispiel ist ein Beschreibungssatz, der es Benutzern in der Gruppe wheel erlaubt, ohne Passwortabfrage jeglichen Befehl als root oder andere Benutzer auszuführen. Die Gruppe wheel ist im BSD-Bereich traditionell eine Art "Co-Administrator" Gruppe, es könnte also durchaus sein, dass Ihr ein System habt bei dem das bereits konfiguriert ist.

 %wheel  ALL=(ALL) NOPASSWD: ALL

Beispiel: Systemupgrades als User

Ein weiteres Beispiel: Ich benutze ein Debian-System. Das einzige was ich regelmäßig als root tun muss sind Systemupgrades. Da ich recht faul bin, habe ich mir für meinen Benutzer bonsai eine kleine sudo-Konfiguration hinterlegt:

 Cmnd_Alias APT_COMMANDS = /usr/bin/apt-get, /usr/bin/apt-cache, /usr/bin/aptitude
 
 bonsai ALL=(root) NOPASSWD:APT_COMMANDS

Somit kann ich einfach per

 sudo aptitude update && sudo aptitude upgrade

zum Beispiel ein Systemupgrade fahren.

Der Hostalias ALL wird hier übrigens keineswegs wegen Einzelplatznutzung verwendet. Ich betreibe mehrere Debian-Systeme und der Benutzer bonsai ist ein netzwerkweiter Benutzer. Auf allen Systemen kann ich somit - mit der identischen sudo-Konfiguration - Systemupgrades fahren. Wenn ich mein Internet-Gateway ("gate") von dieser Regel ausnehmen möchte, muss ich nur die Zeile ändern in:

 bonsai ALL,!gate=(root) NOPASSWD:APT_COMMANDS

Einschränkungsmöglichkeiten

Wie oben schon erwähnt und auch an einigen Beispielen gesehen, kann man einige Einschränkungen vergeben. In der Regel passiert dies innerhalb der Listen (Benutzerliste, Befehlsliste, ...).

Für die meisten Sachen werden Textvergleiche benutzt, die den Wildcards (Globbing) der Shell nicht unähnlich sind. Zum Negieren eines Listenelements wird ein Ausrufezeichen vorangestellt.

Hier nur einige Beispiele:

• Alle Benutzer dürfen einen bestimmten Befehl ohne Passwortabfrage als root ausführen, ausser einer (kurt):

 ALL,!kurt  ALL=(root) NOPASSWD:/bin/hallo

• Alle Benutzer der Gruppe wheel dürfen alle Befehle ohne Passwortabfrage als root ausführen, nur nicht Befehle für die Netzwerkadministration und keine Shells (muss natürlich vorher als Alias definiert werden):

 %wheel  ALL=(root) NOPASSWD:ALL,!NETWORK_COMMANDS,!SHELLS

Ausführungsbeschränkungen

Die wahrscheinlich populärste Ausführungsbeschränkung haben wir in fast jedem Beispiel gesehen: NOPASSWD. Es gibt mehr Ausführungsbeschränkungen, hier eine hoffentlich vollständige Liste:

Einschalten	Ausschalten	Bedeutung
PASSWD	NOPASSWD	Abfrage des Passwortes (entweder des eigenen oder des des Zielbenutzers, Konfigurationssache) zur Ausführung des folgenden Kommandos
EXEC	NOEXEC	Verhinderung von Sicherheitsrisiken durch Shellescapes (siehe Text "Shellescapes" weiter unten)
SETENV	NOSETENV	Bedingungslose Weitergabe von Umgebungsvariablen (genaue Filterung ist Konfigurationssache)

Shellescapes

Unter Shellescapes wird hier alles zusammengefasst, was brauchbar ist, um von einem Programm aus ein beliebiges anderes Programm auszuführen. In der Regel sind das Kommandos wie "!BEFEHL" im VIM Texteditor. Diese Kommandos starten eine Shell und führen die angegebenen Befehle aus.

Dies stellt natürlich ein Risiko dar, da man mit sudo auf der einen Seite versucht möglichst viele Einschränkungen zu geben, aber auf der anderen Seite Texteditoren gestartet werden können, von denen aus man beliebige Befehle ausführen kann.

Eine Möglichkeit dies zu verhindern ist das NOEXEC Flag von sudo. Wenn dies für einen Befehl konfiguriert wird, werden die Systemfunktionen die zum Starten von Prozessen benötigt werden mit Dummies überladen, und somit unbrauchbar gemacht. Der Texteditor der eine Shell starten will wird nur eine Fehlermeldung erhalten. Auch eine Shell wird niemals etwas ausführen können.

Ob diese Lösung sinnvoll ist oder nicht hängt von der Situation ab. Es ist auf jeden Fall eine Lösung die greift:

 bonsai@mainserver:~$ sudo bash
 root@mainserver:~# ls
 bash: /bin/ls: Keine Berechtigung

Generelle Optionen

Generelle Optionen steuern das Verhalten von sudo, das nicht direkt mit Beschreibungssätzen angegeben werden kann - zum Beispiel welches Passwort abgefragt wird (aufrufender Benutzer, Rootpasswort oder Zielbenutzer).

Die Angaben dieser Optionen überschreiben das Defaultverhalten von sudo. Man kann auch verschiedene Defaults für Benutzer, Zielbenutzer, Hosts und Befehle setzen.

Optionssyntax

• Global

 Defaults OPTION

• Anhand Zielbenutzer

 Defaults>ZIELBENUTZER OPTION

• Anhand aufrufender Benutzer

 Defaults:BENUTZER OPTION

• Anhand Host

 Defaults@HOST OPTION

• Anhand Befehl

 Defaults!BEFEHL OPTION

Es gibt mehrere Optionstypen:

Typ	Beispiele
Boolean (Flags)	env_delete, !passwd_timeout
Integer	passwd_tries=3, passwd_timeout=5
String	passprompt="Passwort bitte: "
Liste	env_delete = "LC_ALL LC_NAME"

An dem Beispiel passwd_timeout sieht man auch gut, dass man bestimmte Optionen sowohl als Integer (oder auch String) als auch Boolean setzen kann.

Beispiele

• Syslog Facility setzen (globaler Default):

 Defaults               syslog=auth

• Umgebungsvariablen bei Zielbenutzer root nicht löschen:

 Defaults>root          !env_delete

• Den Benutzern in der Benutzerliste (ein Alias) FULLTIMERS den Hinweistext nicht anzeigen:

 Defaults:FULLTIMERS    !lecture

• Alle Programme im Alias PAGERS im NOEXEC-Modus ausführen:

 Defaults!PAGERS        noexec

Einige Optionen

Die nachfolgenden Optionen sind lange nicht die einzigen, eine detailierte Übersicht gibt wie immer die Manpage.

Benachrichtigung

mailto	String	Zieladresse für die Benachrichtigungsmail (Default: root)
mailsub	String	Titel der Benachrichtigungsmail (%h wird ersetzt durch den Hostnamen)
mail_always	Boolean	Jeden Zugriff auf sudo per Mail melden, egal ob erfolgreich oder nicht.
mail_badpass	Boolean	Zugriffe mit falschem Passwort per Mail melden.

Limits und Sperren bzw. Freigaben

noexec	Boolean	Alle Befehle werden per Default behandelt als ob NOEXEC angegeben wurde. Überschreibbar mit EXEC
passwd_tries	Integer	Max. Anzahl an Versuchen, Passwörter einzugeben
passwd_timeout	Integer	Timeout des Passwortpromptes. 0 (Null) für keinen Timeout.
exempt_group	String	Benutzer in der angegebenen Gruppe werden vom Passwortzwang (und anderen Sperren) ausgenommen.

Ticketing (Caching)

Das Ticketing ermöglicht das Benutzen von sudo ohne Passwort, nachdem erstmalig ein Passwort eingegeben wurde.

timestamp_timeout	Integer	Anzahl der Minuten nach denen ein Ticket ungültig wird. Bei einer Einstellung von 0 (Null) wird sudo immer nach einem Passwort fragen, bei einer Einstellung kleiner Null wird der Zeitstempel im Ticket niemals ungültig und der Benutzer kann per sudo -k und sudo -v die Gültigkeit des Tickets selber bestimmen.
tty_tickets	Boolean	Normalerweise wird ein Ticket auf Basis des Benutzernamens vergeben, wird tty_ticket gesetzt, so wird das Ticket anhand des Terminals vergeben.

Einige Warnhinweise

Ticketing

sudo kann wie oben angedeutet, einmal ein Passwort entgegennehmen und dann nie wieder danach fragen. Dieses sog. "Ticketing" kann benutzerbasiert sein. Doch Vorsicht: Wenn es benutzerbasiert ist, kann nachdem der Benutzer einmal sein Passwort eingegeben hat, ein etwaiger Schadcode per sudo passwortlosen Zugang zu anderen Accounts (im schlimmsten Fall root) erlangen.

Aus diesem Grund empfehle ich benutzerbasiertes Ticketing nicht. Auch sollte ein sinnvoller Timeout für Tickets gewählt werden.

Zielbenutzer root

Auch wenn es bequem erscheint, (und auch in der Praxis bei mancher Distribution so ausgeliefert wird) so sollte man sehr gründlich darüber nachdenken, ob man generell per ALL als Befehl erlaubt, wenn der Zielbenutzer root ist.

Es gibt nicht ohne Grund eine Trennung zwischen Administratoren und Benutzern. Ein falscher Befehl an der falschen Stelle - absichtlich oder nicht - kann komplettes systemweites Chaos nach sich ziehen.

Wenn root im Spiel ist, darf man sich einfach keine Fehler leisten. Diejenigen die Systeme betreiben deren Ausfall Geld kostet werden das verstehen.

Ausklang

Generell habe ich bemerkt, dass die meisten garnicht verstehen wie und warum sudo funktioniert oder für was es eigentlich da ist (und für was es nicht da ist). sudo scheint zu den Tools zu gehören, denen viele lieber aus dem Weg gehen.

Ich hoffe diese Übersicht hilft ein bisschen die Berührungsangst zu überwinden. Eigentlich - und das meine ich wirklich - ist es ja doch keine Hexerei.

Kritik?

Gerne nehmen alle Beteiligten Ideen und Kritik zu dem Artikel entgegen.

• TheBonsai