Grafische Anwendung als root starten
Grafische Anwendung als root starten
Beschreibung
- 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 admin 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
Global in /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
# gedit Kein Protokoll angegeben Server kann nicht initialisiert werden: Verbindung konnte nicht hergestellt werden: Verbindung abgelehnt (gedit:2349): Gtk-WARNING **: kann Anzeige nicht öffnen: :0
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
Anhang
Siehe auch
Links
Weblinks