staging.inyokaproject.org

kB schrieb:

Es gibt gar kein Problem, weil gedit ja nicht als root und auch nicht mit Root-Rechten aufgerufen wird, sondern ganz normal vom aufrufenden Benutzer ausgeführt wird. Im Gegenteil stellt dieses Beispiel eine empfehlenswerte Methode dar, Systemdateien gefahrlos zu bearbeiten.

Ok, gut und danke! Jetzt werden wir - immer noch das gleiche Beispiel - eine Stufe leichtsinniger und machen:

• sudo -H gedit /etc/default/grub 

• dort eine Variable anpasse

• dann speichere und schließe die Datei

Bitte dabei wieder konkret am Beispiel bleiben. Ich mache nichts anderes als eine Datei, für deren Bearbeitung ich Root-Rechte benötige, kurz zur Bearbeitung zu öffnen. Ich ändere vielleicht noch die Größe des gedit-Fensters, aber sonst nehme ich an gedit kein Umstellungen der Einstellungen vor.

Wo liegt in diesem konkreten Fall das Problem?

LG, Newubunti

Hallo,

die Datei bzw. deren Edit ist auch nicht das potentielle Problem, sondern das gedit mit Root-Rechten gestartet wird. Details: siehe mein vorheriger Post.

Gruß, noisefloor

Hallo,

ich nutze sudo -H seit Jahren erfolgreich mit Programmen wie Gedit, Pluma, Geany, Meld, Nautilus, Dolphin etc., wenn ich Systemdateien bearbeite, und habe noch nie ein Problem dadurch beobachtet.

Stellt sich die Frage: bist du bzw. dein System der repräsentative Durchschnitt oder bist du die glückliche Randgruppe?

Da das ja überall für soooo gefährlich gehalten wird, kann das denn mal jemand konkret erläutern, worin die Gefahr konkret besteht und auf welchem technischen Hintergrund?

Siehe mein vorheriger Post. Es wäre schon hilfreich, wenn man hier mitdiskutiert, dass man andere Posts und Links darin auch liest.

Wie oft die Probleme tatsächlich auftauchen → Supportforum durchsuchen oder Supporterfragen.

Gruß, noisefloor

noisefloor schrieb:

Stellt sich die Frage: bist du bzw. dein System der repräsentative Durchschnitt oder bist du die glückliche Randgruppe?

Na dann bin ich ja ausnahmsweise mal regelmäßig in einer glücklichen Situation.

Siehe mein vorheriger Post. Es wäre schon hilfreich, wenn man hier mitdiskutiert, dass man andere Posts und Links darin auch liest.

Hatte ich, keine Sorge. Ich finde da aber keine konkret technische Begründung und ansonsten nur Vermutungen wie:

a) dass sich ggf. Dateirechte im Homeverzeichnis des Nutzers ändern können, was später zu Problemen führen kann (kann man ggf. durch die Option -H abdämpfen)

... und genau dieses Problem kann man durch sudo -H umgehen, und noch umfassender über Nemo → "Als Systemverwalter öffnen".

und b) viele GUI-Programme nicht für die Nutzung mit Root-Rechten getestet sind

... auch das ist nur eine Vermutung. Allein meine Erfahrung als "glückliche Randgruppe" legt das Gegenteil nahe.

Wie oft die Probleme tatsächlich auftauchen → Supportforum durchsuchen oder Supporterfragen.

Darüber habe ich leider keinen Überblick. Kannst Du mir denn mal ein Beispiel zeigen / verlinken, damit ich nachvollziehen kann, was da außer dem "owner root im Homverzeichnis"-Problem sonst noch so passiert ist?

noisefloor schrieb:

... Details: siehe mein vorheriger Post.

Wenn man nach der Argumentation geht, stellt sich aber dann schon die Frage, warum so ein Befehlsaufruf dann vom System überhaupt zugelassen wird.

Und ob Terminal-Programme immer alle einem ständigen Sicherheits-Audit unterliegen zweifle ich auch mal. Und ja, ich sehe einen großen Unterschied, wenn bei GUI-Prorammen noch der ganze Code Zwecks eben Darstellung dieser GUI läuft. Ich sehe das dadurch erhöhte Risiko schon.

Außerdem geht es in dem von Dir verlinkten Thread generell um die Ausführung von GUI-Programmen unter Root. Meine Frage bezog sich auf eine konkrete administrative Aufgabenstellung bei Verwendung eines grafischen Texteditors. Da ist schon noch mal ein Unterschied.

Wenn man der Argumentation aus dem Thread folgt, dann sollte man konsequenter Weise gar keine GUI nutzen, weil dann die Angriffsvektoren noch deutlicher eingeschränkt werden.

