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

[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?

[wanne]

Das wäre so wie auf Passwörter zu verzichten, weil sich der Administrator keine sicheren Passwörter ausdenken kann.

Der Administrator kann sich für gewöhnlich aber sichere Passörter ausdenken. Ist das nicht Fall. Sind passwörter broken by desighn. Dann muss man sich nach was anderem umgucken. Gibt mittlerweile genug Plattformen wo das gemacht wird. Weil es mit der Userbase halt nicht funktioniert mit Passwörtern. (Meistens eher weil die sich die nicht merken können.)
Übersteigen die benötigten Fähigkeiten der der Andwender ist ein System halt kaputt. Egal wie schön das wäre, wenn wir jetzt irgend welche Übermenschen hätten.

und sichere Programme wie /usr/bin/whoami verwendet.

Und was soll es jetzt bringen, whoami als root ausführen zu können?

[DeletedUserReAsG]

… langsam bin ich mir nicht sicher, ob du die Aufgabenstellung erfasst hast: die Frage war, warum man ›sudo‹ als „broken by design“ bezeichnen könne. Explizit nicht, ob es bei Fehlkonfiguration Rootrechte für User ermöglichen würde, für die’s nicht vorgesehen ist – das ist möglich, und das ist mit vielen Programmen möglich, die deswegen nicht alle „broken by design“ wären. Die obenstehende Config ist übrigens auch unsicher (user kann die Root gehörende Datei löschen, und eine eigene mit eigenem Inhalt neu anlegen), daher im nächsten Beitrag die klare Ausgangssituation mit der Bitte, das zur unbefugten Ausweitung der Rechte zu benutzen, oder einfach mal ruhig zu sein (geht nur an wanne – alle anderen sind eingeladen, gerne weiter zu diskutieren).

Also nochmal extra für wanne: BTT, pls

[uname]

/usr/bin/whoami sollte ein einfaches Beispiel sein. Dieses Programm ist sagen wir mal recht fehlerfrei und ermöglicht wahrscheinlich keinen Ausbruch in die Shell.
Es gibt für den Benutzer den Benutzernamen und für root dann eben root aus.

Sollte es notwendig sein, dass ein Benutzer die Ausgabe root benötigt (natürlich irgendwie Quatsch aber was solls), könnte man es doch per sudo erlauben oder natürlich Setuid Root setzen Setuid Root wäre wohl wenig sinnvoll, da man damit die Funktionalität für alle anderen Anwender zerstört Mal abgesehen, dass die Rechte nicht mehr mit den Vorgaben der Paketverwaltung übereinstimmen und jeder Benutzer /usr/bin/whoami als root ausführen könnte.

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

Code: Alles auswählen

sudo /usr/bin/whoami

Zeigt mir die Sicherheitslücke für sudo /usr/bin/whoami und dann ist "sudo broken by design"

[DeletedUserReAsG]

Die definierten Bedingungen für wanne:

Code: Alles auswählen

root@archT400:/home/niemand# echo -e "#! /bin/bash \necho \$TEST blub" > /bin/testfile.sh && chmod 755 /bin/testfile.sh
root@archT400:/home/niemand# cat /etc/sudoers | grep -v "^#"
root ALL=(ALL) ALL
niemand ALL = (ALL) /bin/testfile.sh 
root@archT400:/home/niemand# exit
niemand@archT400 ~ % testfile.sh
blub
niemand@archT400 ~ % sudo testfile.sh
[sudo] Passwort für niemand: 
blub
niemand@archT400 ~ % 

Die klar definierte Aufgabe für wanne: Zeigen Sie, wie Sie bei den obenstehenden Bedingungen als User ›niemand‹ (UID 1000) mithilfe des Programms ›sudo‹ erweiterte Rechte erlangen, oder seien Sie einfach mal ruhig, und machen nicht weiter diesen Thread kaputt.

Jemand soll’s ftt quoten.

[MSfree]

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.

Hmm, ich würde diesem kleinen, selbstgeschriebenen C-Programm nicht unbedingt suid root setzen:

Code: Alles auswählen

#include <stdio.h>

int main(void)
{
  seteuid(0);
  setuid(0);
  setgid(0);
  setegid(0);
  system("/bin/bash");
  return 0;
}

[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...