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

[wanne]

Das ist interessant und führt in die richtige Richtung. Könntest du bitte eine Zeile zeigen, mit der es mir auf der Maschine vom obenstehenden Beispiel möglich wäre, mehr als stur pacman -Suy auszuführen? Mir will es nicht gelingen.

Da hast du ja keine Wildcards in der /etc/sudoers stehen. Wie gesagt: Wirklich broken by desighn sind nur die wildcards. Punkt 1 schlägt da nicht zu.
Ich wette aber dass du auch bei packman irgend wo snsible editor oder so setzen kannst und damit in den vim kommst.
Ich kenne packman nicht. Deswegen werde ich da nicht ausbrechen können. Aber sobald da jemand kommt, der das Programm besser als du kennt hat der praktisch in jedem komplexeren Programm einen Weg zu einem Terminal zu kommen.

[MSfree]

Mal ein Beispil zu deinem apt-get upgrade. Da setzt du $VISUAL oder $EDITOR auf vim. Wartest dann genüsslich auf ein Update, wo sich eine konfiguration ändert und meinst dann: Resolve Confict. Dann geht dir dein vim als root auf. Und in den kannst du dann :!bash und schwups hast du eine Konsole als root.

Danke für dieses Beispiel. Sowas schwebte mit auch vor, als ich von Broken-by-Design sprach. Klar, das ist nicht unbedingt sudos Fehler, sondern die der Programme, die man mit sudo zuläßt. Wobei das im Falle von apt-get nicht einmal ein Fehler ist sondern gewolltes Verhalten.

Ein anderes Problem wäre noch, wenn man mit sudo nur das Programm xxxxyyyy zulassen würde. Ich mache mir dann einfach eine Kopie von /bin/bash in meinem Home, nenne sie xxxxyyyy und rufe es mit sudo xxxxyyyy auf.

[DeletedUserReAsG]

Ich wette aber dass du auch bei packman irgend wo snsible editor oder so setzen kannst und damit in den vim kommst.

Nein, funktioniert nicht.

Ich scheitere auch gerade daran, zu prüfen, ob Variablen tatsächlich ausgewertet werden, wenn sie vom User/für den User gesetzt werden. Ich denke nämlich, dass das nicht der Fall ist – ein Konstrukt, mit dem ich vorhin getestet hatte, deutete darauf hin, dass es ein neues Environment gibt. Ich versuch’s mal weiter …

Aber auch in diesem Fall wär’s eine Frage der Konfiguration – kein Problem von sudo selbst. Das könnte schließlich genauso auftreten, wenn man mit pkexec arbeitet, oder?

[wanne]

Ein anderes Problem wäre noch, wenn man mit sudo nur das Programm xxxxyyyy zulassen würde.

Defakto testet sudo as mit den absoluten pfaden schon ein bisschen darauf. Das Problem im Fall von apt ist, dass apt ja schön brav weiter läuft und nur einen vim startet. Davon bekommt sudo nichts mit. Du willst das auch nicht wirklich, weil wenn apt-get kein curl mehr starten kann, um die pakete runter zu laden und kein gpg2 starten kann um die Signaturen zu prüfen, ist es nutzlos.
Wie gesagt polkit ist mit seinen actions, die du erlaubst einfach der sinnvollere Ansatz.

[bluestar]

Mal ein Beispil zu deinem apt-get upgrade. Da setzt du $VISUAL oder $EDITOR auf vim. Wartest dann genüsslich auf ein Update, bei dem sich eine Konfiguration ändert und meinst dann: Resolve Confict. Dann geht dir dein vim als root auf. Und in den kannst du dann :!bash eingeben und schwups hast du eine Konsole als root.

Hier verweise ich auf env_reset in der sudo Konfiguration.

Ein anderes Problem wäre noch, wenn man mit sudo nur das Programm xxxxyyyy zulassen würde. Ich mache mir dann einfach eine Kopie von /bin/bash in meinem Home, nenne sie xxxxyyyy und rufe es mit sudo xxxxyyyy auf.

Hier verweise ich auf secure_path in der sudo Konfiguration.

Code: Alles auswählen

