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

[DeletedUserReAsG]

Hi,

bezugnehmend auf viewtopic.php?p=1212801#p1212801:

sudo ist broken by design.

… und die vorherigen, in betreffendem Thread allerdings themenfremden, Aussagen 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 rede ausdrücklich nicht von der missbräuchlichen Verwendung unter Buntu und Co. (und leider ja auch unter Debian, wenn man’s Root-Passwort bei der Installation überspringt), sondern von der Software selbst. Wo liegt das Problem darin, wenn ich einem User mittels sudo das Recht einräume, auf seiner Kiste Updates zu fahren – allerdings nur das, und nix anderes –, während ich mich um sonstige administrative Sachen ggf. via ssh selbst kümmere?

[bluestar]

Ich kann die Aussage von MSfree nicht nachvollziehen für mich seht die auf dürftigem Niveau...

Ich würde mich freuen, wenn MSfree hier ein paar Fakten liefert, die seine Aussage untermauern.
Die Meinung von Experten zum Thema sudo wäre für mich auf jeden Fall wünschenswert.

Code: Alles auswählen

su -

Dient dazu als root zu arbeiten, da bin ich mit MSfree d'accord.

Code: Alles auswählen

sudo befehl

Ist für mich eine bewusste Delegation der Aufgabe befehl an einen bestimmten User, was in größeren Umgebungen auch nötig ist... Wir delegieren über die sudoers gewisse Aufgaben an den First-Level-Support und reduzieren so den Arbeitsaufwand für die Administration.

[MSfree]

Code: Alles auswählen

sudo befehl

Ist für mich eine bewusste Delegation der Aufgabe befehl an einen bestimmten User, was in größeren Umgebungen auch nötig ist...

Und wenn der "befehl" /bin/bash lautet, bist du root, ohne das root-Paßwort kennen zu müssen. Und das ist nunmal der Standardfall, wenn man sudo installiert, egal ob Ubuntu oder Debian.

Es mag ja schön sein, daß man sudo bis ins letzte Eckchen konfigurieren kann. Das wird jedoch selten gemacht und wenn, dürfte es genug Fälle geben, in denen sowas wie sudo /bin/bash nicht verhindert wird. Das ganze Konfigurationsgerüst ist so kompliziert, daß dem besten Admin Fehler schon fast zwangsläufig bei der Konfiguration von sudo unterlaufen.

Ein System, das offen ist und man es mühevoll abdichten muß, wobei vieles übersehen werden kann, ist nunmal broken by Design.

[DeletedUserReAsG]

Und wenn der "befehl" /bin/bash lautet, bist du root, ohne das root-Paßwort kennen zu müssen. Und das ist nunmal der Standardfall, wenn man sudo installiert, egal ob Ubuntu oder Debian.

Ich stelle es gerne nochmal heraus:

Ich rede ausdrücklich nicht von der missbräuchlichen Verwendung unter Buntu und Co.

→ ich rede davon, dass in der sudoers ein Eintrag für genau einen User für genau die Befehle, die zum Update und Upgrade notwendig sind, vorhanden ist. Mich irritierte halt, dass das Programm ›sudo‹ „broken by design“ sein soll. Dass dessen Konfiguration unter Buntu (und halt u.U. leider auch unter Debian) kaputt ist, steht außer Frage, aber das Statement war ja, dass ›sudo‹ selbst kaputt wäre.

[bluestar]

Das ganze Konfigurationsgerüst ist so kompliziert

Da muss ich dir leider widersprechen, vielleicht zu kompliziert für dich.

Ein System, das offen ist und man es mühevoll abdichten muß

Ein Debian mit Root-Passwort und danach installiertem sudo ist nur nicht so konfiguriert, wie du es hier behauptest.

[DeletedUserReAsG]

Nachtrag:

Code: Alles auswählen

