Grafische Anwendung als root starten

Warnung

Alle folgenden Methoden haben Auswirkungen auf die Sicherheit, die Benutzer kennen sollten. Wie [von Emmanuele Bassi, einem GNOME-Entwickler, https://bugzilla.gnome.org//show_bug.cgi?id=772875#c5 beschrieben

[...] es gibt keine *echten*, fundierten, technologischen Gründe, warum jemand eine GUI-Anwendung als root ausführen sollte. Wenn Sie GUI-Anwendungen als Admin-Benutzer ausführen, führen Sie buchstäblich Millionen von Codezeilen aus, die nicht ordnungsgemäß auf die Ausführung mit erhöhten Berechtigungen geprüft wurden. Sie führen auch Code aus, der Dateien in Ihrem $HOME berührt und möglicherweise deren Eigentümer im Dateisystem ändert. Sie stellen über IPC eine Verbindung zu noch mehr ausgeführtem Code her usw.

Sie öffnen eine riesige, klaffende Sicherheitslücke [...].

Vermeiden Sie es, grafische Anwendungen nach Möglichkeit als root auszuführen, siehe #Umgehen der Ausführung grafischer Anwendungen als root.

Umgehen der Ausführung grafischer Anwendungen als root

sudoedit

Um Dateien als root zu bearbeiten, verwenden Sie sudoedit.

GVFS

Der Zugriff auf privilegierte Dateien und Verzeichnisse ist über GVFS möglich, indem der Vorlage:Ic backend im URI-Schema [1][2] angegeben wird, z. B.:

$ nautilus admin:///root/

oder

$ gedit admin:///etc/fstab

Dies kann auch über die Adressleiste/Dateiauswahl der Anwendung erfolgen: Geben Sie z. B. in „nautilus“ oder „gedit“ „Strg+l“ ein und stellen Sie dann dem Ressourcenpfad das Schema „admin://“ voran. Der gleiche Effekt kann über die Server-Adressleiste Other locations erzielt werden.

Xorg

Standardmäßig und aus Sicherheitsgründen kann root keine Verbindung zum X-Server eines Nicht-Root-Benutzers herstellen. Es gibt jedoch mehrere Möglichkeiten, root dies zu ermöglichen, falls erforderlich.

Die richtige und empfohlene Methode, GUI-Anwendungen unter X mit erweiterten Rechten auszuführen, ist die Erstellung einer Polkit-Richtlinie, wie in diesem Forumsbeitrag gezeigt. Dies sollte jedoch „nur für Legacy-Programme verwendet werden“, wie „pkexec“ erinnert. Anwendungen sollten die privilegierten Vorgänge lieber „auf einen überprüfbaren, in sich geschlossenen, ‚‘‚minimalen‘‚‘ Codeabschnitt verschieben, der nach einer Privilegienerweiterung ausgeführt und gelöscht wird, wenn er nicht benötigt wird“ [3]. Dies kann Gegenstand eines Fehlerberichts an das Upstream-Projekt sein.

Punktuelle Methoden

Diese Methoden hüllen die Anwendung in ein Elevation-Framework und heben die erlangten Privilegien nach dem Beenden wieder auf:

kdesu (aus kde-cli-tools)

$ kdesu Anwendung

sudo (muss richtig konfiguriert sein)

$ sudo Anwendung

sux (Wrapper um su, der Ihre X-Anmeldedaten überträgt)

$ sux root Anwendung

Alternative Methoden

Diese Methoden ermöglichen es root, sich mit dem X-Server eines Nicht-root-Benutzers zu verbinden, bergen jedoch unterschiedliche Sicherheitsrisiken, insbesondere wenn Sie ssh ausführen. Wenn Sie sich hinter einer Firewall befinden, können Sie davon ausgehen, dass sie für Ihre Anforderungen sicher genug sind.

Xhost

Mit Xhost kann der Root-Zugriff vorübergehend zugelassen werden.

Root-Zugriff dauerhaft zulassen

Methode 1

Fügen Sie die Zeile session optional pam_xauth.so

zu /etc/pam.d/su und /etc/pam.d/su-l hinzu. Wechseln Sie dann mit su oder su - zum Root-Benutzer.

Methode 2

Fügen Sie global in /etc/profile

die folgende Zeile zu /etc/profile hinzu:

/etc/profile

export XAUTHORITY=/home/username/.Xauthority

Dadurch kann root dauerhaft eine Verbindung zum X-Server eines Nicht-root-Benutzers herstellen.

Oder geben Sie einfach eine bestimmte Anwendung an

XAUTHORITY=/home/username/.Xauthority appname

wobei appname der Name der jeweiligen Anwendung ist. (z. B. kwrite)

Wayland

Der Versuch, eine grafische Anwendung als root über su, sudo oder pkexec in einer Wayland-Sitzung (z. B. GParted oder Gedit auszuführen, schlägt mit einer Fehlermeldung ähnlich der folgenden fehl:

Vorlage:Hc

Vor Wayland konnte die Ausführung von GUI-Anwendungen mit erhöhten Berechtigungen ordnungsgemäß durch die Erstellung einer Polkit-Richtlinie implementiert werden, oder gefährlicher durch die Ausführung des Befehls in einem Terminal, indem dem Befehl „sudo“ vorangestellt wurde; aber unter (X)Wayland funktioniert dies nicht mehr, da standardmäßig nur der Benutzer, der den X-Server gestartet hat, Clients mit diesem verbinden darf (siehe bug report und the [https:// gitlab.freedesktop.org/xorg/xserver/-/commit/4b4b908 upstream] commits it refers to).

Vermeiden Sie es, grafische Anwendungen nach Möglichkeit als root auszuführen, siehe #Umgehen der Ausführung grafischer Anwendungen als root.

Eine vielseitigere, wenn auch unsicherere Lösung besteht darin, jede grafische Anwendung als root auszuführen #Verwendung von xhost.

Verwendung von xhost

Erwähnen Sie, dass xhost nur unter Xwayland funktioniert.

Eine vielseitigere – wenn auch viel weniger sichere – Lösung besteht darin, xhost zu verwenden, um dem Root-Benutzer vorübergehend den Zugriff auf die X-Sitzung des lokalen Benutzers zu ermöglichen [4]. Führen Sie dazu den folgenden Befehl als aktueller (nicht privilegierter) Benutzer aus:

$ xhost si:localuser:root

Um diesen Zugriff nach dem Schließen der Anwendung zu entfernen:

$ xhost -si:localuser:root

Verwendung von sudo -E

Sie können eine Anwendung mit folgendem Befehl starten:

$ sudo -E Programm

wodurch Umgebungsvariablen wie WAYLAND_DISPLAY erhalten bleiben.

Wenn Sie möchten, dass die Umgebungsvariable HOME auf den Zielbenutzer gesetzt wird, verwenden Sie:

$ sudo -EH Programm

Siehe man sudo(8)

Verwendung von pkexec

Sie können eine GUI-Anwendung mit folgendem Befehl starten: $ pkexec env WAYLAND_DISPLAY=„$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY“ XDG_RUNTIME_DIR=/run/user/0 program

wodurch die Umgebungsvariable WAYLAND_DISPLAY erhalten bleibt.