Defaults	env_reset
Defaults	mail_badpass
Defaults	secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

Bitte bitte liebe Mitdiskutierenden liefert Belege um Aussagen zu untermauern.

[TomL]

...möchte ich nun an dieser Stelle fragen, was genau mit sudo selbst so falsch ist, dass man es als „broken by design“ bezeichnen würde.

Ich glaube nicht, dass sudo in dem von Dir beschriebenen Umfeld selber das Problem ist - wenn man mal den Umgang damit bei den Debian-Derivaten nicht betrachtet. Ich denke auch, dass sudo in der eigentlichen Intention verwendet völlig ok ist. Ich habe vor diesem Hintergrund und mit den akuellen Debian-Releases nur ein einziges Problem damit, und zwar dass es durch die grafischen Desktop-Systeme möglicherweise eine schwer durchschaubare Wechselwirkung mit den gleichzeitig installierten Polkit-Policies gibt, weil die teilweise auch auf die Gruppe "sudo" zurückgreifen. Ich glaube, dass man damit Gefahr läuft, unter Umständen die exklusive Kontrollle über das Rechte-System zu verlieren.

Das ist auch der einzige Grund, warum ich sudo immer sofort deinstalliere und keine Einträge in der Gruppe "sudo" vornehme. Ich setze auf EIN System, und bei mir isses halt das Polkit. Gleichzeitig zwei Systeme mit der gleichen Zielsetzung und Zugriff auf die gleichen Quellen (Grp sudo) halte ich mit meinem Laienverstand jedenfalls für kritisch.

[DeletedUserReAsG]

Nachtrag Variablen:

Code: Alles auswählen

niemand@archT400 ~ % cat test.sh
#! /bin/bash
echo $TEST
niemand@archT400 ~ % export TEST=blub
niemand@archT400 ~ % ./test.sh 
blub
niemand@archT400 ~ % sudo ./test.sh

niemand@archT400 ~ % 

Mit den Variablen funktioniert’s also auch allenfalls, wenn die systemweit gesetzt sind. Der User kann sie aber nicht systemweit setzen, und sich so also selbst auch keine höheren Rechte verschaffen. Wenn’s geht, ist’s wieder ein Konfigurationsfehler.

Edit: noch ’n Fehler drin, ich arbeite dran behoben
Noch’n Edit, und ich brauch ’n Versionskontrollsystem … (Bezug: „Zitate“ im Wiki)

[bluestar]

Ich habe vor diesem Hintergrund und mit den akuellen Debian-Releases nur ein einziges Problem damit, und zwar dass es durch die grafischen Desktop-Systeme möglicherweise eine schwer durchschaubare Wechselwirkung mit den gleichzeitig installierten Polkit-Policies gibt, weil die teilweise auch auf die Gruppe "sudo" zurückgreifen. Ich glaube, dass man damit Gefahr läuft, unter Umständen die exklusive Kontrollle über das Rechte-System zu verlieren.

Da muss ich TomL an dieser Stelle absolut Recht geben, wobei der Fehler hier in den Polkit-Policies liegt, sich einfach der Gruppe "sudo" zu bedienen ist schlampig und ja kann natürlich zu unerwünschten Wechselwirkungen/Sicherheitslücken führen....

[DeletedUserReAsG]

Ein anderes Problem wäre noch, wenn man mit sudo nur das Programm xxxxyyyy zulassen würde. Ich mache mir dann einfach eine Kopie von /bin/bash in meinem Home, nenne sie xxxxyyyy und rufe es mit sudo xxxxyyyy auf.

Ich empfehle, dass du dir das Programm mal installierst, die recht überschaubare Doku einmal durchgehst, und die von dir vorgestellten Szenarien einfach mal durchprobierst. Das funktioniert nämlich so nicht – das wird direkt beim Speichern klar:

Code: Alles auswählen

root@archT400:/home/niemand# visudo
[Angabe des Programms ohne Pfad in der Datei → :wq]
>>> /etc/sudoers: Syntax-Fehler near line 80 <<<
Was jetzt?

