[gelöst] Gruppe sudo darf Synaptic ausführen auch wenn nicht in Sudoers

[c1ue]

Hi,

ich raffs nicht: Ich habe mittels visudo die Zeile

# Allow members of group sudo to execute any command
#%sudo ALL=(ALL:ALL) ALL

auskommentiert.

So weit so gut: Auf der Kommandozeile kann mein Benutzer nun keine Befehle mittles sudo mehr ausführen (mein Benutzer ist aber noch immer Mitglied der Gruppe sudo).

Aber selbst nach einem Neustart kann ich noch immer fröhlich synaptic mittels meines Beutzerpasswortes über die grafische Oberfläche starten.

Wieso geht das denn?

Erst wenn ich meinen Benutzer aus der Gruppe sudo rausnehme, geht das nicht mehr.

[Meillo]

``Sorry, Anfängerfrage'' war ein schlechter Titel. Er sagt ueberhaupt nichts ueber dein Problem aus. Ein Titel soll eine Kurzzusammenfassung des Problems sein und die wichtigsten Stichworte enthalten. Bitte versuche das naechste Mal daran zu denken.

[Meillo]

Mich wuerde auch interessieren, warum das so ist.

Davon abgesehen waere es aber wohl besser, statt die Zeile in der Config auszukommentieren, den betreffenen Nutzer aus der Gruppe sudo zu entfernen, wenn du erreichen willst, dass er sudo nicht nutzen soll.

[smutbert]

Das ist so, weil beim Start von synaptic gar nicht sudo genutzt wird.
(Der neue threadtitel ist also auch zumindest irreführend.)

Der Befehl, der in der GUI gestartet wird (synaptic-pkexec) nutzt policykit, um die notwendigen Rechte zu erlangen. policykit seinerseits macht ganz unabhängig davon wie sudo konfiguriert oder ob es überhaupt installiert ist unter anderem an der Mitgliedschaft der Gruppe sudo fest ob es nach dem Passwort des Benutzers oder dem von root fragt.
Um das zu ändern wären die Regeln von policykit der richtige Ansatzpunkt.

[MartinV]

Die Gruppe sudo ist eine andere Schublade als der Befehl sudo.
In /etc/sudoers wird definiert, wer wofür den Befehl sudo nutzen darf.
Die Gruppe sudo ist eine Administrator-Gruppe.

synaptic wird gewöhnlich mit pkexec gestartet, also ohne den Befehl sudo.
pkexec beachtet aber die Gruppe sudo und erlaubt sudo-Gruppen-Mitgliedern, mittels Benutzerpaßwort root-Rechte zu bekommen.

edit: smutbert war schneller.

[Meillo]

Das ist so, weil beim Start von synaptic gar nicht sudo genutzt wird.
(Der neue threadtitel ist also auch zumindest irreführend.)

