„sudo broken by design” - Gründe für diese Aussage?

[debianoli]

Bevor ihr euch hier den Schädel einschlagt, würde ich gerne eine für mich sehr sinnvolle Möglichkeit für den Einsatz von sudo im ursprünglichen Sinn bringen: Ich starte damit Programme wie den Firefox als anderer User surfer und ermögliche es mir, von der Konsole aus als User zu mounten.

Code: Alles auswählen

/etc/sudoers.d/oliver
oliver ALL = (surfer) NOPASSWD: ALL
oliver ALL = NOPASSWD: /bin/mount, /bin/umount

So kann ich dann über kdesudo den Firefox starten, der nur auf das Home von surfer Zugriff hat. So sollten Angriffe über den Browser auf mein User-Home nicht möglich sein, da nur Daten aus dem Surfer-Home gelesen werden können. User oliver ist nicht in Gruppe sudo und kann somit nichts weiteres machen.

[wanne]

user kann die Root gehörende Datei löschen

a) Wie. Glaube nicht, dass es das irgend wo auf dem system gibt. Aber trotzdem nehmen wir das mal an:
Wie soll das weiter gehen. Das interessiert mich wirklich. User löscht die Datei. Legt eine neue eigene an. Und jetzt? Kann er seine eigene Datei ausführbar machen und ausführen. Aber nicht mit sudo, weil das nur root darf. Wo ist da mein Denkfehler?
Wie gesagt: Wäre mir wirklich wichtig.

Bei korrekter Konfiguration von /etc/sudoers sehe ich nun überhaupt keine Probleme bei Ausführung von

Ich auch nicht. Aber es läuft eben genau darauf raus:

natürlich irgendwie Quatsch aber was solls

Dieses Programm ist sagen wir mal recht fehlerfrei.

Um beim Beispiel von apt-get zu bleiben. Es ist keineswegs ein Fehler in apt-get, dass man da Befehle als root ausführen kann.
Erst durch die Nutzung von sudo entsteht das Problem.
Das Problem ist, dass du Programme, die nie für die Nutzung von sudo gedacht waren nicht mit sudo ausführen solltest. Aber alle anderen Programme längst andere Möglichkeiten abseits von sudo bieten.
Du hast schon recht: Broken by design ist es Programme die nicht für den Gebrauch mit sudo gedacht waren mit sudo zu nutzen. Das ist ein Problem vom Admin.
Aber wenn der Admin das nicht macht bleibt dann einfach kein Anwendungsfall mehr übrig.

So kann ich dann über kdesudo den Firefox starten, der nur auf das Home von surfer Zugriff hat. So sollten Angriffe über den Browser auf mein User-Home nicht möglich sein, da nur Daten aus dem Surfer-Home gelesen werden können. User oliver ist nicht in Gruppe sudo und kann somit nichts weiteres machen.

OK. Gewonnen. Da hast du tatsächlich einen Anwendungsfall. Um Rechte einzuschränken macht es wirklich Sinn. Habe ich in komplizierterer Form am laufen gehabt für den Chrome. Das gefällt mir eigentlich sogar richtig gut. Ich denke da nochmal drüber nach aber ich glaube ich mache das auch so. Coole Idee. Aber nur wenn du wayland verwendest. Sonst kannst du über den X11 Über mousevents die Bilschirmtastatur auf machen. und dann das Programm ausführen.

[DeletedUserReAsG]

Wie. Glaube nicht, dass es das irgend wo auf dem system gibt.

Die Datei befand sich in /home/niemand und gehörte Root. Der User ›niemand‹ darf diese Datei nicht direkt bearbeiten, aber nunmal löschen, neu erstellen, ausführbar machen und im Anschluss mit und ohne sudo ausführen, wenn /home/niemand/test.sh in der sudoers steht. Mag sein, dass man’s auch noch so konfigurieren kann, dass die Datei Root gehören muss – besser ist’s aber, so Dateien nicht in userkontrollierten Verzeichnissen unterzubringen.

Das Szenario bei apt-get kann ich nicht nachstellen. Bitte da weiterhin ein reproduzierbares Beispiel.

[wanne]

Das Szenario bei apt-get kann ich nicht nachstellen. Bitte da weiterhin ein reproduzierbares Beispiel.

Wie gesagt: Du musst halt auf ein Update warten, bei dem sich eine Datei unter /etc ändert. Dann bekommst du die Frage ob du die bearbeiten willst. Dann bist du im vim. Das ist in Debian sogar default. (Du musst also gar nicht $EDITOR setzen.) Und da kannst du dann halt :! machen.

Die Datei befand sich in /home/niemand und gehörte Root. Der User ›niemand‹ darf diese Datei nicht direkt bearbeiten, aber nunmal löschen, neu erstellen, ausführbar machen und im Anschluss mit und ohne sudo ausführen, wenn /home/niemand/test.sh in der sudoers steht.

