Linux: Sudo-User oder Root-Account?

Ich habe mittlerweile Verständnisschwierigkeiten mit dem Konzept sudo und root. Bisher habe ich unter Fedora einen root-Account mit eigenem Passwort angelegt. Zusätzlich hat mein normaler Benutzer sudo-Rechte (mein System wird nur von mir benutzt; kein Multiusersystem). Für gewöhnlich (kann mich nicht erinnern wann ich zu letzt den root-Account verwendet habe) benutze ich sudo um mein System zu administrieren. Mein root-Account liegt also praktisch ungenutzt herum.

Würde es Sinn machen schon bei der Installation den root-Account überhaupt nicht anzulegen, sondern einfach den Benutzer mit sudo-Rechten auszustatten? Oder gibt es vielleicht doch einen Grund den root-Account anzulegen?

Wäre es vielleicht sinnvoller den root-Account zu erstellen und dann dem Benutzer die sudo-Rechte zuverwehren? Die Administration würde dann mittels su erfolgen.

Eine kurze Internetrecherche hat mich leider sehr verwirrt zurück gelassen, was nun best practice ist.

1 „Gefällt mir“

Root ist immer noch sinnvoll für mich, wenn ich in eine Textkonsole wechsle um ein hängendes Programm im Desktop zu beenden oder sicher runterzufahren. Geht vielleicht auch mit sudo - ist aber viel mehr Tipparbeit.

Sonst mache ich alles mit sudo

1 „Gefällt mir“

Der root-Account wird immer angelegt. Bei der Installation kann man oft wählen, ob man ein Passwort anlegt. Macht man das nicht, kann man sich als root nicht einloggen. Der Account ist aber dennoch vorhanden.

Ein Nachteil kann das sein, wenn das System ein Problem hat bei dem ein Login über den Useraccount nicht mehr möglich ist. Hat man dann kein root-Passwort, muss man ein extra Rescue-System verwenden.
Auch wenn es wegen sudo im Alltag nicht verwendet wird, würde ich ein root-Passwort setzen.
Wenn es ein Singe-User-System ist, sind die Daten von Interesse ja die privaten die mit den Rechten des Users ohnehin gelesen werden können und damit auch, wenn das System kompromittiert ist ohne root oder sudo zur Verfügung stehen.

Bei meinen Systemen habe ich das schon immer so gemacht, dass der User kein sudo hat. Updates sind bei manchen Systemen auf automatisch, oft nehme ich aber Konsole via F1 und logge mich kurz als root ein. Ebenso bei hängenden Anwendungen wie von @schnedan ausgeführt.

4 „Gefällt mir“
  1. Es gibt keine signifikante Sicherheitsgrenze zwischen einem Nutzer in der Wheel/Sudo-Gruppe und Root. Siehe https://madaidans-insecurities.github.io/linux.html#root
  2. Für administrative Tätigkeiten verwendet man meistens einen Nutzer aus der Wheel-Gruppe statt Root direkt (bis auf ein paar Ausnahmen) und verwendet Sudo nur für die Schritte die notwendig sind, z.B um die Auswirkung von Fehlern zu minimieren.
  3. Für nicht-administrative Tätigkeiten/Alltagsbenutzung sollte ein Nutzer verwendet werden, der nicht in der genannten Gruppe ist.
  4. Es ist besondere Vorsicht geboten beim Wechsel zwischen diesen Benutzern, z.B. aufgrund der zahlreichen Möglichkeiten für Keylogging. Siehe https://www.kicksecure.com/wiki/Root#Advanced_Users

Ob man den Root-Nutzer sperrt, muss jeder selbst wissen, da er im Recovery-Fall auch von Nutzen sein kann. Im Notfall kann man aber auch bei deaktiviertem Root-Nutzer auf ein Live-System zurückgreifen.

5 „Gefällt mir“

Du arbeitest an einem Single User System also mit drei Benutzern.

  • root
  • user mit sudo
  • user

Wäre es dann nicht sinnvoller, wie @jdevlx geschrieben hat nur root für administrative Zwecke zu verwenden. Welchen Sicherheitsgewinn hat der user mit sudo gegenüber root?

2 „Gefällt mir“

Drei Benutzer für ein Single User System wäre mir persönlich zu unbequem. Aber ein System mit normalem user (kein sudo) und ein root-Account für administrative Zwecke erscheint mir im Alltag machbar vom Aufwand her.

Der Vorteil wäre dann, dass mein user nicht teil der wheel-Gruppe ist. Falls ich also Opfer eines Angriffs werden sollte, bei dem mein user-Passwort kompromitiert wird, wäre eine komplette Übernahme meines Systems nicht möglich. Der Angreifer müsste sich erst in meinem System breitmachen (keylogger o.ä. installieren) und mein root-Passwort in Erfahrung bringen.

