© Sergey Nivens / 123RF.com

Sudo kennen nahezu alle, die heute mit Linux arbeiten. Es ist die Abkürzung von superuser do – aber hinter dem Tool steckt mehr als “jeder darf alles, solange er Sudoer ist”.

@L:Mit Sudo kam ich – wenn ich mich recht erinnere – erstmals in Ubuntu 4.10 Warty Warthog in Berührung. Abgesehen davon, dass ich das Root-Kennwort nicht mehr brauchte, war mir anfangs noch unklar, was es bringen sollte, auf einem Desktop »root« zu deaktivieren. Das lag vermutlich auch daran, dass Doku und Beispiele allzu oft Zeilen wie »user ALL=(ALL:ALL) NOPASSWD: ALL« enthielten. Die wahre Macht des Tools erkannte ich erst, als ich begann, mich eingehender damit zu befassen. Da Sudo einen enormen Funktionsumfang besitzt, gehe ich lediglich auf einige wenige Punkte ein, die Interessierten die Konfiguration erleichtern.

Besagte Zeile, die mir stets sauer aufstieß, gibt dem Benutzer »user« das Recht, auf allen Hosts jegliches Kommando unter beliebigen Usern auszuführen – ohne sich per Passwort authentifizieren zu müssen. Mir fällt tatsächlich kein Anwendungsfall ein, der so ein niedriges Sicherheitsniveau rechtfertigen würde. Bevor ich aber einen Blick auf sinnvolle Settings werfe, sehen wir uns die grundsätzliche Arbeit mit der beziehungsweise den Konfigurationsdateien an.

