Sinn und Unsinn: "sudo" oder doch "su"

[theSplit]

Da Metal_Warrior *fingerzeig* die Beiträge zum Sub-Thema "sudo" versus "su" "weggerootet" hat, möchte ich das Thema: Ob "sudo" oder "su" - Sinn und Unsinn - mal hier aufgreifen.

Meine Meinung sah in etwa wie folgt aus:
"sudo":
- um Schnell einen Befehl bzw. ein "Chain/Piped" Command(s) auszuführen
- Root Rechte sind temporär nur für diesen Befehl/Befehlskette vergegeben (danach nur wieder mit expliziter Eingabe von "sudo" vor einem weiteren Befehl)

"su":
- man will mehrere Befehle als Root ausführen, die man auch nicht zwingend pipen will...


Laut einer anderen Meinung sind beide Varianten identisch, ein Befehl wird mit "sudo" als - bzw. mit "su" unter Root, als Root ausgeführt.

---

Unter einem Mehrbenutzersystem oder vielleicht generell sehe ich dabei einige Vor- und Nachteile:

Vorteil "sudo":
Ich bin nicht im Root Konto eingeloggt, es gibt keine "root" Sitzung im Terminal die mit "exit" beenden werden muß

Nachteil "sudo":
Ich sehe den Nachteil das man per Default für 10 Minuten (mit Refresh bei Nutzung?!) alles mit "sudo" als Root ausführen kann, wenn nicht explizit mit "sudo -k" deaktiviert.
Plus die Eingabe "sudo" vor allem voranzustellen, obwohl ich doch eh "root" benötige, warum nicht gleich "su" ?

Vorteil "su":
Ich sehe das ich als Root eingeloggt bin, führe jedoch eine Terminalsitzung als Root aus - kann das exploited werden?

Nachteil "su":
Man muss sich explizit mit "exit" aus dem Konto ausloggen damit die Root-Sitzung beendet wird


Wenn wir jetzt von einem Mehrbenutzersystem sprechen, bei dem jemand Zugriff auf den Benutzeraccount hat der die "sudo" Freigabe hat, könnte dies missbraucht werden wenn nicht explizit die Timestamp zurückgesetzt wird mit "sudo -k".

Als Root eingeloggt mittels "su" sieht man relativ einfach das man nur "exit" ausführen muß bzw. das Terminal schließen.

---

Vorzeitiges Fazit:
"sudo" sollte meiner Meinung nach, immer nach einem Passwort fragen, ansonsten bliebe ja der direkte Wechsel ins Root-Konto mit "su".
Vor allem verschleiert "sudo" das es aktiv ist, im Gegensatz zum Prompt das man sich als Root eingeloggt hat.

Also müsste man bei häufigem Arbeiten, an einem Mehrbenutzersystem mit geteiltem Account (ist vielleicht nicht der Use-Case, aber who knows) - immer mit "sudo -k" zurücksetzen.
Oder "sudo" müsste einen Switch/Parameter anbieten einen Befehl einmalig als Root ausführt, aber sofort die Rechte zurücksetzt so dass das Password erneut abgefragt wird.

---

Rückfragen!
Wie ist eure Erfahrung, gibt es Meinungen dazu, gibt es mehr Vorteile und Nachteile?
Seht ihr ebenfalls Sicherheitsrisiken, oder ist das alles eher unwahrscheinlich und es sollte so bleiben?

-

Mir persönlich gefällt es zumindest besser "su" zu nutzen, das zu tun was ich mache, ist vielleicht aber auch eine Sache der Gewöhnung und wie man das selbst handhabt.

 

[Trolling Stone]

Sudo ist halt eingeführt worden für die Casual-Anwender.
Im Prinzip unnötig und wer möchte, kann sowieso su verwenden.

 

[thom53281]

"sudo" hat durchaus auch ein paar Vorteile, wenn man sich etwas damit auseinandersetzt. Man kann nämlich unter anderem auch:

• Bestimmte einzelne Befehle einem Benutzer als root ausühren lassen.
  Vor allem in größeren Mehrbenutzersystemen ganz nützlich, wenn man einem Benutzer keine allgemeinen root-Rechte geben möchte, dieser aber für eine bestimmte genau definierte Tätigkeit selbige bräuchte. Man muss aber hier genau aufpassen, welche Befehle man in welcher Form erlaubt, da sich sonst ein Benutzer unter Umständen volle root-Rechte "bauen" könnte.
• Einen Benutzer bestimmte Befehle ohne Kennwort ausführen lassen.
  Beispielsweise ganz nützlich wenn keine WaldundwiesenGUI zum Einsatz kommt um beispielsweise /sbin/shutdown zum Herunterfahren ohne Kennworteingabe zu erlauben.

Wenn man sudo natürlich, so wie es in *buntu vorwiegend OOTB gemacht wird, nur als su-Ersatz verwendet, dann halten sich die Vorteile sehr in Grenzen.

 

[Asseon]

su und sudo sind fast äquivalent, mit einigen wichtigen unterschieden in der Authentifizierung und Autorisierung.


