sudo, su & root-login + ssh

[Ozelot]

Ich spiele gerade mit einem Raspberry Pi herum (nicht mein Ideal von Freiheit, aber war ein Geschenk). In den FAQ von Raspbian lese ich folgendes:

Code: Alles auswählen

How do I make a proper root account?
Don't do this unless you're certain that you want and need a true root account. sudo will take care of root tasks for you nicely in almost all cases.
However, if you do want a root account so you can log in as root or su to a root account, just type:
sudo passwd
This will let you enter a password for the root account. Be careful to make it a secure one!
One other modification you should do, if you enable a root account, is to forbid root logins via ssh for security reasons. You can log in using a normal user account instead (such as pi), and use the su command to become root. To do this:..

Das alles irritiert mich, weil es ziemlich genau das Gegenteil von dem ist, was ich als erstes machen wollte. Jetzt bin ich etwas verunsichert: Kein Rootlogin über SSH - macht ihr das auch so? Was sind die Gründe dafür? Geht es da nur um brute-force-Gefahr bei schlechten Passwörtern, d.h. es erledigt sich, wenn man mit keys arbeitet?

Und dann das alte Thema: sudo vs. su vs. rootlogin - Ich dachte immer, das letztere sei die sauberste Lösung, weil dann auch die UID stimmt. Abgesehen davon daß mir das "sudo"-getippe auf den Keks geht..

[TomL]

Kein Rootlogin über SSH - macht ihr das auch so?

Ja, natürlich. root ist nicht berechtigt, ebenso sind alle anderen Anmeldungen verboten , Passwortanmeldung ist gesperrt. Das einzige was geht, ist meine Anmeldung mit Key. Wenn jemand hacken will, soll er gefälligst erst mal den Anmeldenamen herausfinden und nicht einfach als root alle Hundenamen und Geburtstage der Familie ausprobieren.

Ausserdem bin ich der Meinung, dass sudo und die Mitgliedschaft des Users in der Gruppe "sudo" ein NoGo ist, wenn es sich beim Anwender nicht um einen erfahrenen Linux-Kenner handelt.... zumal das heute m.E. auch völlig überflüssig ist. Wer sudo als Kommando benötigt, kann das ebenso über die policies ereichen.

Und was die Freiheit auf dem Pi angeht .... er lässt sich 1:1 wie ein normaler Debian-PC einrichten.... unter Berücksichtigung der natürlichen Grenzen durch die CPU....also idealerweise lxde oder was eigenes mit openbox. Zwischen meinem Custom-Debootstrap-Setup am PC gibts faktisch keinen Unterschied zum Netinst auf meinem Pi.... es laufen exakt die gleichen lxde-Komponenten und es sieht identisch aus ....die Unterschiede liegen lediglich in anderer Anwendungssoftware.

[Ozelot]

Hm. Für sudo habe ich ja auch wenig übrig. Aber eines verstehe ich nicht: Wenn ich Schlüssel statt Passwörtern verwende, dann fällt doch der bekannte Anmeldename nicht mehr ins Gewicht, und auch die Sache mit den Hundenamen erübrigt sich, oder?

Was die Freiheit angeht, meinte ich eher solche Sachen:
https://www.fsf.org/resources/hw/single-board-computers
http://whitequark.org/blog/2012/09/25/w ... education/

[TomL]

Aber eines verstehe ich nicht: Wenn ich Schlüssel statt Passwörtern verwende, dann fällt doch der bekannte Anmeldename nicht mehr ins Gewicht, und auch die Sache mit den Hundenamen erübrigt sich, oder?

Das kann ich nicht widerlegen.... *hmmm*... bei mir ist es halt so, dass der erfolgreich per SSH angemeldete User erst mal trotzdem absolut nix darf. Er ist nur ein angemeldeter unprivilegierter User. Um was zu "dürfen" benötigt er ein zweites Passwort, und zwar das root-Passwort des Remote-Rechners. Zwei Passworte = doppelte Sicherheit. Praktisch bedeutet das für mich Mehraufwand. Aber die konzeptionellen Überlegungen hinsichtlich der Sicherheit wiegen imho schwerer. Ich bin sowieso davon überzeugt, dass Sicherheit primär durch Konzepte und Verhalten gewährleistet wird, technische Werkzeuge und Maßnahmen unterstützen das dann zusätzlich.

[Ozelot]

Klingt sinnvoll. Für einen richtigen Server würde ich das auch so machen.. Aber vielleicht reicht bei meinem Pi auch eine Lage Sicherheit. Der wird ohnehin nur hinter einem privaten Router laufen und auch nicht 24/7. Primär werde ich ihn wohl als Proxy/VPN für besondere Fälle nutzen.

[DeletedUserReAsG]