Stimmt, da war ich nicht aufmerksam genug. Es steht ja da, dass `sudo' nicht mehr ausgefuehrt werden kann, Synaptic aber schon. Hab's nochmal angepasst.

Der Befehl, der in der GUI gestartet wird (synaptic-pkexec) nutzt policykit, um die notwendigen Rechte zu erlangen. policykit seinerseits macht ganz unabhängig davon wie sudo konfiguriert oder ob es überhaupt installiert ist unter anderem an der Mitgliedschaft der Gruppe sudo fest ob es nach dem Passwort des Benutzers oder dem von root fragt.
Um das zu ändern wären die Regeln von policykit der richtige Ansatzpunkt.

Es hat also ueberhaupt nichts mit sudo zu tun, bloss dass dessen Gruppe von Policykit zweckentfremdet wird, bzw. dass die Gruppe nach einem Programm und nicht fuer einen Zweck benannt worden ist. ... Folgen schlecher Designentscheidungen ...

[willy4711]

Ich möchte mal die ketzerische Frage stellen, warum Debian immer noch zweigleisig fährt (sudo / Policy Kit), obwohl das seit langem mir als
nicht mehr notwendig erscheint.
Seit über einem Jahr lebe ich in Debian Testing /Xfce wunderbar ohne Sudo / Gruppe Sudo / /etc/sudoers .
Vermisst habe ich noch nichts.
Sehr viele Programmen (zumindest die wichtigen) bringen inzwischen eigene Policies mit, die in /usr/share/polkit-1/actions/ versammelt sind.
Für einige wenige habe ich mir selbst eine Policy geschrieben, da ich halt gerne mit einem Klick aus dem Dateimanager (Thunar)
ohne viel Gehacke Aktionen ausführen möchte. z.B. um einen Datei mit Root- Rechten zu bearbeiten:

Code: Alles auswählen

pkexec sakura -x 'nano %F'

Ich habe bisher noch keinerlei Einschränkungen oder Nachteile beobachtet. Im Gegenteil, die leidige Diskussion über sudo oder nicht sudo
würde sich erübrigen.

[willy4711]

pkexec beachtet aber die Gruppe sudo und erlaubt sudo-Gruppen-Mitgliedern, mittels Benutzerpaßwort root-Rechte zu bekommen.

Interessant, ist mir neu: Wo wird das geregelt?
Aus der Policy von Synaptic:

Code: Alles auswählen

<defaults>
      <allow_any>auth_admin</allow_any>
      <allow_inactive>auth_admin</allow_inactive>
      <allow_active>auth_admin</allow_active>
    </defaults>
    <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/synaptic</annotate>
    <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>

[MartinV]

Interessant, ist mit neu: Wo wird das geregelt?

In welcher policy das steht, weiß ich nicht, ich kenne mich mit polkit nur wenig aus.
Es ist eine allgemeine Regel, nicht programmspezifisch. sudo-Gruppen-Mitglieder dürfen jedes beliebige Programm mit pkexec als root ausführen.

In der synaptic-policy ein möglicher Hinweis:

Code: Alles auswählen

      <allow_any>auth_admin</allow_any>

[willy4711]

Nach dem Manual:
https://www.freedesktop.org/software/po ... kit.8.html
wäre das nach meinem Verständnis eventuell

Code: Alles auswählen

auth_self

Beschreibung:

Authentication by the owner of the session that the client originates from is required.
Note that this is not restrictive enough for most uses on multi-user systems;
auth_admin* is generally recommended.

Das hat doch aber nichts mit sudo zu tun ?

[TomL]

Nach dem Manual:
https://www.freedesktop.org/software/po ... kit.8.html
wäre das nach meinem Verständnis eventuell

Code: Alles auswählen

auth_self

Damit kannst Du aber dann nicht beschränken, dass auf einem Multi-User-System nur bestimmte Personen etwas machen dürfen... im Regelfall also die Mitglieder der Gruppe "sudo". Der Eintrag ist dann meistens in pkla-files zu finden, oder bei Fedora in dem neueren xml-Format. Manchmal ist es ja so, dass nicht alle User Programme mit root-Rechten ausführen sollen dürfen. Meillo hat allerdings recht mit der Einschätzung, dass aus heutiger Sicht die Gruppe "sudo" als Grundlage für Polkit-Rechte zu verwenden keine gute Design-Entscheidung war. Sachlich eindeutiger wäre es gewesen, eine neue Gruppe "Administrator" oder sö ähnlich zu schaffen.

Ich habe leider keinen Standard-Desktop verfügbar und kann das derzeit nicht mehr kontrollieren. Aber soweit ich mich erinnere ist das bei buntu und mint die Regel, das Policies die Gruppe "sudo" verwenden. Ob die Debian-Desktops da noch was ähnliches haben, kann ich auch grad nicht prüfen.... bei uns gibts ja nur diese Openbox-Custom-DE's. Aber Du hast Recht... ich sehe das seit jessie auch so, es gibt nix überflüssigeres wie "sudo"... ich steuere seit Jahren ebenalls alle Rechte mit Policies.

[c1ue]

Hey,

danke für Eure vielen Antworten!

@Meillo
Das mit den aussagekräftigen Titeln werd ich in Zukunft beherzigen.

@Alle
Ok, also Policykit also ist dafür verantwortlich, dass ich z.B. Synaptic trotz deaktiviertem Sudo starten kann.

Nun, da ich meinen Nutzer aus dieser Gruppe gerne draußen lassen würde, habe ich dafür ein neues Problem:

Ich würde gerne grafische Programme (wie Dolphin & Co.) gerne in meiner laufenden KDE-Sitzung von einem anderen user ausführen.

Bisher habe ich das immer mit kdesudo -u AndererUser -c dolphin erledigen können. Nun geht das aber nicht mehr. Kennt Ihr noch eine andere einfache Möglichkeit dies zu bewerkstelligen, oder muss mich doch wieder zur Gruppe sudoers hinzufügen?

[KP97]

Die Antwort hast Du doch schon bekommen

Code: Alles auswählen

pkexec dolphin

Wenn Dein KDE mit Xwayland läuft, hat @MartinV das auf der vierten Seite gut beschrieben:
viewtopic.php?f=1&t=172987&start=45

Nachtrag:
Ich habe auf einer Testpartition unter Sid ein KDE installiert. Als Starter habe ich einen Admin mit dem Befehl "pkexec dolphin" eingerichtet.
Das funktioniert auch, allerdings werden die Themes und Einstellungen nicht richtig übernommen, so wie es beim User der Fall ist. Das kann aber auch am Sid-KDE liegen,
ich habe es nicht groß recherchiert, da es eh nur ein Testsystem ist. Definitiv ist aber der User nicht Mitglied der Gruppe sudo.
Aber wenn ich als User Dolphin aufrufe, und z.B. in der fstab etwas ändere, wird beim Speichern das RootPW abgefragt und das Ändern ist möglich.
Ob das auch mit Xwayland so ist, weiß ich nicht, bei mir läuft Xorg.

[willy4711]

Es ist eine allgemeine Regel, nicht programmspezifisch. sudo-Gruppen-Mitglieder dürfen jedes beliebige Programm mit pkexec als root ausführen.

Hat mich jetzt doch interessiert und hab mal "geforscht und (zumindest teilweise) gefunden
in /usr/share/polkit-1/rules.d
existieren einige Rules, die die sudo- Gruppe abfragen. Diese wurden wohl aus den entsprechenden *pkla - Dateien aus /var/lib/polkit-1/localauthority/10-vendor.d/ generiert (?) , wie TomL ja schon erwähnt hatte :
1)blueman.rules

Code: Alles auswählen

// Allow users in sudo or netdev group to use blueman feature requiring root without authentication
polkit.addRule(function(action, subject) {
    if ((action.id == "org.blueman.network.setup" ||
         action.id == "org.blueman.dhcp.client" ||
         action.id == "org.blueman.rfkill.setstate" ||
         action.id == "org.blueman.pppd.pppconnect") &&
        subject.local && subject.active &&
        (subject.isInGroup("sudo") || subject.isInGroup("netdev"))) {
        return polkit.Result.YES;
    }
});

2)/ org.gtk.vfs.file-operations.rules

Code: Alles auswählen

polkit.addRule(function(action, subject) {
        if ((action.id == "org.gtk.vfs.file-operations-helper") &&
            subject.local &&
            subject.active &&
            subject.isInGroup ("sudo")) {
            return polkit.Result.YES;
        }
});

3) 60-network-manager.rules

Code: Alles auswählen

polkit.addRule(function(action, subject) {
  if (action.id == "org.freedesktop.NetworkManager.settings.modify.system" &&
	subject.local && subject.active && 
	(subject.isInGroup ("sudo") || subject.isInGroup ("netdev"))) {
    return polkit.Result.YES;
  }
});

Wie der Zusammenhang mit Synaptic da ist, kann ich allerdings nicht verstehen.

Denn für Synaptic gibt es bei mir (Xfce +KDE) eine eigene policy:
/usr/share/polkit-1/actions/com.ubuntu.pkexec.synaptic.policy
Diese Policy ist bei mit auch in KDE (Stretch) als uch in KDE (Buster) vorhanden.

Ich würde gerne grafische Programme (wie Dolphin & Co.) gerne in meiner laufenden KDE-Sitzung von einem anderen user ausführen.

Kannst du das mal genauer ausführen ? Was soll das für ein Nutzer sein ? Root oder was Anderes?
Wenn was Anderes: Was versprichst du dir davon ?

[c1ue]

Die Antwort hast Du doch schon bekommen

Code: Alles auswählen

pkexec dolphin

Wenn Dein KDE mit Xwayland läuft, hat @MartinV das auf der vierten Seite gut beschrieben:
viewtopic.php?f=1&t=172987&start=45

pkexec dolphin

QXcbConnection: Could not connect to display
Abgebrochen

pkexec --user user2 dolphin

QXcbConnection: Could not connect to display
Abgebrochen

pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dolphin
verlangt nach dem root-PW und öffnet dann einen root Dolphin. Ich benötige aber den Dolphin von user2.

EDIT:
pkexec --user user2 env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dolphin

No protocol specified
QXcbConnection: Could not connect to display :0
Abgebrochen

Kannst du das mal genauer ausführen ? Was soll das für ein Nutzer sein ?

Ein normaler, anderer Nutzer auf dem selben, laufenden System mit dessen Rechten ich "seinen" Dolphin oder "sein" Office starten lassen möchte.

[KP97]

Bei der Angabe von "kdesudo" bin ich davon ausgegangen, daß nach root gewechselt werden soll, daher meine vorherige Antwort.
Wenn es aber ein anderer Benutzer sein soll, wäre doch der Aufruf "Benutzerwechsel" aus dem Menü das sinnvollste Vorgehen. Man kann dem zweiten User noch Rechte auf den anderen Verzeichnissen einräumen, aber sauberer wäre, gleich beide in die gleiche Gruppe stecken. Hier mußt Du Dich mit dem Unix-Rechtesystem beschäftigen.

[MartinV]

EDIT:
pkexec --user user2 env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY dolphin

No protocol specified
QXcbConnection: Could not connect to display :0
Abgebrochen

willy4711 hat geschrieben:
Kannst du das mal genauer ausführen ? Was soll das für ein Nutzer sein ?

Ein normaler, anderer Nutzer auf dem selben, laufenden System mit dessen Rechten ich "seinen" Dolphin oder "sein" Office starten lassen möchte.

Ah, gut, jetzt verstehe ich besser, was Du erreichen willst.
Dein pkexec-Befehl ist grundsätzlich richtig, scheitert aber, weil die Datei $XAUTHORITY nur von user1 gelesen werden kann.
Die einfachste Lösung ist, Zugriff auf X für user2 mit xhost zu erlauben.
Als user1:

Code: Alles auswählen

xhost +SI:localuser:user2

Anschließend sollte gehen:

Code: Alles auswählen

pkexec --user user2 env DISPLAY=$DISPLAY dolphin

[TomL]

Wenn es aber ein anderer Benutzer sein soll, wäre doch der Aufruf "Benutzerwechsel" aus dem Menü das sinnvollste Vorgehen.

Nicht unbedingt... ich nutze das z.B. um meinen Normalbetriebs-Surfer-Browser mit dem Profil eines völlig unberechtigten Users (hier ist das ein virtueller User) zu starten. Mein eigenes mir selbst gehörendes Browserprofil wird zum Surfen tatsächlich gar nicht verwendet. Weil ich gleichzeitig neben dem Browser aber noch ganz normal in meinem Profil werkele, mit irgendwelchen beliebigen Anwendungsprogrammen und eben auch der Notwendigkeit, auf LAN-Ressourcen mit meinen regulären User-Rechten zuzugreifen, wäre ein vollständiger User-Wechsel natürlich problematisch.

Man kann dem zweiten User noch Rechte auf den anderen Verzeichnissen einräumen, aber sauberer wäre, gleich beide in die gleiche Gruppe stecken. Hier mußt Du Dich mit dem Unix-Rechtesystem beschäftigen.

Bei mir gehts genau darum, nur halt genau umgekehrt... und zwar das der zweite User überhaupt keine Rechte hat. Mein virtueller User sieht hinsichtlich Daten und bezogen auf unsere LAN-Freigaben gar nix, er sieht eigentlich nur sein eigenes quasi völlig leeres Homedir, dementsprechend sieht auch der Browser nix, der unter dieser UID läuft. Ich habe lediglich mich selber dazu berechtigt, sein Download-Dir zu öffnen, damit ich an dort liegende Downloads rankomme.

[c1ue]

Code: Alles auswählen

xhost +SI:localuser:user2

Anschließend sollte gehen:

Code: Alles auswählen

pkexec --user user2 env DISPLAY=$DISPLAY dolphin

Super, das klappt. Mal ne frage: Reiß ich mir damit irgendwelche gravierenden Sicherheitslücken auf mit dem xhost? Und bleibt das dann permanent so oder nur bis zum Abmelden meines "normalen" Beutzers?

@TomL

ich nutze das z.B. um meinen Normalbetriebs-Surfer-Browser mit dem Profil eines völlig unberechtigten Users (hier ist das ein virtueller User) zu starten.

Find ich super, wie Du das machst. Könntest Du mir mal Schritt für Schritt erklären, wie Du das machst? Und nochwas: Kombinierst Du das dann mit z.B. firejail? Und wie läuft das, wenn Du mal ne mit dem Browser heruntergeladene Datei speichern willst, die Dein "normaler" user dann weiterverwenden soll?

[MartinV]

Super, das klappt.

Reiß ich mir damit irgendwelche gravierenden Sicherheitslücken auf mit dem xhost?

Ich bin kein Fan von xhost, aber mit der Festlegung localuser (nur lokaler Benutzer) und nur user2 geht es.
Bei Fedora (oder Gnome 3 generell?) gibt es gar kein XAUTHORITY mehr, nur noch ein xhost-Setup für den aktuellen Benutzer wie das hier beschriebene.
Riskant ist "xhost +", das beliebigen Zugriff durch jedermann erlaubt. Findet man oft als (schlechte) Empfehlung im Netz.

Und bleibt das dann permanent so oder nur bis zum Abmelden meines "normalen" Beutzers?

Bis zum Ende des X servers.
Du kannst es vorher schon deaktivieren mit:

Code: Alles auswählen

xhost -SI:localuser:user2

Den derzeitigen Status von xhost-basierten Zugriffsrechten siehst Du mit:

Code: Alles auswählen

xhost

[c1ue]

Super, danke vielmals!