su hat keine eigene Autorisierung sondern delegiert diese an den Kernel über die normalen "Unix-Style" Berechtigungen und benutzt das Passwort des Zielusers* für die Authentifizierung, also alle müssen die gleichen Zugangsdaten verwenden

sudo kann, wie thom schon sagte, einzelne Befehle autorisieren oder auch Zieluser* erst danach greifen wie bei su die normalen "Unix-Style" Berechtigungen. sudo benutzt das Passwort und/oder die Gruppen des ursprünglichen Users zur Authentifizierung, wodurch man individuelle Zugangsdaten umsetzen kann.


Das wars aber auch schon mit großen den unterschieden, su -c führt einen einzelnen Befehl aus und sudo -s gibt ne shell, also "sudo su" Nutzer sind pfaule Leute die keine manpage lesen können/wollen


Es ist also am ende eine frage der Präferenz und des Use case.
Alleiniger Admin: egal
Mehrere Admins: im grunde auch egal, aber sudo ergibt schon SInn
Nur bestimmte befehle: sudo
ohne Passwort: sudo






*der User unter dem der Befehl ausgeführt werden soll, das muss nicht unbedingt root sein

 

[Metal_Warrior]

Soweit ich mich erinnern kann, ist sudo auch in anderer Hinsicht praktisch: Es behält den Userkontext bei, also lässt dir deine Shell, deine Aliase und deine Variablen, wohingegen su selbst sich an Root anmeldet und damit dessen Einstellungen verwendet. Außerdem, und das ist ein weiterer Punkt für sudo, muss man bei su root explizit mit einem Kennwort versehen, d. h. root die Anmeldung am System erlauben. Abgesehen davon, dass shared secrets immer scheiße sind (weil die Kompromittierung viel wahrscheinlicher wird, je mehr Leute ein Secret kennen), ist das prinzipiell eine Sicherheitsproblematik bei Systemen, auf die mehrere Leute (sei es über ssh oder direkt) Zugriff haben: Sicherheit entsteht aus Benutzername und Kennwort. Ist beides unbekannt, potenziert sich die Zahl der Möglichkeiten bei Brute Force in schwindelerregende Höhen. Root als administrativer Benutzer ist aber jedem bekannt, d. h. die einzige Sicherheit des Kontos ist die Länge und Komplexität des Kennworts.

Generell richte ich jeden Server so ein:
root: Keine Anmeldeerlaubnis (! als Kennwort in /etc/shadow)
sudo für alle Administratoren
Eingeschränktes SSH nur für benötigte User (AllowUsers-Statement)
Ausschließlich keybasierte Authentifikation am SSH-Server

Außerdem, und das ist ein weiterer Punkt, der schon genannt wurde, kann sudo auch Leuten erlauben, die keine Admins sind, verschiedene definierte Rootbefehle auszuführen, gern auch ohne Kennwort.

Meiner Erfahrung nach sind außerdem die sudo-Nutzer eher angehalten, über die Tragweite ihrer Befehle nachzudenken, als die su-Nutzer. Vielleicht weniger in Bezug auf den Zugriff auf Configs, aber vielmehr in Bezug auf die Privatsphäre der anderen User. Wenn ls auf einem anderen Homeverzeichnis nichts ausspuckt, sudo ls aber schon, dann wird man sich bewusst, dass man gerade in die Privatsphäre eines Anderen eindringt. Im Root-Konto fällt das gar nicht auf.

 

[theSplit]

Hier tun sich ja immer mehr "sudo" Fans auf - hätte mir irgendwie klar sein müssen das es nicht einfach so "trival" ist wie ich es hier verglichen habe

Jetzt so beim vergleichen der Vor- und Nachteile, und wenn ich das Konzept so in etwa verstehe - scheint "sudo" wirklich mehr Sinn zu machen.
Aber hängt wohl auch stark vom Use-Case ab...

Das man "root" in gewisser Weise aussperren kann, war mir so auch nicht klar...
Sollte ja bei Remote Server groß zum tragen kommen.

---

Also werde ich jetzt mal etwas genauer darauf achten, ich glaube schnell verinnerlichen kann ich die Infos hier nicht - aber vielleicht hilft es ja jemand anderem unmittelbar.
Wird Zeit das ich mal mehr nachlese wie was funktioniert... vor allem auch "man" pages.

 

[Asseon]

@Metal_Warrior:
su räumt die Umgebungsvariablen nur mit "su -" komplett auf und üblicherweise ist das auch der zustand den mal haben will, weil alles andere einen potentiellen Angriffsvektor für Rechteausweitung darstellt.

sudo hat afaik ne blacklist, aber blacklists haben ihre ganz eigenen schwächen.

 

[Cazawhi]

Kommt auf die Arbeit an.
Wer fix 1-2 Befehle als root reinballern möchte, ist mit sudo gut aufgehoben, während man bei ewigen Befehlsketten, und bei einem System, in dem man sowieso alleine unterwegs ist, ruhig mit su einloggen kann.

 