Ich halte das Erlauben des Rootlogins via ssh ausschließlich mittels Schlüssel für sicherer, als das su auf dem System mittels Passwort zuzulassen. Zumindest bei Servern ist z.B. der häufigste Einfallspunkt www-data (wenn man etwa eines der dafür bekannten großen CMS oder selbstgeklöppelte Scripte vom httpd ausliefern lässt), und von da aus lassen sich dann bequem alle Hundenamen und Geburtstagsdaten durchprobieren. Meiner Meinung nach ist sudo genau dann sinnvoll, wenn ich einem weiteren Benutzer des Systems exakt definierte administrative Tätigkeiten ermöglichen möchte (Updates, Runterfahren des Systems, wenn etwa polkit aus Sicherheitsgründen nicht installiert ist, …).

[worker]

Klingt sinnvoll. Für einen richtigen Server würde ich das auch so machen.. Aber vielleicht reicht bei meinem Pi auch eine Lage Sicherheit. Der wird ohnehin nur hinter einem privaten Router laufen und auch nicht 24/7. Primär werde ich ihn wohl als Proxy/VPN für besondere Fälle nutzen.

Halte ich für meinen 'RasPi' genauso - root darf sich anmelden.
Eben weil das teil
1. hinter dem Router steht
2. nichts relevantes auf dieser kleinen 'Box' ist, was einem Datendieb weiterhelfen könnte
... und als Bot für DDOS-Bot-Netze ist das Teil ein Witz

Auf meinem Root-Server arbeite ich mit Keys (+ der Möglichkeit sich mit Passwort anzumelden). Die Root-Anmeldung ist deaktiviert.
Also auf öffentlichen Kisten würde ich es unbedingt wie TomL und 'niemand' halten.

Ansonsten ein kurzes 'sudo su' und Adminaufgaben können problemlos im Nu erledigt werden ...

[TomL]

...wenn etwa polkit aus Sicherheitsgründen nicht installiert ist, …).

Das ist jetzt ein Aspekt, denn ich überhaupt noch nicht bedacht habe.... ich bin bisher immer davon ausgegangen, dass gerade das Policykit die Sicherheit gewährleisten soll.

[DeletedUserReAsG]

Das mag dessen Intention sein – meine Ansicht dazu: jede zusätzliche Schicht bringt zusätzlichen Raum für Fehler. Umso komplexer, desto mehr.

[TomL]

jede zusätzliche Schicht bringt zusätzlichen Raum für Fehler. Umso komplexer, desto mehr.

Ja, das stimmt... diese Regel ist wohl genauso richtig, wie sie alt ist. Aber ich habe trotzdem Zweifel an Deiner Schlussfolgerung.... zumindest ist sie m.E nicht konsistent.... wobei ich das allerdings NUR aus der Perspektive "Debian" betrachten kann und meine Meinung auch nur auf meinen wenigen Debian-Kenntnissen beruht.

Fakt ist, dass das Polkit bei Debian per Default installiert ist, es ist sogar im magersten debootstrap-Setup ohne bewusstes Zutun meinerseits installiert. Es fehlte lediglich der grafische Poolkit-Agent, der aber in einer Desktopless-Server-Installation eh überflüssig ist. Ebenso Fakt ist, dass sudo erst mal nicht installiert ist, wenn ich beim Setup ein root-PWD vergeben habe. Das bedeutet, wenn Du sagst "polkit aus sicherheitsgründen nicht installiert, dafür aber sudo" müsste ich also das Polkit vorsätzlich deinstallieren und danach sudo absichtlich installieren.... also einen Weg gehen, der völlig gegensätzlich zu den Debian-Defaults ist.

Weiterhin denke ich, wenn theoretisch kein Tool zur Steuerung aussergewöhnlicher Userrechte vorhanden wäre, müsste ich mich also für eines von 2 Alternativen zur Nachinstallation entscheiden, entweder also für sudo oder für das polkit. Letztendlich reduziert es sich in beiden Fällen auf eine Anwendung, entweder das Programm "sudo" oder das Programm "pkexec", die beide einen Befehl in "anderem Namen" ausführen können und dazu auf spezielle Customizing-Einstellungen zur Prüfung zurückgreifen. Aber wenn ich Benutzerrechte steuern möchte, gehts eben auch nicht ohne... und da scheint es erst mal egal zu sein, mit welchem Tool ich mein Linux erweitere und damit zwangsläufig auch neue potentielle Sicherheitslücken schaffe. Denn beide stellen ja in diesem theoretischen Fall eine neue und zusätzliche Installation dar.