user@mtrf:~$ sudo
-bash: sudo: Kommando nicht gefunden.
user@mtrf:~$ su -c 'apt install sudo'
Passwort:
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.
Statusinformationen werden eingelesen.... Fertig
Die folgenden NEUEN Pakete werden installiert:
  sudo
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
Es müssen 1.055 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 3.108 kB Plattenplatz zusätzlich benutzt.
Holen:1 http://ftp.de.debian.org/debian stretch/main amd64 sudo amd64 1.8.19p1-2.1 [1.055 kB]
Es wurden 1.055 kB in 0 s geholt (1.816 kB/s).
Vormals nicht ausgewähltes Paket sudo wird gewählt.
(Lese Datenbank ... 135395 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../sudo_1.8.19p1-2.1_amd64.deb ...
Entpacken von sudo (1.8.19p1-2.1) ...
sudo (1.8.19p1-2.1) wird eingerichtet ...
Trigger für systemd (232-25+deb9u11) werden verarbeitet ...
Trigger für man-db (2.7.6.1-2) werden verarbeitet ...
user@mtrf:~$ sudo su

Wir gehen davon aus, dass der lokale Systemadministrator Ihnen die
Regeln erklärt hat.  Normalerweise läuft es auf drei Regeln hinaus:

    #1) Respektieren Sie die Privatsphäre anderer.
    #2) Denken Sie nach, bevor Sie tippen.
    #3) Mit großer Macht kommt große Verantwortung.

[sudo] Passwort für user:
user ist nicht in der sudoers-Datei. Dieser Vorfall wird gemeldet.
user@mtrf:~$

[bluestar]

@niemand

[guennid]

Das ganze Konfigurationsgerüst ist so kompliziert

Da muss ich dir leider widersprechen, vielleicht zu kompliziert für dich.

Ließe sich dieses spannenende Thema vielleicht auch ohne persönliche Angriffe diskutieren?

Grüße, Günther

[MSfree]

→ ich rede davon, dass in der sudoers ein Eintrag für genau einen User für genau die Befehle, die zum Update und Upgrade notwendig sind, vorhanden ist.

Das ist ein an den Haaren herbeigezogenes Beispiel. Warum sollte man ausgerechnet dafür sudo nehmen, das geht auch unattendet.

Auch das Ansehen der Logs geht ohne sudo, wenn man den dafür beauftragten in die adm-Gruppe aufnimmt. Das ist allemal sicherer als ihm Ausführrechte für irgendwelche Programme zu erteilen, mit denen er dann unter Umständen Schindluder treiben kann.

Ein Debian mit Root-Passwort und danach installiertem sudo ist nur nicht so konfiguriert, wie du es hier behauptest.

Und was willst du damit jetzt sagen? Daß kein Benutzer in der sudoers eingetragen ist? Cool, damit ist sudo also erstmal funktionslos. Und wenn du dann doch einen Benutzer einträgst, geht das Sicherheitsproblem genauso los, als wenn du Debian ohne root-Paßwort installierst, bei dem dann der erstbeste Benutzer als "root-Ersatz" in der sudoers steht.

[DeletedUserReAsG]

Das ist ein an den Haaren herbeigezogenes Beispiel. Warum sollte man ausgerechnet dafür sudo nehmen, das geht auch unattendet.

Das ist vollkommen unerheblich¹, die Frage war, welches Problem du in diesem Szenario sehen würdest, wenn du das Programm ›sudo‹ als „broken by design“ bezeichnest.

Cool, damit ist sudo also erstmal funktionslos. Und wenn du dann doch einen Benutzer einträgst, geht das Sicherheitsproblem genauso los, als wenn du Debian ohne root-Paßwort installierst, bei dem dann der erstbeste Benutzer als "root-Ersatz" in der sudoers steht.

Dass derartige Software ohne Konfiguration erstmal nichts macht, ist normal und gewollt. Wenn man dann was einträgt, und weiß was man tut, es also richtig macht, erlaubt man einem User genau einen Befehl. Wenn man’s nicht weiß, reißt man sich unter Umständen sein System auf, ja. Das geht aber mit nahzu beliebiger anderer Software genauso, oder gar noch besser (wenn sie nämlich von außen erreichbar ist).

Dass die Konfiguration kaputt ist, wenn man ohne Rootpasswort installiert, ist kein Geheimnis, und an dieser Stelle komplett irrelevant, wie nun schon mehrfach hervorgehoben. Das ist Problem der betreffenden Distri, daraus kann man kein Problem der fehlkonfigurierten Software ableiten.

Komm doch bitte mal zum Punkt: dass dir sudo nicht gefällt, ist klargeworden – kein Problem. Dass die initiale Konfiguration unter Buntu und unter Umständen auch unter Debian kaputt ist, steht ebenfalls außer Frage. Aber was ganz objektiv das Problem mit dem Programm selbst ist, diese Frage steht zumindest für mich weiterhin im Raum, während es die Kernfrage dieses Threads ist.

¹ Tatsächlich habe ich das vor langer Zeit mal so gemacht, heute ist der betreffende User weit genug, selbst die Verantwortung für sein System zu übernehmen

[bluestar]

Ein Debian mit Root-Passwort und danach installiertem sudo ist nur nicht so konfiguriert, wie du es hier behauptest.

Und was willst du damit jetzt sagen? Daß kein Benutzer in der sudoers eingetragen ist? Cool, damit ist sudo also erstmal funktionslos.

Richtig es wartest darauf korrekt konfiguriert und eingerichtet zu werden, wie so ziemlich jeder andere Dienst auch...

Und wenn du dann doch einen Benutzer einträgst, geht das Sicherheitsproblem genauso los

Das Sicherheitsproblem ist nicht sudo, sondern der Administrator der sudo falsch konfiguriert hat.

Bleib doch bitte bei den Fakten und behalte falschen Aussagen zu sudo für dich ...

Ich respektiere deine Meinung, du magst sudo nicht und das ist dein gutes Recht - niemand zwingt dich es zu nutzen.

[uname]

Der Ursprung von "sudo" lag darin, dass man einzelnen Benutzern auf Mehrbenutzersystemen für einzelne Befehle wie das Starten und Stoppen von Services die Erlaubnis geben wollte, diese als root durchzuführen. Natürlich gehörten weder /bin/bash noch der Editor Vim dazu, aus dem man mit ":sh" als root ausbrechen kann

Das Problem fing wohl damit an als wahrscheinlich Canonical dem Ubuntu-Anwender auf vor allen Desktop-Systemen keine zwei unterschiedlichen Benutzer mit auch noch unterschiedlichen Passwörtern zumuten wollte. Abgeschaut hat man das wahrscheinlich von Windows.
Hier /etc/sudoers von Ubuntu falls korrekt im Internet gefunden, Die UNIX-Gruppen admin und sudo dürfen über sudo alle root-Befehle ausführen.

Code: Alles auswählen

%admin ALL=(ALL) ALL
%sudo	ALL=(ALL:ALL) ALL

Die Idee war aber eine andere:

Sudo ist ein Programm, welches es einem Systemadministrator erlaubt, Benutzern bestimmte Root-Privilegien zu gewähren und dabei verrichtete Aktivitäten zu protokollieren. Die Grundidee ist es, möglichst wenige Privilegien zu vergeben, aber dennoch den Anwendern die Durchführung ihrer Arbeiten zu ermöglichen.

Die Betonung liegt auf bestimmte und möglichst wenige und nicht alle. Der Fehler liegt somit beim Adminstrator, der /etc/sudoers konfiguriert bzw. bei der Vorgabe durch den Distributor und die nicht vom Anwender zurückgeänderte Konfiguration.

Im übrigen halte ich die Konfiguration "ALL" (s.o.) für genauso unsicher bzw. sicher, wie wenn man für seinen Benutzer und root das gleiche Passwort verwendet, wenn mehr ist es nicht nur dass man die erneute, identische Passwortabfrage erzwingen oder auch nicht erzwingen kann

[DeletedUserReAsG]

Noch ein kleines Beispiel (kein Debian, aber tut da genauso – auf dieser Maschine ist sudo halt im Gebrauch), weil ich befürchte, dass MSfree genau dieser Punkt noch nicht ganz klar ist:

Code: Alles auswählen

niemand@archT400 ~ % sudo visudo                                                                                                                      :(
[sudo] Passwort für niemand: 
Leider darf der Benutzer niemand »/usr/bin/visudo« als root auf archT400 nicht ausführen.
1 niemand@archT400 ~ % sudo pacman -Suy                                                                                                               :(
[sudo] Passwort für niemand: 
:: Synchronisiere Paketdatenbanken...
[…]

[wanne]

Ich sehe das auch so, dass sudo broken by desighn ist. Das hat zwei gründe:

• sudo unterstützt wildcards. Defakto fürt aber jeder Wildcard zu vollen root-Rechten, weil man da subcommandos einbauen kann. Das Feature wildcard ist also broken by desighn. Da kann man direkt sudo su geben.
• Das zweite Problem an sudo ist, dass die meisten leute unterschätzen wie mächtig irgend welche Programme sind. Die wenigsten Programme sind dafür ausgelegt, dass man aus ihnen nicht irgend wie ausbüchsen kann. Sei es durch Bugs oder durch Features. Da ist es wie mit dem suid Bit. Viele oft misbrauchte Programme fragen mittlerweile sogar das suid bit ab und beenden sich dann, weil sie wissen, das sie nicht "sicher" sind. Mit sudo wird das dann gerne wieder umgangen. (Großes Beispiel bash.)
  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.
  Ich wette ich finde drei vier Methoden wie ich bei einem Update ne root-shell bekomme. apt ist einfach nicht darauf ausgelegt, dass da jemand bösartiges davor sitzt. Wenn du jemand updates machen lassen willst nutze kpackagekit oder so. Und so ist das halt für die meisten Programme.
  Es braucht besondere sorgfalte (und das bewusste weglassen von features) ein Programm so zu schreiben, dass man damit kein Schindluder treiben kann. Die wenigsten Programme sind das. Die die das sind, bieten aber auch andere Methoden als sudo an.
  Insbesondere seit Polkit und Systemd hast du da üblicherweise eine Menge alternativen.
  sudo macht IMHO nur Sinn für selbstgeschriebene Programme. (Und damit meine ich ausdrücklich nicht in bash.) Da du nur da weißt, ob es Möglichkeiten zum ausbrechen gibt. Da kannst du aber auch gleich ein suid bit setzen.

[DeletedUserReAsG]

sudo unterstützt wildcards. Defakto fürt aber jeder Wildcard zu vollen root-Rechten, weil man da subcommandos einbauen kann. Das Feature wildcard ist also broken by desighn. Da kann man direkt sudo su geben.

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.

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