Die neuen Kernel mit Patch sind da. Alle Mann updaten!
Die Kernel laufen bislang problemlos.
Category Archives: Security
Gelöst : Chroot mit OpenSSH 7.2p2-6
Erste Hinweise zu den Ursachen des Problems
Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade (während des Schreibens dieses Artikels) Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte, um Benutzer den Zugang zum eigentlichen System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten müssen, werden die für Root nötigen Capabilities nicht mehr gesetzt.
Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:
# capsh --print Current: = Bounding set = Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups=
Ursache ist eine Änderung am SSHD aus 2015 : https://bugzilla.mindrot.org/show_bug.cgi?id=2486
Bis zu dieser Änderung konnte man keine intelligente Ausnahme für den Rootuser konfigurieren, wenn es darum ging den Benutzer in eine Chroot einzusperren, OHNE das man alle Benutzernamen des Systems in die Config einträgt. Das wäre kompletter Quatsch gewesen 😉 Deswegen mußte man sich folgendes Konstrukts bedienen:
ChrootDirectory /opt/root/ Match user root ChrootDirectory /
Übersetzt heißt das obige:
Für *ALLE* Benutzer, wechsle in eine CHROOT Umgebung im Pfad „/opt/root/“
Wenn Du ROOT bist, dann wechsle nach „/“
Und genau das führt nun zum Problem, da ChrootDirectory „/“ für die Entwickler nie als Option in Betracht kam, obwohl es ein valides Argument war. In der 7.2p2-6 wurde „ChrootDirectory“ überarbeitet und offensichtlich beschlossen, daß bei einer Chroot nie Capabilities nötig sein werden würden, was so vermutlich auch nicht für alle Server auf der Welt funktionieren wird. Das kann noch spannend werden.
Der Lösung auf der Spur
Die Lösung liegt in dem neu eingeführten Wert „none“ als Argument für ChrootDirectory. Dies hebt die ChrootBeschränkungen für den User Root wieder auf:
ChrootDirectory /opt/root/ Match user root ChrootDirectory none
Wo mit es wieder so funktioniert, wie ursprünglich gedacht.
„Thank you for the help with investigation. Do not close this bug, because it is obviously a bug that we drop root capabilities. We should not certainly do that for a UID=0 regardless the chroot option.
Once I will test the patch, I will issue the updates.
Jakub Jelen / RedHat.com“
Update: Fedora OpenSSH Alarm: Nicht updaten auf 7.2p2-6 !
Wie gestern schon berichtet, ist die openssh Version 7.2p2-6 für Fedora defekt,
Wer keinen Zugang zu seiner Monitor Konsole hat und trotzdem das Downgrade einspielen muß, kann nun auf diesen Weg zurückgreifen:
Workaround V2.0: Downgrade auf 7.2p2-3
Über den Kojilink lädt man die drei Pakete runter:
Koji : http://koji.fedoraproject.org/koji/buildinfo?buildID=756836
dann loggt man sich via defektem SSHD ein und downgraded die Files für einen oneshot CronJob:
echo „59 16 * * * root /usr/bin/rpm -U –force /tmp/openssh*rpm > /tmp/log; rm -f /etc/cron.d/onetime“ > /etc/cron.d/onetime
Die Uhrzeit muß man natürlich an seine aktuelle Zeit anpassen 😉
Dann Ausloggen und nach der Zeit wieder einloggen. Der Befehl „rpm -qa | grep openssh“ sollte dann 7.2p2-3 anzeigen, welches die letzte funktionierende Version war. Danach in /etc/dnf/dnf.conf einfügen:
exclude=openssh*
erst dann zieht das nächste Update nicht wieder die defekte Version auf den Server.
Das ganze klappt, weil der crond als „echter“ Root außerhalb der SSH Session läuft und nicht über sshd angetriggert wird.
Erste Hinweise zu den Ursachen des Problems
Wie im Bugtracker von RedHat einsehbar ist, kristallisieren sich grade Probleme mit der Chroot-Funktion vom SSHD heraus. Ist die Chroot aktiviert, was man tun sollte um Benutzer den Zugang zum System zu verweigern, so daß diese keine lokalen Angriffe fahren können, sondern in einer eigenen Umgebung arbeiten können. werden die für Root nötigen Capabilities nicht mehr gesetzt.
Capabilities sind die Eigenschaften eines Users, die erweiterte Rechte im Linuxsystem beinhalten, wie z.b. das Recht sich mit PTRACE in Prozessen einzuklinken, um diese zu belauschen oder zu verändern. Diese Capabilities machen Root erst aus und fehlen in der aktuellen sshd version:
# capsh --print Current: = Bounding set = Securebits: 00/0x0/1'b0 secure-noroot: no (unlocked) secure-no-suid-fixup: no (unlocked) secure-keep-caps: no (unlocked) uid=0(root) gid=0(root) groups=
Meine Vermutung: Da hat wer zuviel weggepatcht 😉