Systemd v239 breaks su (and sudo)

[dufty2]

https://lwn.net/Articles/758128/

Jo, da werd' ich wohl in Zukunft auf mein geliebtes
$ su -
verzichten müssen und wieder hübsch brav via
Strg-Alt-F1
auf der virtuellen Konsole als user 'root' anmelden dürfen.

Moderne Zeiten

PS
Werd braucht denn noch root, ist doch eh alles vollautomatisiert ...

[Lord_Carlos]

Warum musst du denn NoNewPrivileges= benutzten?

[TomL]

Find ich gut ... ... imho ein längst überfälliger Schritt in die richtige Richtung zur Verbesserung der Sicherheit. Nur frag ich mich, ob dafür dann auch entsprechend das PolKit aufgewertet wird. Ich nutze das Polkit jetzt schon länger so umfassend, dass ich "sudo" schon ewig ausgemustert habe und auf meinem PC auch auf die Eingabe von "su" verzichten könnte... ich kann mich sowieso kaum daran erinnern, wann ich das das letzte Mal getan habe....

Nur eines ist mir bei der Meldung unklar, wie wird das künftig geregelt, wenn ich mich heute via SSH und mit Keyfiles als User auf meinem Server anmelden kann, um dann da via "su" zu root zu wechseln? Ist da dann eine direkte root-Anmeldung vorgesehen... dessen Einrichtung in der sshd.conf ja heute meistens nicht empfohlen wird?

[DeletedUserReAsG]

Nur eines ist mir bei der Meldung unklar, wie wird das künftig geregelt, wenn ich mich heute via SSH und mit Keyfiles als User auf meinem Server anmelden kann, um dann da via "su" zu root zu wechseln?

In dem Fall setzt du die besagte Option einfach nicht. Das ist ’ne Sache für Leute, die eben kein su o.Ä. benötigen.

Abgesehen davon: direkter Root-Login via ssh mit Schlüsseln (also nicht via Passwort) ist schon in Ordnung.

[schwedenmann]

Hallo


Komisch, ist wohl ne fake-news, oder wir haben den 1.April

Habe systemd 239-1 drauf (Debian-unstavbe) und kann trotzdem in der Konsole per su zu root werden.


Man sollte eben dem Inet , vor allen den blogs nicht allzu vertrauen.

mfg
schwedenmann

[Blackbox]

Habe systemd 239-1 drauf (Debian-unstavbe) und kann trotzdem in der Konsole per su zu root werden.

Ich habe Debian Sid installiert und ebenfalls keine Probleme mit systemd 239! - Da wollte sich wohl ein systemd-Hasser wichtig machen?

Code: Alles auswählen

ii  libpam-systemd:amd64                 239-1                          amd64        system and service manager - PAM module
ii  libsystemd0:amd64                    239-1                          amd64        systemd utility library
ii  systemd                              239-1                          amd64        system and service manager
ii  systemd-sysv                         239-1                          amd64        system and service manager - SysV links

[DeletedUserReAsG]

Man sollte eben dem Inet , vor allen den blogs nicht allzu vertrauen.

In diesem Fall: falsch, das ist ’ne offizielle Info des Hauptentwicklers von systemd – der kann man schon trauen. Man sollte nur genau lesen, und auch mal ’ne halbe Minute über das Gelesene nachdenken. Da steht nicht, dass nun irgendwas umgestellt wurde und su et al. nicht mehr funktionieren würden. Da steht nur, dass es nun die Option gibt, eine solche Rechteausweitung zu verhindern – wenn man das denn will.

[TomL]

In dem Fall setzt du die besagte Option einfach nicht. Das ist ’ne Sache für Leute, die eben kein su o.Ä. benötigen. Abgesehen davon: direkter Root-Login via ssh mit Schlüsseln (also nicht via Passwort) ist schon in Ordnung.

Jetzt überlege ich schon eine ganze Zeit, was dann (meine) Best-Practice sein wird. Auf den Desktop-PCs hab ich keinen Zweifel, da wird der Wechsel nach root auf jeden Fall deaktiviert. Beim Server bin ich noch unschlüssig. Einerseits gibt dort sowieso keine lokalen Anmeldungen, und andererseits resultiert aus der "su"-Methode eine 3-stufige Sicherheit: 1. ohne Key-File geht gar nix, 2. mein Pwd muss bekannt sein, aber selbst damit ist 'man' noch rechtelos, 3. auf dem Server muss zusätzlich das root-PWD bekannt sein.

Aber egal... ist ja noch ne ziemliche Zeit hin, bis ich das entscheiden muss....

[geier22]

Das steht während des gerade vollzogenen Upgrades (siduction):

Code: Alles auswählen

systemd (239-1) unstable; urgency=medium

  DynamicUser=yes has been enabled for systemd-journal-upload.service,
  systemd-journal-gatewayd.service, systemd-timesyncd.service,
  systemd-networkd.service and systemd-resolved.service.
  This means it is no longer necessary to statically allocate a
  systemd-journal-upload, systemd-journal-gateway, systemd-timesync,
  systemd-network and systemd-resolve user and you can now safely remove
  those system users along with their associated groups.

Wäre schön, wenn dies mal einem nicht verstehenden user gedeutet werden könnte.

su geht nach wie vor.

[DeletedUserReAsG]

Wäre schön, wenn dies mal einem nicht verstehenden user gedeutet werden könnte.

Was ist unklar? Einige Sachen, für die vorher ’n eigener User benötigt wurde, brauchen nun keinen mehr. Die entsprechenden Accounts können entsorgt werden.

su geht nach wie vor.

Warum sollte es auch nicht?

[dufty2]

Wäre schön, wenn dies mal einem nicht verstehenden user gedeutet werden könnte.

Was ist unklar? Einige Sachen, für die vorher ’n eigener User benötigt wurde, brauchen nun keinen mehr. Die entsprechenden Accounts können entsorgt werden.

Also wer sich für "DynamicUser" interessiert, kann Lennarts ausführlichen Blogpost dazu mal lesen:
http://0pointer.net/blog/dynamic-users- ... stemd.html

Warum wohl "NoNewPrivileges" nicht so schnell default wird, man muss halt man in sein /bin (und /usr/bin) gucken:
Ok, neben dem vielleicht nicht ganz so wichtigen su gibt es da noch z. B. ein
mount bzw. umount
Aber die weitere Entwicklung bleibt spannend.