Möglicherweise wäre dieser Thread dann auch obsolet, wenn du’s so machen würdest. Oder aber, du bringst ein Beispiel, in dem ein ordentlich konfiguriertes sudo tatsächlich eine unerlaubte Ausweitung der Rechte für einen User ermöglicht – in dem Fall hätte der Thread sein Ziel erreicht, und (nicht nur) ich würde fortan ebenfalls an jeder Ecke vor sudo warnen (und auf diesen Thread verweisen, weil: leere Warnungen ohne jeden Beleg sind … unseriös, das ist das Wort).

[wanne]

Ich scheitere auch gerade daran, zu prüfen, ob Variablen tatsächlich ausgewertet werden, wenn sie vom User/für den User gesetzt werden. Ich denke nämlich, dass das nicht der Fall ist – ein Konstrukt, mit dem ich vorhin getestet hatte, deutete darauf hin, dass es ein neues Environment gibt.

Nein. sudo resetet dir ein paar Variablen wie PAHT und LD_PRELOAD. Aber eben bei weitem nicht alle.
Habe hier gerade mal ein Beispiel:

Code: Alles auswählen

# a=5
# echo $a
5

man kann das auch um konfigurieren aber auch da verhält sich sudo nicht im geringsten so, wie man das erwarten würde.

Aber auch in diesem Fall wär’s eine Frage der Konfiguration – kein Problem von sudo selbst. Das könnte schließlich genauso auftreten, wenn man mit pkexec arbeitet, oder?

Ich habe jetzt eher nicht auf pkexec abgeziehlt sondern eher auf berechtigungen auf freedesktop-Events ala mouten über usdisk oder eben updates über kpackage-Kit.

Bitte bitte liebe Mitdiskutierenden liefert Belege um Aussagen zu untermauern.

Deine Konfiguration enthält keine einzige Regel, die irgend was zulässt. In aller erster Linie ist die Nutzlos.
Und genau das ist meine Kritik: Man kann sudo in sicherer Art und weise verwenden. Dann tut es aber halt auch nichts mehr. Die Überschneidungen von sicher und nützlich sind extrem klein.
Auf der anderen Seite hat man einen Riesen Konfigurationen, die auf den ersten Blick sicher aussehen, aber es nicht sind.
In 99% der Fälle wo sudo sinnvoll angewendet wird, ist es halt unsicher. Dass du irgend welche abstrusbeispiele konstruieren kanns, wo das nicht der Fall ist ändert nichts daran.

[bluestar]

Oder aber, du bringst ein Beispiel, in dem ein ordentlich konfiguriertes sudo tatsächlich eine unerlaubte Ausweitung der Rechte für einen User ermöglicht – in dem Fall hätte der Thread sein Ziel erreicht, und (nicht nur) ich würde fortan ebenfalls an jeder Ecke vor sudo warnen (und auf diesen Thread verweisen, weil: leere Warnungen ohne jeden Beleg sind … unseriös, das ist das Wort).

Dem kann ich mich nur anschließen ...

[DeletedUserReAsG]

Habe hier gerade mal ein Beispiel:

Dieses verstehe ich nicht: ich hab’s ja oben mit $TEST probiert → wird nicht übernommen. Ich bin mir sicher, wenn ich es mit $a erneut versuche, passiert das Gleiche. Könntest du bitte detailliert und nachvollziehbar angeben, was du meinst?

[bluestar]

Bitte bitte liebe Mitdiskutierenden liefert Belege um Aussagen zu untermauern.

Deine Konfiguration enthält keine einzige Regel, die irgend was zulässt. In aller erster Linie ist die Nutzlos.

Ich habe Ausschnitte aus der Standardkonfiguration gepostet um euch aufzuzeigen, einfach um die vielen Behauptungen "es würde etwas gehen" durch die Standardoptionen zu entkräften...

Ich warte auf eine konkretes Beispiel, was die Aussage "sudo is broken by design" begründet. Bitte keine faktenlosen Behauptungen.

Persönlich darf jeder für sich entscheiden, ob er/sie/div sudo mag oder nicht mag bzw. einsetzen/nicht einsetzen möchte.

[wanne]

Mit den Variablen funktioniert’s also auch allenfalls, wenn die systemweit gesetzt sind.

Nicht in der default config.

