Installer Root das anmelden erlauben j/n und user anlegen

[inne]

Hallo,

hatte der D-I nicht mal die Punkte/Fragen:

* soll root das anmelden erlaubt werden – Stichwort su/sudo
* und ob man einen normalen user uid 1000 anlegen will

Bei einer Installation in einer VM wollte ich kein root sondern einen user /staff/ mit uid 1000 und sudo, damit sich keiner mit su und root-pw weitere Rechte holen kann.

Aber das scheint es nicht mehr zu geben?

[cronoik]

Zumindest in der Expertenvariante fragt er, ob ein root user angelegt werden soll. Wenn das nicht gewünscht ist, soll man einfach kein Passwort für diesen vergeben.

[cosinus]

Hi,

gib doch dem root ein Passwort, das du dann für dich behälst.

Den staff-user den du da anpeilst müsstest du aber rechtemäßig weiter bescheiden. Denn mit sudo su und dem Passwort des users 'staff' wird er ja sonst gleich root.

--
Arne

[inne]

Staff dürfe natürlich root werden aber eben andere konten nicht selbst wenn sie mein pw kennen.

Nagut ich schau mal wie man das nochmal selbst bastelt. denn es gibt noch ein 2. programm das nicht su ist um root zu werden. ich finde das nur gerade nicht. und ich weiss nicht ob dort die PAM-Beschränkung der Gruppe wheel greift.

[MSfree]

Eigentlich ist es egal, was man bei der Installation angibt.

Man kann durch editieren der /etc/passwd dem Standardbenutzer die UID auch nachträglich ändern.
Und root kann man auch nachträglich noch ein Passwort verpassen, sollte man das versehentlich vergessen haben, mit sudo passwd root.

[inne]

Zumindest in der Expertenvariante fragt er

Ah okey, dann liegt dort mein Fehler – vielen Dank

[inne]

sudo passwd root.

Ich weiss, das will ich aber nicht tun... und das könnte auch nur der eine user (staff o.ä.)

[cosinus]

Aber warum soll root denn kein Passwort bekommen?
Wenn jmd mit staff sich in das System hackt, kann er doch wieder root werden

Was genau willst du denn so verhindern?

[inne]

Was genau willst du denn so verhindern?

Wenn zum Beispiel user inne der kein su kann gehackt wird und das Hacker-Skript mein root druckprobiert, kann er nicht su benutzen und sudo auch nicht. das kann nur der user staff der als admin herhalten soll. oder der user debian-tor oder debian-transmission die mir auf meinem system noch konkret einfallen.
Ich weiss nicht ob ich einen denkfehler habe aber das war so meine Überlegung.

Konkret Plane ich eine Neuinstallation und da wollte ich das zukünftig so wie bei Ubuntu handhaben.

[cosinus]

Wenn der Cracker es denn unbedingt auf den root Zugang abgesehen hat. Er kann ja schon ne Menge Unsinn treiben wenn er "nur" mit deinem User 'inne' drin ist. Vllt will dann der Angreifer nicht dein System zerstören oder ein rootkit installieren, sondern nur die Daten des Benutzers 'inne' oder deine Dateien klauen um dich damit zu später erpressen whatever.

Also du hast schon ein schweres Problem wenn ein Angreifer auch als nicht root in dir drin ist

[TomL]

Was genau willst du denn so verhindern?

Wenn zum Beispiel user inne der kein su kann gehackt wird und das Hacker-Skript mein root druckprobiert, kann er nicht su benutzen und sudo auch nicht. das kann nur der user staff der als admin herhalten soll.

Ich verstehe im Moment auch noch nicht den Zusammenhang des Users "Inne" und der Verwendung "su" oder "sudo" für root/root-Jobs. Was bedeutet "mein root durchprobiert"? Wenn Du nicht via Gruppe "sudo" und sudoers root-Rechte hast, kann er auch nix durchprobieren. Deswegen bin ich ja der Meinung, "sudo" ist eigentlich heute völlig überflüssig. Man kann exakt das gleiche mit nem Alias auf "pkexec" erreichen, ohne die schwer kontrollierbaren Schwächen von "sudo" zu haben. Und ausserdem, die beiden Befehle "su" und "sudo" kann doch jeder User im Terminal absetzen.... und wenn derjenige das root-Password kennt, kann er mit beiden Befehlen alles machen.

Ob der User nun staff, inne oder Kaiser-Franz-Josef heisst, ist doch völlig unerheblich.... wenn er das root-Passwort kennt, hat er root-Rechte. Und falls ein anderer User oder ein Hacker-Script das inne-Konto hackt, dann wurde halt nur das inne-konto gehackt, aber derjenige ist deshalb noch lange kein root und kann imho auch nicht das System als ganzes kompromittieren. Das einzig vorstellbare wäre ein Keyboard-Logger, der im inne-Account läuft. Das würde ich aber nicht mit dem User "staff" lösen, sondern in dem ich das Script beseitige.... und zwar, in dem ich zuallerst mein Home-Dir durch neu-erstellen desinfiziere. Und ich würde auf "sudo" verzichten.