Wie viele andere Tools beherrscht auch Sudo den Umgang mit einer Hauptkonfigurationsdatei »/etc/sudoers« sowie beliebig benannten weiteren Konfigurationsdateien im Verzeichnis »/etc/sudoers.d«. Das birgt große Vorteile, denn splitte ich die Konfiguration beispielsweise nach einzelnen Usern auf, bleiben die Dateien nicht nur deutlich übersichtlicher, syntaktische Fehler haben ebenfalls erheblich weniger gravierende Konsequenzen. Eine nicht lesbare Unter-Konfigurationsdatei führt nicht dazu, dass Sudo unbrauchbar wird. Um die Aufspaltung zu ermöglichen, bedarf es der Direktive »@includedir /etc/sudoers.d« (beziehungsweise »#includedir /etc/sudoers.d« auf Systemen mit Sudo < 1.9.1) in »/etc/sudoers«.

Anschnallen, bitte!

Sudoers-Dateien sollten Sie niemals einfach per Editor bearbeiten. Stattdessen empfiehlt sich dazu das Tool Visudo. Es ergreift gleich mehrere Sicherheitsmaßnahmen, um Inkonsistenzen in der oder den Dateien zu verhindern. Dazu gehört unter anderem ein Locking-Mechanismus, der verhindert, dass mehrere Prozesse die Datei gleichzeitig verändern, aber auch Prüfroutinen hinsichtlich Syntax und Validität, die vor der endgültigen Sicherung der Datei ausgeführt werden. Visudo erkennt Fehler und fragt beim Beenden nach, was mit der Datei geschehen soll (Abbildung 1).

Abbildung 1: Visudo prüft und beanstandet Fehler.

Doch das Werkzeug kann noch mehr: Wer beispielsweise automatisiert, etwa per Ansible, seine Linux-Maschinen ausrollt und dabei außerdem Benutzer, Gruppen und Sudoers konfiguriert, kann per Visudo die Konfiguration auf Validität prüfen. Visudo verfügt über einen Check-Modus, wie Abbildung 2 zeigt.

$ sudo /usr/sbin/visudo --check --file=/etc/sudoers

Abbildung 2: Der Check-Mode von Visudo prüft die Konfiguration.

Dank des Check-Mode lässt sich zum Beispiel im Rahmen der Automatisierung vor dem Editieren der Konfiguration eine Sicherungskopie anlegen. Gibt Visudo anschließend grünes Licht, kann ich die Sicherungskopie löschen. Ansonsten kann ich eine Art Rollback-Mechanismus implementieren, der die Konfigurationsdatei aus der Sicherungskopie wiederherstellt.

Lockdown

Weniger ist mehr – häufig steckt in solchen Plattitüden ein Körnchen Wahrheit. Der Grundsatz gilt vor allem bei Berechtigungen und Privilegien auf Computersystemen. Allzu häufig erhalten User viel zu umfangreiche Berechtigungen auf Betriebssystemen. Gerade Sudo macht es einem da sehr einfach: Eine einzige ANY-ALL-Zeile genügt, um als Admin schnell seine Ruhe zu haben.

Dass bei derart offenen Systemen kaum jemand mit personalisierten Usern arbeitet, sondern direkt per »sudo -i« oder »sudo -s« eine privilegierte Shell öffnet und daraufhin als root unterwegs ist, erleichtert selbstverständlich vieles. Für den verantwortlichen Administrator sieht die Sache allerdings anders aus. Er oder sie kann in einem solchen Szenario nur hoffen, dass die Kollegen angemessen verantwortungsvoll handeln. Eine ausgesprochen unbefriedigende Situation – immerhin bietet Sudo doch zahlreiche Möglichkeiten, Rechte feingranular zu vergeben.

Cmnd_Alias    SHELLS = /bin/sh, /bin/bash, /bin/bash, /usr/bin/zsh
Cmnd_Alias    SU = /bin/su
Host_Alias    WEB_SERVERS = srvweb01, srvweb02, srvweb03, srvweb04
User_Alias    WEB_INTERNS = oskar, mila, emil, snorre, tilda
User_Alias    WEB_ADMINS = estrid, freya, balder
User_Alias    BACKUP_ADMINS = knut, ylvi, olav
User_Alias    ADMINS = hilka, magne
WEB_INTERNS    WEB_SERVERS = /usr/bin/, !SU, !SHELLS
WEB_ADMINS    WEB_SERVERS = /usr/bin/, !SHELLS
BACKUP_ADMINS    ALL=(ALL:ALL) ALL, !SU, !SHELLS
ADMINS    ALL=(ALL:ALL) ALL
%operators    ALL=(ALL:ALL) ALL

Eine Sudo-Regel definiert, welcher User auf welchem Host unter welchem anderen User welches Kommando ausführen darf. Ein »User_Alias« definiert dementsprechend entweder einzelne User oder eine Liste von Usern, die sich zusammensetzt wie in Listing 1 in Zeile 6. Ähnlich funktioniert das mit »Cmnd_Alias« (erste Zeile). Hier werden diverse ausführbare Dateien, bei denen es sich um Shells handelt, unter dem Alias SHELLS zusammengefasst. In Zeile 11 erhalten nun die Mitglieder des User_Alias WEB_INTERNS die Berechtigung, Programme aus »/usr/bin« zu starten, mit Ausnahme von SU und SHELLS. Das Ausrufezeichen negiert, wie in vielen Fällen, das nachfolgende Kommando. Andererseits dürfen Mitglieder des User_Alias ADMINS ebendiese SHELLS mit root-Rechten starten. Ich kann hier nicht nur einzelnen Usern Rechte zuweisen, sondern auch ganzen UNIX-Gruppen, wie Zeile 11 verdeutlicht.

Protokollierung

Wer erstmalig Sudo auf einem System (in deutscher Sprache) ausführt, den begrüßt zunächst ein Appell zu mehr Privatsphäre, Sorgfalt und Verantwortung (Abbildung 3). Vertrauen ist hier gut, Kontrolle aber besser. Im Rahmen der Anpassungen an der sudoers-Datei habe ich sichergestellt, dass einfache User keine root-Shells öffnen können. Das ist die Grundlage, damit ich mitbekomme, was die Kollegen auf den Systemen anstellen beziehungsweise angestellt haben. Ich persönlich habe kein übermäßiges Interesse daran, stets zu erfahren, was Kollegen auf Systemen treiben, für die sie selbst verantwortlich sind. Im Zweifel hilft es allerdings ungemein, wenn man nachsehen kann, wo die Ursache eines Problems liegt. Dazu dient das Sudo-Input-/Output-Log.

Abbildung 3: Sudo weist den User initial auf seine Verantwortung hin.

Aktiviere ich das Input-Log von Sudo per Direktive »Defaults log_input«, wird künftig die Kommandozeile jedes Sudo-Aurufs »/var/log/sudo-io/« gespeichert. Wie ein solches Log aussehen kann, zeigt Abbildung 4. Genauso funktioniert das Output-Log. Der Befehl »Defaults log_output« aktiviert es. Daraufhin protokolliert es sämtliche Ausgaben aller per Sudo gestarteten Prozesse. Mit sämtliche Ausgaben meine ich wirklich alle. Das heißt: Kommt jemand auf die Idee, Kommandos wie »cat /dev/sda1« auszuführen, würde der komplette Inhalt der ersten Partition auf der ersten Festplatte am SCSI-Bus im Log landen.

Die Möglichkeit über das Output-Log eine Art DoS-Attacke zu fahren, leuchtet vermutlich jedem ein. Ich empfehle daher dringend, nicht pauschal die Ausgabe von Prozessen zu loggen, sondern über einzelne Regeln nur ausgewählte Kommandos aufzuzeichnen. Das geschieht per Flag »LOG_OUTPUT« im Cmnd_Alias.

Abbildung 4: Das Sudo-Input-Log protokolliert Eingaben.

Weniger offensichtlich ist die Möglichkeit, Festplatten per Input-Log zu füllen. Dementsprechend sollten Sie auch beim Input aufpassen. Bei mir im Unternehmen ist der root-Zugang per SSH standardmäßig gesperrt. SSH-Logins erfolgen ausschließlich per personalisiertem User und Public-Key-Authentication. Soweit so gut. Benötigen Kollegen oder Kolleginnen größere Dateien auf einem Server (etwa DB-Dumps, größere Executables und so weiter), laden sie die Dateien üblicherweise per SCP/SFTP hoch.

In den Home-Verzeichnissen der User gibt es gewöhnlich nicht genügend Platz, dass man Hunderte GBytes an Daten dorthin schaufeln könnte. Deswegen kam die Idee auf, dass man die Uploads via SCP/SFTP mit eingeschachteltem Sudo bewerkstelligen könnte. Das ist tatsächlich möglich. Unter SLES kann ich Dateitransfers über den folgenden Befehl [2] bei gesperrtem root-User unter Zuhilfenahme von Sudo mit privilegierten Rechten vornehmen.

sftp -s "sudo /usr/lib/openssh/sftp-server" user@hostname

Der sftp-Schalter »-s« weist dabei den SSH-Server an, das Subsystem für sftp durch das nachgestellte Kommando zu ersetzen. Damit läuft der ad-hoc gestartete SFTP-Server mit elevated rights, und der Kollege oder die Kollegin kann lesen und schreiben, wo er oder sie möchte.

Was ein wenig nach Magie aussieht, hat unglücklicherweise einen gewaltigen Pferdefuß: In diesem Konstrukt erhält der per Sudo gestartete SFTP-Server seine Daten von der Standard-Eingabe stdin, was durch das Sudo-Input-Log protokolliert wird. Im ungünstigsten Fall kann es also passieren, dass bei einem solchen Aufruf Hunderte GBytes im Protokoll von Sudo landen. Im Umkehrschluss ist also auch beim Input-Logging hohe Sorgfalt angeraten. Viel einfacher ist es, einen entsprechenden Upload-Ordner für die betreffenden User als les- und beschreibbar zu deklarieren – und die Dateien eben ohne Sudo hochzuladen.

Fazit

Hinter Sudo steckt definitiv mehr als ein blanker Ersatz für »su«. Es befähigt Administratoren nicht nur dazu, sehr differenziert einzelne Benutzer, sondern auch Gruppen mit erweiterten Rechten auszustatten. Sie müssen keine root-Kennwörter mehr an Applikations-Admins herausgeben, sondern schalten schlicht die relevanten Kommandos frei. Wildcard-Regeln wie »userxy ALL=(ALL:ALL) ALL« kann ich problemlos vermeiden, wenn ich weiß, welche Kommandos unter welchem User ein Kollege oder eine Kollegin braucht.

Wer protokollieren möchte, sollte tunlichst auf Sinn und Zweck des Ganzen achten, sowie auch darauf, dass überprivilegierte User selbstverständlich ihre eigenen Logs löschen können. Wenn mir meine Logs wichtig sind und ich unbedingt verhindern möchte, dass jemand sie manipuliert, muss ich zwangsläufig auf ein dediziertes Log-System loggen, auf das die jeweiligen User keinen Zugriff haben. (csi)