Dem kann ich mich nur anschließen ...

Und hier der Exploit für niemands config:

Code: Alles auswählen

cd /tmp
echo -e '#!/bin/sh\nxterm' > ./test.sh
chmod +x  ./test.sh
sudo ./test.sh

Und jetzt einfach mal ruhig sein.

Wenn’s geht, ist’s wieder ein Konfigurationsfehler.

Ja. Es ist nur pratisch unmöglich Konfigurationen ohne Fehler zu erstellen. Auch du hast es nicht hinbekommen.
DAS ist der Grund warum man, kein sudo benutzen sollte.
Und ja: Wir können das jetzt nochmal 5 mal mit "besserer" config durchspielen und dann fallen mir auch keine Exploits mehr ein.
Wir haben in dem thread bis jetzt 3 configs gepostet gehabt. Eine hat nichts gemacht. Die anderen beiden waren expliotbar.
Und das alles von Leuten, die eher nicht ganz unbedarft sind.
Versteht ihr jetzt, warum ihr die Finger von sudo lassen solltet? Es ist nicht aus prinzip unsicher. Es ist nur extrem schwierig sicher zu betreiben. Und wir haben genug Lücken mit tools, wo man sich eigentlich schon stark anstrengen muss, um sich in den Fuß zu schießen.

[bluestar]

Und hier der Exploit für niemands config:

Code: Alles auswählen

cd /tmp
echo -e '#!/bin/sh\nxterm' > ./test.sh
chmod +x  ./test.sh
sudo ./test.sh

Und jetzt einfach mal ruhig sein.

So und jetzt bitte noch deine /etc/sudoers Datei, mit der default /etc/sudoers Datei von Debian Buster läuft es nämlich NICHT!

[uname]

Code: Alles auswählen

sudo ./test.sh

Also ich kenne "sudo" nur von Systemen mit vielen Benutzern.
Ich habe noch nie eine Konfiguration gesehen, wo relative Befehle wie "test.sh" oder "./test.sh" erlaubt gewesen wären.
Natürlich müssen alle erlaubten Befehle mit absoluten Pfaden verstehen werden und nur root darf diese Dateien ändern dürfen.
Ich wundere mich, dass diese Art von Konfiguration überhaupt möglich ist oder möglich sein soll.
Eigentlch ist es aber auch wieder nur ein Administrationsfehler und kein Fehler von sudo.

[DeletedUserReAsG]

So und jetzt bitte noch deine /etc/sudoers Datei, mit der default /etc/sudoers Datei von Debian Buster läuft es nämlich NICHT!

Tjo, das läuft in gar keinem Fall – es sei denn, man gäbe /tmp/test.sh in der sudoers an (und würde /tmp ohne noexec remounten …). Dann kann man auch gleich die Buntukonfiguration nehmen – kein normaler Admin würde sowas da reinschreiben, oder überhaupt die Ausführung einer Datei via sudo erlauben, auf die der Nutzer schreibenden Zugriff hat. Das wäre ’ne klassische Fehlkonfiguration, aber immer noch kein Designproblem von sudo.

Ja. Es ist nur pratisch unmöglich Konfigurationen ohne Fehler zu erstellen. Auch du hast es nicht hinbekommen.

Bei mir funktionierte ›sudo ./test.sh‹, weil ich in /home/niemand war, und in der sudoers „/home/niemand/test.sh“ freigegeben war. Dein „Exploit“ kann hier gar nicht funktionieren, und tut’s auch nicht.

In meinem gestellten Beispiel hat ›niemand‹ auch schreibenden Zugriff auf die Datei, könnte also einfach ›/bin/bash‹ reinschreiben und hätte im Anschluss ’ne Rootshell. Hab ich getestet, geht – aber nochmal: da wäre die Schuld eindeutig beim Admin zu suchen. Genausogut könnte man sein System so confen, dass der httpd Zugriff auf die shadow hat – und könnte immer noch nicht behaupten, der httpd wäre „broken by design“.