Aber ich denke, es ist trotzdem nicht egal, welches ich nutze.... denn das Polkit ist ja "default" und sudo eben nicht. Wenn ich "sudo" trotzdem als Befehl möchte, dann ist das auch kein Problem... ich kanns mit einem Alias zu pkexec aufs einfachste emulieren, und zwar ohne Funktionsbeinträchtigung. Und wenn das polkit eh vorhanden ist, welchen Sinn macht es, "sudo" noch nachzuinstallieren, damit man besondere Berechtigungen in der "sudoers" vergeben kann. Das gleiche ist doch auch mit den Polkit-Berechtigungen möglich.

Und nun der für mich wichtigste Aspekt. Auf einem Desktopless-Server mag man sich noch sinnvoll für eine Variante entscheiden können, entweder sudo oder polkit. Beides führt gleichermaßen zum Ziel, im Ergebnis besteht kein Untgerschied. Aber es sieht völlig anders aus, wenn man eine grafische Benutzeroberfläche hat, denn die Verwendung des Polkits ist bei ALLEN Desktops obligatorisch und somit zwangsweise implementiert. Vor diesem Hintergrund ist die zusätzliche Installation von "sudo" meiner Meinung nach völlig überflüssig und in der Tat das, was du bemängelst: ein unnötiges Sicherheitsrisiko.

Und ganz zum Schluss... ich halte "sudo" für ein überholtes Konzept und hoffe, dass das in einer der nächsten Debian-Versionen völlig abgeschafft wird. Das Polkit halte ich für einen großartigen Nachfolger für das aus den 90'ern stammende überalterte "sudo", welches wegen der moderneren Fähigkeiten imho ein deutlich feiner abgestimmtes Customizing ermöglicht und zudem auch die Belange einer grafischen Benutzerumgebung berücksichtigt.

jm2c

[DeletedUserReAsG]

Fakt ist, dass das Polkit bei Debian per Default installiert ist, es ist sogar im magersten debootstrap-Setup ohne bewusstes Zutun meinerseits installiert.

Komisch, bei mir nicht.

Code: Alles auswählen

$ aptitude search policykit-1
p   policykit-1                                                          - Rahmen für die Verwaltung von Privilegien und administrativen Verfahren    

$ ps aufx | grep pol
** 1 **

Du sagst "polkit aus sicherheitsgründen nicht installiert, dafür aber sudo"

Nein, das sagte ich so nicht. Damit ist der Rest des Textes auch nicht auf das von mir gezeichnete Bild passend. Ich sagte sinngemäß, dass genau spezifizierte administrative Aufgaben via sudo ermöglicht werden können, wenn das gewünscht ist. Zum Beispiel kann ich einem User einen Befehl samt sämtlichen Parametern und Optionen buchstabengetreu erlauben und alle anderen Verwendungsmöglichkeiten unterbinden – ich kann ihn etwa eine bestimmte Partition mit bestimmten Parametern an einem bestimmten Ort einhängen lassen, und die Verwendung von mount in jedem anderen Kontext verbieten. Gut, in dem Fall ging’s auch via fstab, aber zur Illustration sollte das Beispiel tun. Ich weiß zugegebenermaßen nicht, ob’s mit policykit auch realisierbar ist. Ich weiß aber, dass das besagte Paket von dbus abhängt, das ich z.B. ausdrücklich nicht ohne zwingenden Grund auf einem Server haben möchte.

[TomL]

Fakt ist, dass das Polkit bei Debian per Default installiert ist, es ist sogar im magersten debootstrap-Setup ohne bewusstes Zutun meinerseits installiert.

Komisch, bei mir nicht.

Ja, das ist bei nochmaligen drüber Nachdenken tatsächlich vorstellbar. Ich hatte bei meinem Debootstrap die "Recomments" nicht abbestellt, weil ich bei vorherigen Versuchen deshalb einige Probleme hatte, die "mit" nicht mehr bestanden. Vielleicht hängt das damit zusammen, dass das Polkit bei mir im Zuge der "Recomments" installiert wurde. Ansonsten habe ich da jedoch nicht eingewirkt.

Ich weiß aber, dass das besagte Paket von dbus abhängt, das ich z.B. ausdrücklich nicht ohne zwingenden Grund auf einem Server haben möchte.

Tja, "dbus".... das ist wieder ne Ebene, auf der ich nicht mithalten kann. Ich weiss nicht, ob dbus gut oder schlecht ist.... aber soweit ich weiss, ist dbus bei Desktops zur Interprozesskommunikation zwingend notwendig. Insofern habe ich mir nie darüber Gedanken gemacht und einfach nur gedacht "watt mut, datt mut" *hmmm*

[DeletedUserReAsG]

dbus ist in erster Linie mächtig und ziemlich umfassend – und bietet daher seinerseits viel Platz für Fehler. KISS ist schon nicht der schlechteste Ansatz, wenn es einem um Sicherheit geht.