Auchso. Ja. So ist klar. Ich dachte du beziehst dich auf meine config wo nur root sudo ausführen kann.

besser ist’s aber, so Dateien nicht in userkontrollierten Verzeichnissen unterzubringen.

In jedem Fall. Das gilt auch für die Anwendung ohne sudo. Wenn dein User nicht alle Überordner kontrolliert solltest du da nichts executable haben.

[uname]

Ich hätte noch eine Frage. Nutzt jemand von euch Umgebungen mit mehreren Benutzern, wo einige dieser Benutzer nur eingeschränkte root-Rechte z. B. zum Starten und Stoppen von Services ausführen dürfen? Wie wird das heute überhaupt gemacht? Ist auf Serversystemen mit vielen Benutzern, nur Shell-Zugang und wenigen als root auszuführenden Befehlen tatsächlich Polkit bzw. Policykit die heutige Alternative zu sudo?

[TomL]

Ich hätte noch eine Frage. Nutzt jemand von euch Umgebungen mit mehreren Benutzern, wo einige dieser Benutzer nur eingeschränkte root-Rechte z. B. zum Starten und Stoppen von Services ausführen dürfen? Wie wird das heute überhaupt gemacht? Ist auf Serversystemen mit vielen Benutzern, nur Shell-Zugang und wenigen als root auszuführenden Befehlen tatsächlich Polkit bzw. Policykit die heutige Alternative zu sudo?

Ja, ich, bei mir ist alles, von den Mounts an und bis in die letzte Instanz user-individuell geregelt... jeder User hat nach der Anmeldung ein eigenes Debian-Umfeld, hinsichtlich Berechtigungten individuell ausgerichtet auf seinen Bedarf. Und alles vollständig über das Polkit mit expliziten Berechtigungen... sudo gibts hier nicht, und auch nicht die Möglichkeit, dass sich User höhere Rechte aneignen können.

[DeletedUserReAsG]

Du musst halt auf ein Update warten, bei dem sich eine Datei unter /etc ändert. Dann bekommst du die Frage ob du die bearbeiten willst. Dann bist du im vim. Das ist in Debian sogar default. (Du musst also gar nicht $EDITOR setzen.) Und da kannst du dann halt :! machen.

Gut, wäre dann wieder ein Konfigurationsproblem (Admin lässt einen User Programme als Root ausführen, bei denen unter Umständen ’ne Shell gestartet werden kann – hatte ich damals™ nicht dran gedacht, und wäre da auch unwichtig gewesen: der User war nur darauf festgenagelt, damit er nix aus Versehen kaputtmacht – der hätte von sich aus keine Shell aus’m Editor raus gestartet).

Die eigentliche Frage bleibt damit die Ausgangsfrage: warum sollte man sudo als „broken by design“ bezeichnen?

[OrangeJuice]

sudo ist nicht (sicher) administierbar. Deswegen verwendet man es auch nirgends mehr abseits von der Ubuntu-Variante wo by desighn alles geht.

Fedora verwendet doch auch sudo.

[AspeLin]

Mein Standpunkt ist, dass sudo nicht "broken by design" ist, nur weil es unsichere Konfigurationen zulässt. Immerhin können chmod und chown auch unsichere Zustände hinterlassen, ohne dass "by design" eine bestimmte Rechtevergabe verboten wäre. Software ist einfach nicht klug genug, um mir sagen zu dürfen, was ich im Einzelfall nicht können soll.

Den Thread habe ich sehr interessiert gelesen, hatte zum Teil etwas seifenopermäßiges (werden sie sich wieder vertragen?)!

[bluestar]

sudo ist nicht (sicher) administierbar.

Diese Aussage mag für dich gelten, ich lasse diese Aussage nicht gelten.

Wie gesagt: Null sichere Anwendungsfälle. Das nenne ich broken by desighn.

Wenn du keine Anwendungsfälle für sudo hast, dann mag dies für dich gelten...

Wir haben unterschiedlichste Anwendungsfälle, ein typischer Fall:
Ein Script welches Daten aus einer Datenbank zieht und einem Dienst bereitstellt/aktualisiert und danach den Dienst neu startet.
Das Script wird von Support-Mitarbeitern gestartet, die keinen Root-Zugriff auf das System haben.

Um auf deine Aussage noch einmal einzugehen: Jeder Server-Dienst im Netzwerk, der keine Verschlüsselung(TLS) und ggfs. Benutzer-Anmeldung unterstützt wäre somit auch "broken by design".

Ich glaube damit würdest du den Erfindern des HTTP und des FTP-Protokolls den Sinn der Entstehung dieser Protokolle absprechen, weil sie ja zum Zeitpunkt ihrer Entwicklung schon "broken by design" waren...