Was das „einfach mal ruhig sein“ angeht – das kommt überheblich und arrogant rüber (weiß nicht, ob’s auch so gemeint war – ist mein subjektives Empfinden). Dafür, dass das gebrachte Beispiel ’ne Nullnummer ist, finde ich das ziemlich unangebracht und möchte darum bitten, sowas zu unterlassen. Ich denke, bis hierher war’s ein durchaus interessanter Thread und würde mich freuen, wenn es auch so bliebe. Über einen tatsächlich nachvollziehbaren Weg, bei der Default-Config seine Rechte zu erweitern, würde ich mich noch viel mehr freuen.

Edit: Ergänzung, Quote eingefügt für Highlight des Users

[wanne]

Ich habe Ausschnitte aus der Standardkonfiguration gepostet um euch aufzuzeigen, einfach um die vielen Behauptungen "es würde etwas gehen" durch die Standardoptionen zu entkräften...

a) Nein. Das ist nicht standardconfig. Die hat ne rech längliche env_check und env_delete liste.
b) Ja. In Standardkonfig ist sudo ungefährlich. Es macht ja auch nichts.

So und jetzt bitte noch deine /etc/sudoers Datei, mit der default /etc/sudoers Datei von Debian Buster läuft es nämlich NICHT!

Wie gesagt: Die default Datei macht gar nichts. Die bezog sich auf die von niemad, die jetzt schnell wegeditiert hat, damit sie nicht mehr da ist. Ich habe eine (IMHO) sichere sudoers datei:

Code: Alles auswählen

Defaults        secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

root    ALL=(ALL:ALL) ALL

Die entspricht aber auch nicht dem, was die meisten Leute mit sudo machen wollen....

Ich warte auf eine konkretes Beispiel, was die Aussage "sudo is broken by design" begründet.

Ein unkongiguriertes sudo sit so natürlich so gefährdet wie ein ausgeschalteter Rechner. Es macht nichts. Also kann man es auch nicht angreifen.
Dafür wo es die meisten einsetzen ist es unbrauchbar. Das sind vor allem die Calls, die beliebige Argumente nehmen (Wie gesagt: Wildcards sind broken by desigh.) aber eben auch fast alle anderen tools. Die Idee hinter sudo ist, Programme mit anderer Berechtigung auszuführen, die nicht dafür gedacht sind. Das kann in seltenen Fällen gut gehen. Wenn du irgend wie echo oder so nimmst geht das natürlich gut. In den aller meisten Fällen nicht.

[wanne]

Genausogut könnte man sein System so confen, dass der httpd Zugriff auf die shadow hat – und könnte immer noch nicht behaupten, der httpd wäre „broken by design“.

Die Idee vom httpd ist nicht Zugriff auf die /etc/shadow zu geben. Die Idee von sudo ist aber eben schon non-Suid executables mit geänderten privilegien auszufühen. Und das geht halt in 99% der Fälle in die Hose. Und es ist für einen normalen User nicht absehbar, wann das der Fall ist.
Ihr habt euch beide auch hartneckigst geweigert explizite Anwendungsfälle zu anzugeben. Schlicht, weil ihr euch eben auch nicht sicher seid. Es gibt defakto halt keine nützlichen Kommandos, wo jemand die Hand für ins feuer halten würde, dass die mit sudo sicher sind.
Deswegen ist es broken by desighn: Es gibt keinen Anwendungsfall. (Im krassen Gegensatz zum httpd.)
Und auch da würde ich es btw als broken by desighn betrachten, wenn der als root läuft. Das ist einfach eine riesige gefahr ohne Nutzen.

[DeletedUserReAsG]

Wie gesagt: Die default Datei macht gar nichts. Die bezog sich auf die von niemad, die jetzt schnell wegeditiert hat, damit sie nicht mehr da ist.

Bitte keine Unterstellungen. Hier wurde gar nichts von der sudoers wegeditiert. Wenn du dich das nächste Mal auf was von mir beziehst, quote es einfach – dann musst du dich nicht auf das Niveau herablassen, Dinge zu behaupten, die gar nicht stimmen.

Hier meine komplette sudoers (kommentierte Zeilen nicht mitkopiert):

Code: Alles auswählen

root ALL=(ALL) ALL
niemand ALL = (ALL) /home/niemand/test.sh