Damit wir uns nicht missverstehen: Ich vertrete hier nicht den Standpunkt, man könne ruhig mit sudo -H gedit arbeiten. Es gibt ja die schon genannten Alternativen.

Mir geht es um vernünftige, nachvollziehbare Erklärungen anhand konkreter Anwendungsbeispiele - eventuell auch in einem Unterartikel, mit beispielsweise dem Titel "Wo liegen die Probleme beim Arbeiten mit Root-Rechten".

Die Argumentation im verlinkten Thread ist halt einfach ein totschlag-Argumentation. Code der nicht ausgeführt wird, kann auch keine (Sicherheits-)Probleme verursachen. Das kann man natürlich nicht wiederlegen, ist mir aber auf meine konkrete Frage hin zu plump.

Nach der Argumentation lassen wir unsere Rechner einfach aus.

LG, Newubunti

UlfZibis schrieb:

…nutze sudo -H seit Jahren erfolgreich mit Programmen wie … Dolphin…

Bist du sicher, dass du da nicht zu viel Vergangenheit im Kopf hast? sudo mit grafischen Qt-Programmen geht schon ewig nicht mehr und sogar unter K/Ubuntu, unter dem das viel länger ging, muss man eine PolKit-Lücke reaktivieren, um das überhaupt startbar zu bekommen.

Abgesehen von den Sicherheitslücken wie das überschreiben von Speicherbereichen (anderer Nutzer) hat root nunmal keine grafische Oberfläche und das Erzwingen kann diverse ungewollte Seiteneffekte haben. Daher wurden ja kdesu und gksudo abgeschafft, der XServer nicht mehr als root gestartet, etc.
Natürlich ist es möglich einfache grafische Programme weiter als root zu starten (über xhost, ssh, setuid, wasauchimmer), sinnvoller wird es dadurch aber nicht. Die direkt spürbaren Seiteneffekte sind meist die berühmten verbogenen Rechte, Probleme mit Grafikdarstellung, undefinierte Crashes (Segmentation Fault durch nicht mehr zugreifbaren Speicher), ein crashender oder falsch funktionierender DBus der für die Interprozesskommunikation zuständig ist, ändern der xdg-Standards und/oder /run/user, usw.

Um die Systeme stabiler zu machen, wurden Routinen einprogrammiert, die auf sowas prüfen. Ich kenne das allerdings nur von Qt, welches sich bspw. bei gesetztem setuid-bit oder dergleichen weigern zu starten (lässt sich auch umgehen). Aktuell wird in den „großen Frameworks“ ein PolicyKit-Wrapper eingesetzt, um für bestimmte Aufgaben erweiterte Rechte zu ermöglichen, wie bspw. bei GParted und sowas.

Idealerweise nutzt man also mit sudo -H Programme, die nicht in die Desktopumgebung eingebettet sind und ihre eigene Konfiguration brav unter /root/ ablegen, keine Desktopintegration haben, usw., um die ganze Wechselwirkung mit laufenden Prozessen zu verhindern. Bleibt das Problem mit dem Grafikserver, der dem Nutzer mit rootrechten entzogen wird. Kann klappen, muss aber nicht.

Als harmloseres Beispiel kann man sudo gedit aufrufen, die Editor-Einstellungen ändern und dann beenden. Danach als Nutzer versuchen diese wieder zurück zu ändern.

ChickenLipsRfun2eat schrieb:

Um die Systeme stabiler zu machen, wurden Routinen einprogrammiert, die auf sowas prüfen. Ich kenne das allerdings nur von Qt, welches sich bspw. bei gesetztem setuid-bit oder dergleichen weigern zu starten (lässt sich auch umgehen). Aktuell wird in den „großen Frameworks“ ein PolicyKit-Wrapper eingesetzt, um für bestimmte Aufgaben erweiterte Rechte zu ermöglichen, wie bspw. bei GParted und sowas.

Und was ist, wenn auch Nemo mit "Als Systemverwalter öffnen" genau dasselbe macht? Ist nur eine Vermutung, ich weiß, es spricht aber auch nichts dagegen. Dafür spricht auf jeden Fall sie damit ermöglichte komfortable Arbeitsumgebung.

Und ich verstehe ja nicht, warum Du immer noch mit sudo ohne -H argumentierst, das ist doch klar, dass das schief geht.

UlfZibis schrieb:

Und was ist, wenn auch Nemo mit "Als Systemverwalter öffnen" genau dasselbe macht? Ist nur eine Vermutung, ich weiß, es spricht aber auch nichts dagegen. Dafür spricht auf jeden Fall sie damit ermöglichte komfortable Arbeitsumgebung.

