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:

1$ sudo screen
2# whoami
3root

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

vi / vim

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:

1$ sudo vim myfile
2ESC
3:!bash
4# whoami
5root

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:

1$ sudo less /var/log/messages
2ESC
3:!bash
4# whoami
5root

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:

1$ sudo scl enable httpd24 bash
2# whoami
3root

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:

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

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:

1$ pstree
2...
3└─bash
4   ├─find
5      ├─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:

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

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

1$ sudo vi /etc/myapp.conf
2ESC
3:!bash
4
5Cannot 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: