Die Sudo Diskussion

  • Das Beispiel:

    sollte so auch nicht gemacht werden. Richtig wäre es, wenn es dann von user pi ausgeführt werden soll so:

    Code
    pi@raspberrypi: sudo bash -c "iptables-save > /etc/iptables.rules"

    Aber, und dass ist nicht böse gemeint, woher soll jemand das wissen, der vielleicht nicht täglich mit Linux arbeitet?

    Das mit "sudo bash" ist aber ein workaround. Denn damit wird die Datei _immer neu erstellt_ und als root (... ohne "sudo bash") wird lediglich der Inhalt der Datei geändert bzw. neu geschrieben, ohne das der Zeitstempel der Datei geändert wird.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Ja, auch damit bist du noch lange kein root.

    Ach ne ... :conf:

    Zitat

    dirk@neptun:~/0sysBackup$ sudo -i

    [sudo] Passwort für dirk:

    root@neptun:~# id

    uid=0(root) gid=0(root) Gruppen=0(root)

    root@neptun:~#

    Zitat

    dirk@neptun:~/0sysBackup$ sudo bash

    alias TT='touchpad-toggle'

    root@neptun:~/0sysBackup# id

    uid=0(root) gid=0(root) Gruppen=0(root)

    root@neptun:~/0sysBackup#

    ... tbc

    oder evtl. doch ;)

    Ihr und Euer sudo ...

    btw:

    ... wenn root geperrt ist,

    ... hat sich der Admin schon was dabei gedacht und an dem System sollte kein "normaler" User mit sudo rumfummel ... imho

    cu,

    -ds-

  • Zitat

    dirk@neptun:~/0sysBackup$ sudo -i

    [sudo] Passwort für dirk:

    root@neptun:~# id

    uid=0(root) gid=0(root) Gruppen=0(root)

    root@neptun:~#

    Aus purem Interesse: Ist da root gesperrt, oder existiert der noch? Das die Gruppe root da sein muss ist mir klar.

    Aber mal ganz weg davon, wahrscheinlich gibt es da so viele Meinungen wie Leute die man fragt dazu. Ich würde sogar soweit gehen "einfachen" Nutzern die bash verwehren. Das geht aber nun schon weg vom eigentlichen Thema sudo.

  • Aus purem Interesse: Ist da root gesperrt, oder existiert der noch?

    Der user root existiert bzw. ist nicht gesperrt. Er wird evtl. nur kein Password haben.

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • Denn damit wird die Datei _immer neu erstellt_ und als root (... ohne "sudo bash") wird lediglich der Inhalt der Datei geändert bzw. neu geschrieben, ohne das der Zeitstempel der Datei geändert wird.

    Auch hier die Frage: Bist Du sicher? Ich kann das weder als root noch als nicht privilegierter user nachvollziehen – und wüsste auch nicht, woher der Unterschied kommen sollte.

  • Auch hier die Frage: Bist Du sicher? Ich kann das weder als root noch als nicht privilegierter user nachvollziehen – und wüsste auch nicht, woher der Unterschied kommen sollte.

    Z. B.:

    Code
    root@raspberrypi:~# ls -la /etc/iptables/rules.v4
    -rw-r----- 1 root root 1735 Mar 10 13:40 /etc/iptables/rules.v4
    Code
    root@raspberrypi:~# cat /etc/iptables/rules.v4 | grep -i generated
    # Generated by iptables-save v1.4.21 on Sat Jul 22 10:58:23 2017
    # Generated by iptables-save v1.4.21 on Sat Jul 22 10:58:23 2017
    # Generated by iptables-save v1.4.21 on Sat Jul 22 10:58:23 2017

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

    Einmal editiert, zuletzt von rpi444 (25. April 2018 um 14:19)

  • root darf sich nicht direkt per ssh anmelden aber ansonsten existiert er und wird ausschließlich genutzt.

    Auf deinem RasPi? Oder auf einem echten System? Für den RasPi könnte ich das nachvollziehen. Aber als Admin als root zu arbeiten finde ich bedenklich. Kann aber sein, dass ich zu alt bin und die Jugend das heute so macht. Mir würde man den A...h hochbinden, wenn ich anfangen würde root zu erlauben, ich den anderen Admins aber auch.

    • Offizieller Beitrag

    Mir wurde es so beigebracht - von einem altehrwürdigen Linuxmenschen - damals...vor vielen Monden. Allerdings verbunden mit der Anweisung zur höchsten Konzentration. Und ich sehe da auch kein Problem drin. Prozesse werden unter ihrem User gestartet und wenn ich die Kiste zerlege, weil ich nicht aufgepasst habe, krieg ich eins auf den Deckel.

  • Z. B.:

    Da kann ich Dir nicht ganz folgen: Der Zeitstempel der Datei ist deutlich neuer, als das Datum des iptables-save-Aufrufs. Offensichtlich wurde der Zeitstempel also nach diesem Aufruf noch geändert – wodurch das auf Deinem System geschehen ist, kann ich nicht beurteilen.

    Inwieweit das aber Deine These unterstützen soll, ein als root ausgeführtes iptables-save > <Datei> würde, im Gegensatz zu der Variante mit sudo bash – den Zeitstempel von <Datei> nicht verändern, erschließt sich mir nicht.

  • Inwieweit das aber Deine These unterstützen soll, ein als root ausgeführtes iptables-save > <Datei> würde, im Gegensatz zu der Variante mit sudo bash – den Zeitstempel von <Datei> nicht verändern, erschließt sich mir nicht.

    Du hast recht. Ich habe das jetzt mal mit stat genauer angeschaut:

    Code
    pi@raspberrypi:~ $ stat -c %x%y%z /etc/iptables/rules.v4
    2016-11-03 09:37:22.542025196 +01002018-04-25 15:37:25.429299586 +02002018-04-25 15:37:25.429299586 +0200

    und es entsteht kein Unterschied bzgl. timestamps (acces, modify, change), zwischen der Generierung der Datei mit und ohne "sudo bash -c".

    The most popular websites without IPv6 in Germany.  IPv6-Ausreden

    Meine PIs

    PI4B/8GB (border device) OpenBSD 7.4 (64bit): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server

    PI3B+ FreeBSD 14.0-R-p3 (arm64): SSH-Serv., WireGuard-Serv., ircd-hybrid-Serv., stunnel-Proxy, Mumble-Serv., ddclient

    PI4B/4GB Bullseye-lite (64bit; modifiziert): SSH-Server, WireGuard-Server, ircd-hybrid-Server, stunnel-Proxy, Mumble-Server, botamusique, ample

  • ? Was hat Ubuntu damit zu tun?


    Da ist ein Debian drunter (weißt du ja).

    Ja, es basiert wohl auf Debian... zumindest wird das immer gesagt. Was tatsächlich noch von diesem Ursprung vorhanden ist, kann ich aber nicht einschätzen. Tatsache ist aber, dass Debian vom Default-Installer keinen User mit sudo-Rechten aktiviert.... im Gegenteil, der Debian-Installer weist sogar sehr deutlich suggestiv darauf hin, was Debian für sicher hält:

    "Sie müssen ein Passwort für "root", das Systemadministrator-Konto, angeben. Ein bösartiger Benuter oder jemand, der sich nicht auskennt und root-Rechte besetzt, kann verheerende Schäden anrichten."

    Erst im eher kleingeschriebenen Nachsatz wird erwähnt, dass Sudo eingerichtet wird, wenn man sich bewusst gegen das Root-PWD entscheidet. Diese Unsitte mit Sudo ist ein reines Ubuntu-Vergehen.

    Die Nutzung von sudo war, ist und bleibt nützlich. Es ist der einzige Weg, ein Linuxsystem vernünftig administrieren zu können

    Sorry, nimms mir nicht übel, aber das ist Quatsch und widerspricht völlig dem Zweck von "sudo". Und der historische Hintergrund sowie die Zweckbestimmung kann überall nachgelesen werden:

    https://de.wikipedia.org/wiki/Sudo

    "Die erste Version entstand um 1980 an der State University of New York at Buffalo, weil man erkannte, dass viele Studenten Befehle brauchten, die eigentlich nur von Administratoren benutzt werden dürfen, die jedoch keine Gefahr für das existierende System darstellten."

    https://wiki.debian.org/sudo

    "Sudo (sometimes considered as short for Super-user do) is a program designed to let system administrators allow some users to execute some commands as root (or another user). The basic philosophy is to give as few privileges as possible but still allow people to get their work done. Sudo is also an effective way to log who ran which command and when."

    https://searchsecurity.techtarget.com/definition/sudo-superuser-do

    "Sudo (superuser do) is a utility for UNIX- and Linux-based systems that provides an efficient way to give specific users permission to use specific system commands at the root (most powerful) level of the system."

    Zusammenfassend kann man für den tatsächlichen Verwendungszweck "sudo" folgendermaßen feststellen, dass der "Administrator" einem ansonsten unberechtigten User das Recht gibt, einzelne Programme mit root-Rechten auszuführen. Punkt.

    Der Unterschied zwischen einem Administrator und einem Sudo-Berechtigen User ist ganz einfach: Der Administrator kann Berechtigungen vergeben, der sudo-User kann das nicht. Der Admin kann eine System-Konfiguration verändern, der sudo-User kann das nicht. Das ein normaler User mit der Verwendung von "sudo" selber Berechtigungen vergeben kann und auch noch die System-Konfiguriation verändern darf, ist schlichtweg der größte konzeptionelle Fehlgriff aller Zeiten... danke dafür Ubuntu. :thumbdown:

    Es ist der einzige Weg, ein Linuxsystem vernünftig administrieren zu können.

    Besser noch, man legt einen neuen Benutzer an, der nur iptables bearbeiten kann. Das wäre dann eine reine Umsetzung der UNIX-Philosophie.

    Das sind jetzt Aussagen, die machen mich nur noch sprachlos.....Tatsache ist, dass man als alleinverantwortlicher Admin in einem kleinen privaten Netzwerk überhaupt kein "sudo" benötigt, um alle Systeme auf sichere Art und Weise zu administrieren. "sudo" ist nicht nur unnötig und wirklich kaum hilfreich, sudo ist in Standard-Konfiguration ein absoluter Exploit, mit dem auf einfachste Weise das System kompromittiert werden kan.

    Und das zweite.... wo hast Du denn diese abenteuerliche Philosophie her? Einen eigenen User für die Pflege von Iptables anlegen? Wow! Ich lege also einen User für iptables an, und dann einen für postfix-conf, einen für dovecot-conf, einen für openvpn-conf, einen für cups-conf, einen für network-conf, einen für samba-conf, einen für apache, einen für user-rechte, einen für systemd-timesync-server, einen für den ftp-server, einen für die IP-Cam-Verwaltung, einen für die Journal-Auswertungen.... gehts noch? Das ist doch total daneben.

    Fakt ist, es gibt Adminis mit allumfassenden Rechten... und es gibt rechtelose User, die nur Rechte auf ihr Homedir haben. Aus Gründen der Arbeitsaufteilung bzw. Delegation von Aufgaben richten die Administratoren für einzelne vorhandene User explizite Sonderberechtigungen ein, damit eben ein solcher einzelner User einen Admin bei einer ganz bestimmten Aufgabe entlasten kann.... dazu nutzt dieser User dann explizit erlaubte sudo-Kommandos, die, wie framp erwähnt hat, revisionssicher gespeichert werden. Damit ist aber NIE eine allumfassende Rechte-Aneigung möglich, wie die Buntus das per Default implementiert haben. Die Buntu- und Mintrechner werden bei der ersten großen von außen kommenden Attacke Fallen, wie von der Sense gemähtes Schilf. Die Sicherheit auf diesen Kisten geht wg. dieser Verwendung von Sudo gegen Null.


    Du administrierst Linuxlandschaften und arbeitest als root bzw. hast root nicht gesperrt? Wo hast denn das gelernt?

    Dann schau Dir mal an, wie Debian das auf Enduser-Desktops vorschlägt... in der Communitiy gilt "sudo" in Buntu-Verwendung als absolutes NoGo. Und bei Fedora erhält der Installer-User ebenfalls keine "sudo"-Berechtungen. Und wirklich auf keinem einzigen meiner Linux-Installationen gibt es irgendwo das Paket "sudo", oder noch schlimmer, die grafischen Prothesen gksudo oder ksudo, die ebenfalls völlig überflüssig sind.

  • Aus purem Interesse: Ist da root gesperrt, oder existiert der noch? Das die Gruppe root da sein muss ist mir klar.

    Jetzt wird mir einiges klar..... root kann nicht gesperrt sein... niemals... es kann nur sein, dass für die Anmeldung als root (as himself) kein PWD vergeben wurde, aber root ist nie gesperrt. Man kann jederzeit auf unterschiedliche Wege root-Rechte erlangen. Und um das mal von völlig anderer Seite zu betrachten....

    ...der Kernel interessiert sich einen feuchten Kehrricht dafür, wer in der Gruppe "sudo" drinsteht oder nicht, oder in /etc/passwd oder nicht oder wer ein Password in der /etc/shadow hat oder nicht und der Kernel braucht das auch gar nicht. Den Kernel interessiert nur eines, dass systemverändernde Prozesse nur unter der UID 0 möglich sind und das zu schreibende Dateien unter der UID des jeweiligen Users geschrieben/erstellt werden.

    Und das wirklich spannende daran ist, wirklich jeder kann sogar systemverändernde Prozesse auch unter seiner eigenen UID starten. Für diese Prozesse wird dann einfach systemisch ein Kontextwechsel auf UID 0 durchgeführt, und zwar OHNE das der User selber zu root wurde, OHNE das root-PWD zu kennen, OHNE in der Gruppe "sudo" oder sonstwo mit erweiterten Rechten eingetragen zu sein.

    Wie geht das? Ganz einfach... z.B. zeigt uns das unter anderen das Programm "passwd" , welches über die Funktion https://linux.die.net/man/2/setuid nach dem Start für den Prozess einen Kontextwechsel nach/zu UID 0 durchführt, damit der User überhaupt sein Password ändern darf.... was ihm ansonsten eigentlich gar nicht erlaubt ist. Verantwortlich dafür ist das SETUID-Bit am Binary . Für dieses Programm wird nicht nachgesehen, ob root ein PWD hat, oder der User berechtigt ist, es wird einfach in der Prozessliste ein Kontextwechsel nach UID 0 durchgeführt ... und schon kann der User sein Password ändern.

    Denn gleichen Kontextwechsel führt z.b. auch systemd beim Start von allen Services durch, die nach dem Start unter einer nichtssagenden (unberechtigten) UID laufen sollen, wie z.B. Openvpn, Postfix, Dovecot, etc.... und auch systemd interessiert sich nicht dafür, wer in der /etc/shadows ein Password hat oder nicht, ob das ein realer User oder nur ein virtueller User ohne Homedir ist. Ist genau das gleiche, nur umgekehrt... gestartet wird als root UID 0, um dann den laufenden Prozess an eine andere UID zu hängen.

    Ein weiteres und wesentlich praxisnäheres Beispiel ist "pkexec" für den vom Policykit (auf Rechte) überwachten Start von Programmen. Das führt ebenfalls einen direkten Kontextwechsel des Prozesse auf UID 0 oder eine beliebige andere UID durch, völlig vorbei an sudo, sudoers oder irgendwelchen Passwort-Einstellungen in /etc/shadow oder Rechteeinstellungen, die man im Desktop-Environment einträgt.

    Letztendlich geht es nur um die Frage "Wer ist berechtigt, für seine Prozesse einen Kontextwechsel auf UID 0 im Kerneln zu veranlassen?" Für den Zusammenhang "allumfassend" kann/darf das imho nur root selber sein. Für ausdrückliche Einzelaufgaben können das im Rahmen einer Aufgabenverteilung mithilfe von sudo auch Nicht-Admins sein. Aber "sudo" zusammen mit "allumfassend" für Nicht-Admins ist einfach nur ein übler Fauxpas.

    Wer will, kann sich das auch im Kernel-Source ansehen... einfach nach setuid() suchen:

    https://git.kernel.org/pub/scm/linux/…ee/kernel/sys.c

    oder

    https://unix.stackexchange.com/questions/6140…d-vs-etc-passwd

    Einmal editiert, zuletzt von WinterUnit16246 (25. April 2018 um 18:54)

  • Jetzt wird mir einiges klar..... root kann nicht gesperrt sein... niemals... e

    Naja ... "root" schon ... korrekterweise sollte man vom Super-User, also dem Nutzer mit der UID 0. reden.

    Ganz so einfach ist das mit der S-Bit dann allerdings auch nicht.

    Das S-Bit bleibt nur bei einem Kopier-/Verschiebe-Vorgang durch den Eigentümer erhalten. In allen anderen Fällen wird es gelöscht. Ich glaube sogar, dass es beim Editieren/Ändern der Datei ebenfalls zurückgesetzt wird. Weiss ich aber nicht mehr so genau ... zu lange her

    Du musst also schon "root" bzw. Superuser sein, um das Bit setzen zu können.

    Also einfach mal so einen Kontext-Switch mit UID 0 Rechten is nicht :)

    //EDIT: Aber sonst ... ja ... so eine eigene root-shell braucht nur nen Fünfzeiler ;)

    Oder Du nutzt den sendmail-bug (falls Du ihn noch findest ;) ).

    cu,

    -ds-

  • Naja ... "root" schon ... korrekterweise sollte man vom Super-User, also dem Nutzer mit der UID 0. reden.

    Ganz so einfach ist das mit der S-Bit dann allerdings auch nicht.

    Das S-Bit bleibt nur bei einem Kopier-/Verschiebe-Vorgang durch den Eigentümer erhalten. In allen anderen Fällen wird es gelöscht.

    Dann hast Du mich missverstanden.... oder vielleicht nicht alles gelesen. Es geht nicht darum, eine Datei mit einem Setuid-Bit zu schreiben, sondern nur darum eine bestehende zu verwenden.


    Wenn ich als normaler User in dem einen Fenster das mache:

    Code
    $ id
    uid=1000(thomas) gid=1000(thomas) Gruppen=1000(thomas)
    
    $ passwd
    Ändern des Passworts für thomas.
    (aktuelles) UNIX-Passwort:

    sehe ich in einem zweiten Fenster den erfolgten Kontext-Wechsel:

    Code
    ps -aux | grep passwd
    root      4357  0.0  0.0  48840  3200 pts/0    S+   19:25   0:00 passwd

    Es geht nicht ums kopieren, sondern um den Kontextwechsel eines Prozesses im Kernel... und um die Feststellung, dass es mehr Möglichkeiten dazu gibt, als das mit "sudo" zu tun. Deswegen auch die Hinweise auf systemd und polkit.... auch die brauchen kein sudo und keine sudoers.

    Naja ... "root" schon ... korrekterweise sollte man vom Super-User, also dem Nutzer mit der UID 0. reden.

    root ist niemals gesperrt... könnte root gesperrt werden, könnte das System gar nicht mehr laufen, da dann keine Prozesse unter der UID 0 laufen würden. Wie gesagt, das Missverständnis ist, dass root nicht gesperrt ist, sondern das nur die Anmeldung als root mit eigenem root-Password verhindert wurde, wenn in /etc/shadow kein password für Root eingetragen ist... aber Prozesse unter der UID 0 sind immer möglich, ebenso wie der Kontextwechsel zum root-Account z.b. via pkexec oder setuid-Bit möglich ist.

  • Vollkommen richtig. Das mit dem Kopieren usw. sollte da nur als weiterer Erklärung dienen.

    Das mit den S-Bits ist halt die "ursprüngliche" Variante ... ich kann mich jedenfalls nicht erinnern, dass wir damals schon sudo hatten.

    //EDIT: su glaub' ich, gab's aber schon ... war, und ist, glaube ich, aber auch ein S-Bit Programm ohne Bezug zu sudo

    Wobei S-Bit Programme damals auch schon verpönt waren ...

    //EDIT 2: evtl. meint Jörg mit sperren ja einen Eintrag in der passwd mit login auf false oder so für den Nutzer mit UID 0 ...

    Wobei ich da meine Zweifel habe, dass das funktioniert.

    Hat aber imho alles schon keinen Bezug zur Frage: "sudo - Sinn oder Unsinn?" mehr ...

    cu,

    -ds-

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!