Soweit jedenfalls mein Verständnis.

Was anderes kann ich auch nicht feststellen.
Wenn man verschiedene thematisch unterscheidbare Sachen zu machen hat, z.B. Finanzen, Steuern, geschäftliches, … und sonstiges, z.B. privat, kann man jeweils eigene Accounts anlegen. Dann schränkt man die bei erfolgreichem Hack jeweils abgreifbaren Daten weiter ein.

Hat keiner der Accounts sudo, geht es nur bei sehr schwerwiegenden Lücken, die genau zu dem passenden Zeitpunkt offen sein müssen, für den Angreifer weiter.
Nach meiner Erfahrung macht hinsichtlich der konkreten Thematik root/sudo keinerlei strikte Empfehlung nach Folie irgendeinen Sinn.
Man muss -wie immer in der IT- den Sachverhalt genau prüfen und die jeweils angemessene Entscheidung treffen.

Es gibt so gesehen kein sichereres Konzept als die strikte Trennung (wenn man sich nicht auch noch damit beschäftigen will).

1 „Gefällt mir“

Root kann jeden Schaden anrichten, den sollte man möglichst selten nutzen.
Ein „admin“ user mit eingeschränkten Möglichkeiten über sudoers kann administrative Aufgaben erledigen, aber nicht mal ausversehen die Platte löschen.
Ein normaler Nutzer geht ins Internet. Böse Dinge die der sich dort einfängt haben nur seine Rechte und können daher auch nur weniger anrichten.

Daher nutze ich die drei.

2 „Gefällt mir“

Der Vorteil von sudo liegt in erster Linie darin, dass du weiteren Benutzern Root-(ähnliche)-Rechte geben kannst (mehrere Administratoren), als auch Protokollierungsfunktionen, und die Option bestimmte Anwendungen/Befehle (auch ohne Passwörter) mit Rootrechten auszuführen, auch inmitten einer Reihe von weiteren Schritten.
Also eben nur dessen Featureset. Brauchst du dieses nicht, ist sudo, ganz böse gesagt, unnütz.

Würdest du sudo komplett vom System verbannen, wenn das für dich eine Option ist, hast du eine komplexere Software mit SUID-Bit weniger. Schonmal hatte Sudo ernste Sicherheitslücken, komplett ausgeschlossen ist das also auch hier nicht, dass das weitere Male Möglichkeiten zur privilege escalation schafft.
Wenn du es einfach nur nicht verwendest, bringt das aber für diesen Fall eher keinen Vorteil.

Von der Protokollierung halte Ich nichts, sofern du sie nicht komplett auf ein anderes System auslagerst. Sobald ein Angreifer Rootrechte hatte, ist es aus meiner Sicht aber auch sowieso sinnvoller das System komplett platt zu machen. Und für dieses Wissen reicht auch einfach nur das auth-log.
Ein detaillierteres Protokoll brauchst du nur in einer Situation, in der klar sein soll, welche Rootsession was (in etwa) getan hat, um hinterher evtl. weitere Schritte gegen die entsprechende Person einleiten zu können: im Vereins-/Unternehmensumfeld o.Ä..

Vorteilhaft ist es, sudo anstelle des Rootnutzers zu verwenden, aus meiner Sicht also nur aus zwei Gründen, für ein normales System das von dir administriert wird:
Komfort und eine, eher weniger nützliche, „Fehlertoleranz“ (die bei sicherer Nutzung des Rootnutzers eigentlich eher nicht nötig sein sollte, und genauso bei sudo dd … auftreten kann).
Komfort steht hierbei dafür, dass du mitten in einer Terminalsession per wget etwas herunterladen kannst, dann die Datei prüfen, und erst/direkt dann, per sudo, mit Rootrechten in /etc einfügen kannst.

Würdest du das mit eigenständigen Rootnutzer machen, würdest du in einen möglichst nur dafür verwendeten Nutzerprofil die Dateien herunterladen, dort prüfen, und dann in einer Rootsession im System einpflegen. Wget o.Ä. sind prinzipiell einfach Tabu als Root (verarbeiten von unvertrauenswürdigen Daten).
Also würdest du selbst dich um diese Trennung mit mehr Aufwand kümmern müssen.