[cosinus]

Ich glaub inne meint, wenn ein Angreifer root werden will, muss dieser zuerst mal den User hacken, der sudo machen darf. Mit su kommst du zwar aus jedem User in root rein wenn du das Passwort zu root kennst, aber inne will das ja so machen wie es Standard bei Ubuntu ist, also rootlogin nicht möglich.

@inne: du weißt aber schon, dass diese ganze "rooterei" nix bringt wenn der Angreifer physikalischen Zugang zu deiner Kiste hat? Da hilft dann nur Vollverschlüsselung also dm-crypt/cryptsetup, nur /boot unverschlüsselt und starkes Passwort für das Cryptp-Device.

[TomL]

Ich glaub inne meint, wenn ein Angreifer root werden will, muss dieser zuerst mal den User hacken, der sudo machen darf. Mit su kommst du zwar aus jedem User in root rein wenn du das Passwort zu root kennst, aber inne will das ja so machen wie es Standard bei Ubuntu ist, also rootlogin nicht möglich.

Aber genau da existiert doch eine viel größere Gefahr der System-Kompromittierung, weil doch quasi der User selber System-Admin ist und Änderungen am System durchführen kann, und das möglicherweise mit seinem eigenen Password. Die Alternative mit dem User "staff" würde ich nur als sinnvoll erkennen, wenn sich der "Hauptbenutzer" regulär ausloggt und im Displaymanager erneut als User "staff" wieder einloggt. In dem Fall findet keine User-Substitution statt, sondern ein echter User-Wechsel, hin zu einem User mit root-Rechten. Aber genau das tun die Ubuntus nicht... da ist der Hauptbenutzer selber in der Gruppe "sudo" enthalten und hat das Recht "sudo"-Statements abzusezten.... also eher angelehnt an die Windows-Welt, weg von der bei Debian bestehenden Sicherheit per default-Verzicht auf "sudo"

[inne]

Ich glaub inne meint, wenn ein Angreifer root werden will, muss dieser zuerst mal den User hacken, der sudo machen darf. Mit su kommst du zwar aus jedem User in root rein wenn du das Passwort zu root kennst, aber inne will das ja so machen wie es Standard bei Ubuntu ist, also rootlogin nicht möglich.

So will ich das. Ich denke das ist auch kein Denkfehler und genau der Vorteil eines solchen Setups.

Bei dem von TomL sehe ich nur den Nachteil – wenn man das Root-PW kennt bzw. erraten kann.

@inne: du weißt aber schon, dass diese ganze "rooterei" nix bringt wenn der Angreifer physikalischen Zugang zu deiner Kiste hat? Da hilft dann nur Vollverschlüsselung also dm-crypt/cryptsetup, nur /boot unverschlüsselt und starkes Passwort für das Cryptp-Device.

Das führt zu weit.

PS: @TomL: pkexec das meinte ich oben mit dem anderen Programm – Danke.

[cosinus]

Ubuntu ist ja auch auf Einsteiger ausgelegt...der soll nicht gleich root werden oder sein Konto und das von root auch noch schützen/pflegen und ich denke die wollen verhindern, dass DAUs sich grafisch als root anmelden. Naja, kann man drüber streiten. Bequemer ist die Ubuntu-Variante wohl schon. Wenn ein User mit sudo alles darf, ist er ja auch mit root gleichzusetzen. Nur dass er vorher ein Befehl, den nur root geben darf, mit sudo ausführen und dann sein Passwort noch eingeben muss.

Aber man kann sudo ja auch anders nutzen, ich glaube dafür war es doch auch ursprünglich gedacht: dass man einem User gezielt bestimmte Programme freischaltet, die Rootrechte erfordern, ohne ihn gleich zum root bzw Admin machen zu müssen.

[cosinus]

So will ich das. Ich denke das ist auch kein Denkfehler und genau der Vorteil eines solchen Setups.

Kann man so oder so sehen. Ich hab für root lieber ein (starkes) Passwort.

Bei dem von TomL sehe ich nur den Nachteil – wenn man das Root-PW kennt bzw. erraten kann.

Es kommt drauf an was du für Angriffsszenarios du da ins Leere laufen lassen willst. Von remote zB über SSH brauchst das Gnaze getue nicht, einfach in der sshd_conf root das einloggen verbieten. Bei lokalen Angriffen führt eigentlich kaum was an Systemverschlüsselung vorbei. Schließ kann ich auch von livesystem booten und dann in den Konfigdateien rumfuchteln. Da ist dann kein Schutz ohne Verschlüsselung.

Das führt zu weit.

Nee eben nicht! Wenn du lokale Angriffe verhindern willst.