… und nun bitte einfach mal sachlich was bringen, das funktioniert, oder halt einfach mal ruhig sein.

Ja, über sowas kann ich mich aufregen: groß rumtönen, vor Arroganz triefende Texte hinterlassen, Beispiele bringen, die von Anfang an nicht funktionieren können und dann noch Sachen unterstellen. Echt jetzt? Hast du sowas nötig, wanne? Bring doch einfach statt inhaltsarmen Gelabere, das teils mit dem Thema nix zu tun hat, mal nachvollziehbare Argumente, und „Beweise“ die auch funktionieren. TIA

[uname]

Code: Alles auswählen

niemand ALL = (ALL) /home/niemand/test.sh

Der Fehler liegt darin dem Benutzer "niemand" ein Programm als root ausführen zu lassen, welches der Benutzer "niemand" selbst ändern kann.

[DeletedUserReAsG]

Ähm … ich schrieb aber schon, dass das zu Testzwecken so gemacht wurde, dass es mir durchaus bewusst wäre, dass man da einfach /bin/bash reinschreiben könne, und dass es ’n Konfigurationsfehler wäre?
Edit:

Code: Alles auswählen

niemand@archT400 ~ % su -c 'chown root: ./test.sh && chmod 755 ./test.sh'                                                                           :(
Passwort: 
niemand@archT400 ~ % ls -l |grep test.sh
-rwxr-xr-x  1 root    root           24 31. Jul 11:52 test.sh
niemand@archT400 ~ % cat test.sh 
#! /bin/bash
echo $TEST
niemand@archT400 ~ % 

… das sei nun die festgeschriebene Ausgangslage. Jemand soll’s direkt quoten, damit wanne nicht wieder auf die Idee kommt, mir Sachen zu unterstellen, bzw., damit es in dem Fall direkt widerlegt werden kann – danke.

[wanne]

Hier meine komplette sudoers (kommentierte Zeilen nicht mitkopiert):

Du hast ja schon geschrieben was da schief geht:

In meinem gestellten Beispiel hat ›niemand‹ auch schreibenden Zugriff auf die Datei, könnte also einfach ›/bin/bash‹ reinschreiben und hätte im Anschluss ’ne Rootshell.

da wäre die Schuld eindeutig beim Admin zu suchen.

Ja. Man kann das immer auf den Admin schieben.
sudo ist nicht (sicher) administierbar. Deswegen verwendet man es auch nirgends mehr abseits von der Ubuntu-Variante wo by desighn alles geht.
Wie gesagt: Null sichere Anwendungsfälle. Das nenne ich broken by desighn.

[uname]

Ist das nun Ironie oder ernst gemeint?
Natürlich kann man /etc/sudoers auch sicher konfigurieren, indem man absolute Pfade, nur durch root veränderbare Programme und sichere Programme wie /usr/bin/whoami verwendet auch wenn das Beispiel wenig sinnvoll ist Aber sudo nicht verwenden, da der Administrator unfähig ist bzw. er keine sichere Konfiguration hin bekommt? Das wäre so wie auf Passwörter zu verzichten, weil sich der Administrator keine sicheren Passwörter ausdenken kann.

[wanne]

Hier meine komplette sudoers (kommentierte Zeilen nicht mitkopiert):

Du hast ja schon geschrieben was da schief geht:

In meinem gestellten Beispiel hat ›niemand‹ auch schreibenden Zugriff auf die Datei, könnte also einfach ›/bin/bash‹ reinschreiben und hätte im Anschluss ’ne Rootshell.

da wäre die Schuld eindeutig beim Admin zu suchen.

Ja. Man kann das immer auf den Admin schieben.
sudo ist nicht (sicher) administierbar. Deswegen verwendet man es auch nirgends mehr abseits von der Ubuntu-Variante wo by desighn alles geht.
Wie gesagt: Null sichere Anwendungsfälle. Das nenne ich broken by desighn.

Damit du sudo sicher nutzen kannst, musst du alle funktionalitäten (inklusive der ungewollten/undokumentierten) kennen. Dass kannst du IMHO nur bei selbstgeschriebenen Programmen.
Denen kannst du aber auch gleich suid geben. Wozu also noch sudo?