Dafür kannst du aber hier auch gleich jede Form von Keylogging/„sudo Imitation“ vermeiden, die nicht auf höherem Level als Nutzerrechten stattfindet:
Auf eine andere TTY wechseln (Strg + Alt + F1/…) und den SAK-Key (Strg + Alt + S-Abf + K) verwenden (um alle Programme auf der aktuellen TTY zu beenden).
Wenn das System selbst sauber ist, was der Fall sein sollte wenn kein Angreifer je erhöhte Rechte hatte, wird hierdurch ein sauberes Loginprompt für dich zur Hand sein.
Ansonsten spielt es sowieso keine Rolle, dann ist dein System nämlich (potentiell) schon auf Systemebene kompromittiert.

Falls sudo gewünscht ist: Root Login sperren. Für die Systemrettung reicht ein USB Stick mit Linux Livesystem, oder ein Installationsmedium, da kannst du dann meist eh ein chroot mit Root in das System machen.

5 „Gefällt mir“

So ist das m.E. auch richtig. Für die Maschine selbst brauche ich root um immer handlungsfähig an der Konsole zu sein.
Davon abgesehen mache ich das aber z.B. bei Servern mit den Anwendungen genau so.
Dafür wird statt Docker in meiner Umgebung LXC/LXD/Incus verwendet.

Hier soll es kein root geben und lediglich unpriviligierte Accounts für die jeweilen Anwendungen. Müssen diese höhere Aufgaben durchführen, wird ggfs. auch eine sudo-basierte Konfiguration für den konkreten Anwendungsfall, z.B. Backups, dedizidierte Konfigurationsänderungen, usw. implementiert.

Davon ab, kann ich bei den vermuteten Anwendungsfällen aus der Eingangsfrage des Threads bei Verwendung von sudo nur mögliche Probleme bei kaum Nachteilen gegenüber einer Trennung der Accounts sehen.

1 „Gefällt mir“

Als Alternative zu sudo kann man auch das Tool doas einsetzen. Es gab da mal einen Bericht:

https://www.linux-community.de/ausgaben/linuxuser/2021/08/mit-doas-statt-sudo-administrative-aufgaben-erledigen/

Wenn Sie also zu den Anwendern zählen, die Sudo auf Ihrem System lediglich nutzen, um zeitweise Root-Rechte für die Systemadministration zu erlangen, dann ist Sudo für Ihren Bedarf stark überfrachtet.

Aufgrund seiner mächtigen Funktionen ist das Programm zudem geradezu ein Hacker-Magnet. In der Vergangenheit wurden in Sudo des Öfteren sicherheitskritische Bugs aufgedeckt, zuletzt im Januar 2021 [3]. Diese Fehler blieben aufgrund der Komplexität des Codes bis zu zehn Jahren unentdeckt.

Nutzt doas hier jemand?

1 „Gefällt mir“

Ich hatte mal mit doas experimentiert. An sich funktioniert das, aber wenn du sudo wirklich komplett vom System entfernen und nur auf doas setzen willst, dann kann es Probleme geben. Unter Arch setzt das Skript makepkg z.B. sudo vorraus. Ist sudo nicht vorhanden, kannst du makepkg nicht benutzen. Mir ist zwar nicht bekannt das es andere Inkompatiblitäten gibt, aber bisher setzt keine Distro doas standardmäßig ein. Da stellt sich mir die Frage, wieso jede Distro weiter auf sudo setzt, wenn man es mit doas ersetzen könnte.

1 „Gefällt mir“

Unter Debian habe Ich damit keine Probleme, aber Arch setzt da eventuell grundsätzlich auf sudo, wie auch schon mit systemd.
Im Wiki wird noch die Option eines Symlink erwähnt, wäre auch mein erster Gedanke: https://wiki.archlinux.org/title/Doas#Smooth_transition_sudo_to_doas

Exakt die gleichen Kommandozeilenoptionen haben die Programme aber nicht, wenn also sudo bei makepkg mit bestimmten Optionen aufgerufen wird, die so bei doas nicht existieren, wird es Probleme geben.

Weil sudo mehr Optionen hat. Die meisten Distros sind nicht wirklich auf Sicherheit oder spezielle Anwendungsfälle getrimmt, sondern sollen Großflächig alles mögliche abdecken: Private Computer, Server, Rechner im Unternehmensumfeld, etc..
Da ist sudo, neben der Option gar keine dieser Anwendungen systemseitig zu verwenden, die „beste“ Option, weil: Eierlegende Wollmilchsau.

Nachtrag:
Zumindest für makepkg lässt sich sudo austauschen, siehe Wiki (unter „Note:“): https://wiki.archlinux.org/title/Makepkg#Usage
(Etwas weiter nachgeschaut, wenn Sudo gar nicht installiert ist, verwendet laut Dokumentation makepkg automatisch su)

1 „Gefällt mir“