[musv]

Das Problem mit den shared secrets ist durchaus korrekt. Auf Arbeit haben diverse Admins das Root-Passwort. Sobald einer aus der Firma ausscheidet, müssen auf sämtlichen Rechner die Root-Passwörter geändert werden. Ok, das geht automatisch, nervt aber schon.

Ich bin definitiv kein Freund von sudo machallesdamit. In meinen Augen ist es absolut kein Unterschied zu einer Root-Konsole, außer dass man halt immer das sudo noch vor den Befehl tippen muss. Dann lieber gleich 'ne Root-Konsole öffnen.

sudo halte ich sinnvoll für die fein granulierte Gewährung von Rechten für bestimmte User bei bestimmten Befehlen.

Früher war ich auch immer strikt dagegen, dass man sich per ssh direkt als root auf einen Rechner einloggen kann. Mittlerweile sehe ich das durch meinen Job anders. Da administrieren wir Server. Es würde extrem nerven, wenn man da immer erst über ein spezielles Konto gehen müsste. Sicherer wird das direkte Einloggen per ssh dadurch, dass man das nur über den Public Key zulässt.

 

[Metal_Warrior]

Mittlerweile sehe ich das durch meinen Job anders. Da administrieren wir Server. Es würde extrem nerven, wenn man da immer erst über ein spezielles Konto gehen müsste. Sicherer wird das direkte Einloggen per ssh dadurch, dass man das nur über den Public Key zulässt.

Das mach ich auch, und die ssh_config ist da ein großer Helfer. Für jeden Admin ein "sudo adduser $ADMIN && sudo adduser $ADMIN sudo" ist jetzt nicht ne Problematik, die ich als nervend sehen würde, eher als sinnvoll, eben auch weil nachvollziehbar wird, wer was gemacht hat. Und wenn es wirklich mal um ne halbe Stunde Arbeit als root geht, sagt ja auch keiner was gegen sudo -i / su.

[Kloogshize-Modus]
Und auch wenn ausschließlich Keys zum Login verwendet werden, sorgen unbekannte Nutzernamen trotzdem noch ein paar Potenzen mehr Sicherheit. Die Frage ist nur, ob das bei den aktuell verwendeten Keylängen noch ne Rolle spielt, aber das hat es mit Passwörtern auch mal ne Weile geheißen
[/Kloogshize-Modus]

Wie gesagt, ich sehe halt bei mir selbst und auch in der Ausbildung meiner Schützlinge, dass ein Rootlogin gerade als Admin wahnsinnig leichtfertig bezüglich der Privatsphäre anderer Leute macht. Und das kann durchaus fiese Konsequenzen haben, wenn man mal - auch versehentlich - Logs anguckt, die eigentlich einem 4-Augen-Prinzip mit Dokumentation unterliegen...

 

[Cazawhi]

Wie gesagt, ich sehe halt bei mir selbst und auch in der Ausbildung meiner Schützlinge, dass ein Rootlogin gerade als Admin wahnsinnig leichtfertig bezüglich der Privatsphäre anderer Leute macht.

"Ein Rootpasswort einrichten? Wozu DAS denn?" - Metal_Warrior Juni 2k16

 

[Metal_Warrior]

@Cazawhi: Und da stehe ich auch heute noch dazu. Kein Login einrichten, keine Probleme von dieser Seite. Mit sudo -i kannst du immer reinwechseln, wenn dus brauchen solltest, aber für den Normalfall ist das in meinen Augen nicht zweckmäßig, erst recht nicht bei Anfängern.

 

[Cazawhi]

@Metal_Warrior: Also bin ich mit sudo -i im Dauer-Sudo?
Damit wär' doch die ganze Diskussion abgeschlossen, oder?
Keine shared secrets, kein blödes rumgetue mit sudonotsudo, ich mein: passt doch!

 

[Metal_Warrior]

@Metal_Warrior: Also bin ich mit sudo -i im Dauer-Sudo?

-i steht für interactive. Also ja, jeder bis zum nächsten exit/quit eingegebene Befehl wird automatisch mit root-Rechten ausgeführt. Dabei impliziert der interactive-Modus ein -k, d. h. anschließendes erneutes Sudo muss wieder mit Kennwort authentifiziert werden.

 

[Cazawhi]

@Metal_Warrior: Is' doch mega praktisch. Linux-Knowledge lohnt sich!

 

[Asseon]

-i steht nicht für interactive bei sudo, sondern für login, und ist vergleichbar mit der Option -s, mit dem unterschied, dass der shell gesagt wird es sei ein terminal login passiert wodurch ggf weitere config Dateien geladen werden.

 

[Metal_Warrior]

@Asseon: Ich bezog mich da auf diesen Passus in der Manpage: "If no command is specified, an interactive shell is executed." - Da ich nie an ein -i ein Kommando hänge, ist sie für mich immer interactive (und so wars wohl ursprünglich auch gemeint, sonst wäre es sicher nicht -i, sondern -L geworden).