Ich weiß nicht, wie das genau funktioniert. Vermutlich über PolicyKit, müsstest du mal nachgucken. Ähnliches gibt es für Krusader, funktioniert aber nur noch, wenn man die potentielle Sicherheitslücke im PolicyKit wieder reaktiviert. Das wäre aber „nur“ für die Sicherheit relevant, also bspw. schädliche Plugins die auf erweiterte Rechte warten, etc.

Und ich verstehe ja nicht, warum Du immer noch mit sudo ohne -H argumentierst, das ist doch klar, dass das schief geht.

Weil ich ein einfaches Beispiel wollte, welches kein globales Chaos anrichtet 😉 -H könnte auch schon Standard sein und hält auch die meisten Probleme fern, aber eben nicht alle (wie Speicherbereiche überschreiben, DBus- und Session-Probleme, etc.)
Du könntest dir natürlich auch eine komplexere GUI schnappen und rumexperimentieren. Der KDE-KWin-Martin-Flöser (https://martin-graesslin.com) hat damals mal eine XTest-extension geschrieben, die darauf wartete das Dolphin als root gestartet wurde — natürlich ohne Schaden, nur als Beispiel. Finde aber gerade nur Verweise auf https://blog.martin-graesslin.com/blog/2017/02/editing-files-as-root/, in dem das erwähnt aber nicht gezeigt wird. Ist sowieso mittlerweile obsolet.

Gründe wieso man grafische Programme nicht als root laufen lassen sollte gibt es wie Sand am Meer (je nach verwendetem Framework andere) und im Zuge der Einführung von Wayland auf Desktop-System wollte man genau das anpacken und generell vermeiden. Stößt aber auf wenig Gegenliebe, da viele den Sinn hinter getrennten Benutzern nicht erkennen wollen und „GUI-Systeme sind nicht darauf ausgelegt als root zu laufen“ auch nicht jeder liebt.

Hier geht es zudem um Einsteiger und da finde ich admin:/// und sudoedit völlig ausreichend. Damit hast du auch root-Rechte, aber das GUI-Programm läuft als Benutzer.

//Nachtrag:
Vergessen: Wenn du ein GUI-Programm mit sudo -H startest, prüfe mal die Umgebungsvariablen. Mindestens XAUTHORITY zeigt noch auf deinen Nutzer,

Hallo

Nachtrag zu heute Mittag: mit gedit admin:///etc/default/grub läuft gedit mit erhöhten Rechten in der Wayland Session und fällt nicht auf X zurück. sudo gedit oder sudo -H ... fällt auf Xwayland zurück. Ich gehe mal stark davon aus, dass das im ersten Fall mit der Nutzung von Polkit zu tun hat.

Gruß, noisefloor

ChickenLipsRfun2eat schrieb:

Hier geht es zudem um Einsteiger und da finde ich admin:/// und sudoedit völlig ausreichend.

Da gehe ich im Ergebnis mit.

Damit hast du auch root-Rechte, aber das GUI-Programm läuft als Benutzer.

Das wiederum könnte/sollte IMO etwas schärfer herausgearbeitet werden.

Auch der Titel des Artikels führt nachdem, wie ich zumindest sudoedit verstehe, irgendwie in die Irre. Ich arbeite doch bei sudoedit gerade nicht mit Root-Rechten, sondern diese werden nur auf das notwendigste reduziert, zum Schreiben des Ergebnisses beim Schließen des Editors angefordert und eingeräumt. Oder habe ich da etwas falsch verstanden?

Im Prinzip geht es doch hier im wesentlichen um die Bearbeitung von Systemdateien mit geringstmöglichem Risiko, oder sehe ich das falsch?

Was mich davon abgesehen an der Diskussion um z.B. sudo -H gedit stört ist, dass man hier als Fragender munter zwischen Sicherheit und Systemstabilität hin und her geschleudert wird. Es kommt einem zu weilen so vor, als würden die Argumente so lange zu Recht gebogen, bis sie am Ende zu der Aussage "mache das auf gar keinen Fall" passen.

LG, Newubunti

ChickenLipsRfun2eat schrieb:

Hier geht es zudem um Einsteiger und da finde ich admin:/// und sudoedit völlig ausreichend. Damit hast du auch root-Rechte, aber das GUI-Programm läuft als Benutzer.

Da "Systemdateien Ändern" und überhaupt Root-Rechte ja nicht nur ein Einsteiger-, sondern vor allem ein Experten-Thema sind ... wie wär's denn, meinen "Königsweg" in einer Expertenbox zu präsentieren, mit allen verfügbaren deutlichen Zeigefingern auf Risiko und Gefahr gerichtet?

Vergessen: Wenn du ein GUI-Programm mit sudo -H startest, prüfe mal die Umgebungsvariablen. Mindestens XAUTHORITY zeigt noch auf deinen Nutzer,

Wie geht das, also wie soll ich im mit sudo -H gestarteten GUI-Fenster dessen Umgebungsvariablen anzeigen lassen?

Newubunti schrieb:

Was mich davon abgesehen an der Diskussion um z.B. sudo -H gedit stört ist, dass man hier als Fragender munter zwischen Sicherheit und Systemstabilität hin und her geschleudert wird. Es kommt einem zu weilen so vor, als würden die Argumente so lange zu Recht gebogen, bis sie am Ende zu der Aussage "mache das auf gar keinen Fall" passen.

👍 👍 👍

UlfZibis schrieb:

[…] wie wär's denn, meinen "Königsweg" in einer Expertenbox zu präsentieren

Dein „Königsweg“ ist kein solcher, denn

1. Du gehst von falschen Voraussetzungen aus, was sudo -H verhindern würde (weniger als Du denkst),

2. und das Programm Nemo mit dieser tollen Option, der Du vertraust, gibt es gar nicht auf allen Desktops und Standard ist es wohl nur beim Derivat Budgie.

Dein Privatweg ist nicht Wiki-tauglich.

Abschnitt „Root-Rechte für grafische Programme mit Wayland“ überarbeitet.

Newubunti schrieb:

Das wiederum könnte/sollte IMO etwas schärfer herausgearbeitet werden.

Inwiefern? Wie das technisch funktioniert? Wie man das manuell nachstellen kann? Finde ich für den Artikel irrelevant. Du kannst aber sowas wie

cp /etc/fstab /tmp/
gedit /tmp/fstab
sudo mv /tmp/fstab /etc/fstab

verwenden, um ein ähnliches Verhalten zu erreichen.

Im Prinzip geht es doch hier im wesentlichen um die Bearbeitung von Systemdateien mit geringstmöglichem Risiko, oder sehe ich das falsch?

Sehe ich auch so. Dafür gibt es in jeder Umgebung Wege.

… zwischen Sicherheit und Systemstabilität hin und her geschleudert wird…

Ich habe die Sicherheit bislang außen vor gelassen. Es ist logisch, das grafische Anwendungen mit Rootrechten stets Vollzugriff aufs System haben und damit alles und unter allen Benutzern manipulieren können und das somit eine Sicherheitskatastrophe ist. Ich habe mich auf die Stabilität beschränkt, die beeinträchtigt wird, da root keine grafische Umgebung hat und somit die des Nutzers übernimmt. Es wäre ja theoretisch möglich sich als root einzuloggen und eine komplette grafische Umgebung als solcher zu starten — allerdings wird auch das immer weniger unterstützt, eine DE würde ich da nicht mehr versuchen wollen. Das wäre dann auch ein Sicherheitsalbtraum, hätte aber keine direkten negativen Konsequenzen für den Nutzer und dessen Daten.

UlfZibis schrieb:

Da "Systemdateien Ändern" und überhaupt Root-Rechte ja nicht nur ein Einsteiger-, sondern vor allem ein Experten-Thema sind ... wie wär's denn, meinen "Königsweg" in einer Expertenbox zu präsentieren, mit allen verfügbaren deutlichen Zeigefingern auf Risiko und Gefahr gerichtet?

Der Weg funktioniert noch, ist aber auch nur ein Workaround (siehe https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/626), daher auch die XWayland-Komponente. Das wird so lange bestehen, bis die meisten Programme sich auf die Trennung zwischen GUI und Rechten eingestellt haben (Verwendung eines daemons, separate Executables,…).

Wie geht das, also wie soll ich im mit sudo -H gestarteten GUI-Fenster dessen Umgebungsvariablen anzeigen lassen?

Z.B. wenn das Programm das über dessen debugging kann, prinzipiell die Ausführung von env, das alle exportierten Variablen auflistet. Alternativ und genauer wäre das mit Debuggern wie GDB.

ChickenLipsRfun2eat schrieb:

Newubunti schrieb:

Das wiederum könnte/sollte IMO etwas schärfer herausgearbeitet werden.

Inwiefern? Wie das technisch funktioniert? Wie man das manuell nachstellen kann? Finde ich für den Artikel irrelevant.

Mir geht es hier um eine möglichst leicht verständliche sauber differenzierte Darlegung der Problemlage - möglichst auch anhand von ein paar Praxisbeispielen.

• Also klare Unterscheidung zwischen Problem für die Systemstabilität und Problemen für die Systemsicherheit

• Welche Risiken gibt es unter den zuvor genannten beiden Gesichtspunkten

• Risiken anhand einiger üblicher, typischer Administrationsaufgaben abwägen/beschreiben.

Wie ich schon weiter oben schrieb, sehe ich das aber besser in einem Unterartikel dieses Artikels aufgehoben.

Weil bei diesem Thema ist es zunächst schon mal wichtig, dass klar und unmissverständlich dargestellt wird, wie es richtig und sagen wir noch besser, so sicher wie möglich gemacht wird.

Was man in dem Artikel hier noch kurz schreiben könnte ist, ob beispielsweise

VISUAL=gedit sudoedit /etc/default/grub 

und

gedit admin:///etc/default/grub 

gleich vorgehen.

Und sollte man nicht generell nur noch

sudoedit DATEI 

statt

sudo -H nano DATEI 

im Wiki empfehlen? Das hat ja auch den Vorteil, dass es universeller ist.

… zwischen Sicherheit und Systemstabilität hin und her geschleudert wird…

Diese Aussage war übrigens nicht auf Deine Argumentation hier gemünzt, sondern ist mehr allgemein zu verstehen, wie - insbesondere von der Anwender-Community - gerne nach belieben hin- und herargumentiert wird.

Ich habe die Sicherheit bislang außen vor gelassen.

Das finde ich auch sachdienlich und lobenswert!

Es ist logisch, das grafische Anwendungen mit Rootrechten stets Vollzugriff aufs System haben und damit alles und unter allen Benutzern manipulieren können und das somit eine Sicherheitskatastrophe ist.

Da würde ich mich gerne darauf einigen, dass es generell aus Sicherheitsperspektive sinnvoll ist, die Verwendung von Root-Rechten auf das notwendigste zu beschränken. Egal ob GUI oder Terminal. Dass der ganze zusätzliche Code und die erhöhte Komplexität der GUI-Darstellung gegenüber der Terminal-Darstellung zusätzliche, potentielle Angriffsvektoren für die Dauer der Ausführung bietet bzw. bieten kann, wird niemand der sich für das Thema interessiert, bestreiten wollen.

Das folgende bezieht sich nicht speziell auf den bis dahin zitierten Beitrag von ChickenLipsRfun2eat, sondern geht noch mal allgemeiner auf das Hin- und Herschleudern ein:

Auf der anderen Seite ist es in der Argumentation schon schizophren, wenn dem Leser - und insbesondere Neueinsteiger bekommen den gern vorgesetzt - mit großen Enthusiasmus unter anderem das hier erklärt wird:

Virenscanner,

dann kommt der Anwender, wie auch immer, auf die Idee einen grafischen Editor mit Rootrechten zu öffnen - was z.B. wenn man wie für gedit suchmaschinelt (Keywords: "run gedit as root") - zu diesem Ergebnis ziemlich weit oben führt,

https://help.gnome.org/users/gedit/stable/gedit-edit-as-root.html.en

und dann bekommt der Leser - wieder von einer anderen Seite - vor den Latz geknallt, dass er sich damit ein riesiges Sicherheitsloch reist.

Da würde ich als Leser denken: "Ihr habt doch nicht mehr alle Latten am Zaun!"

Und um das festzuhalten: Ich bin dafür, mit Rootrechten so sparsam wie möglich umzugehen!!!

Aber die Argumentationslinien rund um das Thema, sind mir zuweilen bis häufig zu wenig sachlich und haben teilweise etwas von Panikmache - wenn man es dann auf konkrete Beispiele herunterbricht. Und siehe eben mein konkretes Beispiel von oben mit dem sudo -H gedit /etc/default/grub.

Und nein, daraus leite ich nicht ab, dass man sudo -H gedit /etc/default/grub könne man ruhig auch machen.

In aller Regel reden wir hier über Ubuntu-Endanwender-Desktops. Da ist das höchste Gut in der Regel der Datenbestand unter /home. Und für den Zugriff darauf braucht kein Angreifer Root-Rechte.

Das zweit höchste Gut für den normalen Endanwender dürfte die Systemstabilität sein. Der ist froh, wenn sein System möglichst stabil läuft und keine Probleme macht.

Auf Sicherheitsrisiken hinweisen ist richtig und wichtig. Darüber hinaus den Teufel an die Wand malen erfahrungsgemäß eher kontraproduktiv.

LG, Newubunti