5 Programme, die man nicht als root ausführen können sollte

Wer die Verwendung des root-Benutzers unter Linux einschränken möchte, wird wahrscheinlich entsprechende sudo-Regeln erstellen, um administrative Kommandos entsprechenden Benutzern zur Verfügung zu stellen. Dabei gibt es einige prominente Programme, die man keineswegs als privilegierter Benutzer ausführen können sollte – einige Beispiele:

screen, tmux

Die beliebten Terminal-Multiplexer GNU Screen und tmux erzeugen beim Start einer neuen Sitzung eine neue Login-Shell und sollten daher auf keinsten Fall mit Root-Rechten ausgeführt werden können:

$ sudo screen
# whoami
root

Der eindeutig bessere Ansatz ist es, den Multiplexer mit herkömmlichen Rechten zu starten und innerhalb der einzelnen Fenster administrative Sitzungen zu pflegen.

vi(m)

Die Editoren vi bzw. Vi IMproved bieten zahlreiche Funktionen – unter anderem die Möglichkeit, Prozesse zu starten (:!) oder die Ausgabe von Prozessen in das aktuelle Dokument zu übernehmen (:r!). Wenn es möglich ist, den Editor mit Root-Rechten zu starten, kann so schnell eine Root-Shell geöffnet werden:

$ sudo vim myfile
ESC
:!bash
# whoami
root

Die meisten vi-/vim-Installationen beinhalten ebenfalls die rvi– und rvim-Kommandos, welche diese Funktion nicht anbieten (restricted vi/vim). Wenn diese Editoren als root ausgeführt werden sollen, ist es möglich, stattdessen die eben erwähnten Alternativen zu verwenden.

more, less, view

Zum Anzeigen von Protokolldateien und anderen Dokumenten werden meistens die Programme more bzw. less und manchmal auch view verwendet. Häufig wird jedoch vergessen, dass diese Programme mit einem Tastendruck auf v den Editormodus mittels vi bzw. vim aktivieren. Auch hier lässt sich wieder leicht eine Root-Shell starten:

$ sudo less /var/log/messages
ESC
:!bash
# whoami
root

Wer less beim Einsatz einer quellenbasierten Linux-Distribution, wie beispielsweise Gentoo oder CRUX, selbst kompiliert, kann diese Funktion bei der Übersetzung deaktivieren (–with-secure). Alternativ lässt sich eine Umgebungsvariable LESSSECURE auf 1 setzen, um das Verhalten zu deaktivieren – jedoch ist es bekanntlicherweise keine große Herausforderung, eine Shell-Variable zu ändern. Bei more kann dieses Verhalten nicht deaktiviert werden.

Eine weitere Option wäre es, rview statt view zu verwenden.

scl

Red Hat Software Collections (SCL) kann nicht nur dazu verwendet werden, alternative Programmversionen zu verwalten – man kann es auch dazu verwenden, eine privilegierte Terminal-Sitzung zu starten:

$ sudo scl enable httpd24 bash
# whoami
root

find

find ist nicht nur in der Lage Dateien zu suchen – mithilfe des -exec-Parameters lassen sich gefundene Dateien auch ausführen. So kann es dazu verwendet werden, eine Root-Shell zu starten:

$ sudo find /bin -name bash -exec {} ;
# whoami
root

In manchen Fällen ist es aber unabdingbar, find als root auszuführen – was dann?

Abhilfe mit noexec

Alle oben genannten Schwachstellen verhalten sich aus Sicht des Betriebssystems gleich – es wird mittels der fork()– und execve()-Systemaufrufe ein weiterer Kindprozess gestartet. Beispielsweise für den find-Trick:

$ pstree
...
└─bash
   ├─find
      ├─bash

Innerhalb einer Bash-Sitzung wurde find ausgeführt, welches mittels sudo eine privilegierte Bash-Sitzung startete.

Dieses Verhalten lässt sich mithilfe des sudo-Parameters NOEXEC: verbieten – somit kann nur das ursprüngliche Programm privilegiert ausgeführt werden, weitere Unterprogramme lassen sich nicht starten. Ein Beispiel:

# vi /etc/sudoers.d/admins-editors
%admins    (ALL) = NOEXEC: /usr/bin/vi

Versuche eine Root-Shell zu starten, beispielsweise mit vi/vim, schlagen nun fehl:

$ sudo vi /etc/myapp.conf
ESC
:!bash

Cannot execute shell /bin/bash

Beim Einsatz von FreeIPA bzw. Red Hat Identity Management (IdM) muss der Parameter klein geschrieben (noexec statt NOEXEC:) werden – er wird auf Regel-Ebene angewendet, ein Beispiel:

FreeIPA_sudo_noexec

10 Kommentare Schreibe einen Kommentar

  1. Interessanter Artikel – vor Allem interessant, da ich auf keinem Server normalerweise sudo installiere und somit keines der beschriebenen Sicherheitsprobleme habe 😀

    Aber gut zu wissen, dass es so leicht ist „auszubrechen“. Hab mir über diese Szenarion noch keine Gedanken gemacht (wegen Mangel an sudo).

    • Hey Andreas,
      danke für das Feedback!

      Wenn nur eins, zwei Benutzer einen Server administrieren geht das sicherlich auch ohne sudo – das hast Du Recht. Aber wenn man mehrere Teams mit unterschiedlichen Befugnissen und Verantwortlichkeiten hat, kommt man da nicht drum herum. Die größte Hürde ist es, den Kunden beizubringen, dass sie jetzt eben nicht „root“ haben und im Fehlerfall mit dem Finger auf den Administrator zeigen können. 😀

      Grüße!

      • Ja, das stimmt wohl. Meistens setze ich – wenn es mal mehr werden – immer auf Container oder „richtige“ VMs mit Firewall drumherum, dann bin ich die Sorgen los 😀

      • Das ist schön, wenn das so einfach bei dir/euch zu regeln ist – beneidenswert. 😀
        Bei uns gibt es feste Stammabteilungen und eben jeweils klare Pflichten/Rechte pro Team.

        Container ist ein gutes Stichwort – das müsste ich mir auch mal näher im Detail anschauen.. 🙂

  2. Es ist generell eine schlechte idee einem User zu erlauben einen Editor per sudo zu öffnen, da eigendlich jeder editor die möglichkeit bietet eine andere Datei zu öffnen. Damit hat man fast gewonnen, man muss jetzt nur noch aus einem der vielen Möglichkeiten wählen um root zu werden (/etc/passwd, /root/.ssh/authorized_keys, /etc/sudoers …). Wenn man wirklich einem normalen User Schreibrechte auf eine bestimmte Datei geben muss und file permissions/ACLs nicht gehen, kann man noch sudoedit benutzen.

    • Hey Phillip,
      ich stimme dir uneingeschränkt zu! In aller Regel steuere ich das auch lieber über ACLs – bei manchen Legacy-Anwendungen, die tief ins Betriebssystem verankert sind, ist es manchmal zu aufwändig, die ganzen Ausnahmen zu definieren. Aber schöner ist es auf jeden Fall, keine Frage.

      Beste Grüße!

  3. Hi Christian,

    für vi bitte immer sudoedit verwenden. Denn auch mit NOEXEC kann man ja einfach die shadow als root editieren.
    CU
    Jens

Schreibe einen Kommentar