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“

ups … DNF deinstalliert und nu ?

Da will man ein harmloses Update einspielen und angeblich stört so eine Lib dabei. Naja, nichts besonders. Kommt öfters vor. Man deinstalliert das fragliche Programm und installiert es wieder: fertig.  Soweit in der Theorie.

„Götter irren sich nie – Root schon!“

Der Befehl : „dnf update –allowerasing“ sollte das eigentlich auch so gleich machen, wenn man Abhängigkeitsprobleme hat.
Vielleicht hätte er das auch, wenn man stattdessen nicht versucht hätte das Paket direkt zu löschen ( dnf erase packagename ). Den dabei unterlief mir ein Fehler bei der Blindbenutzung der Bash :

dnf erase dnf update –allowerasing

Und natürlich blind auf Ja gedrückt 🙂 Schon war DNF , YUM, YUMEX und ABRT verschwunden 🙁 Jetzt versucht mal ohne Paketmanager den Paketmanager DNF zu reinstallieren. Die Lösung ist natürlich relativ einfach: RPM direkt benutzen.

Jetzt ist natürlich nur die Frage: Woher nehmen ?

Die Frage hatte ich zum Glück schon mal in einem anderen Zusammenhang gestellt : Koji

Beispiel für HTTPD: http://koji.fedoraproject.org/koji/packageinfo?packageID=280

Koji ist eine Webseite des Fedoraprojekts, auf dem alle Builds für alle Fedoraversionen verfügbar sind. Dort können alte wie Betaversionen und natürlich die aktuellen Pakete gefunden werden. Einfach Downloaden und mit rpm installieren.

Wenn man die RPMS alle in einem Verzeichnis hat ist das ganz einfach: rpm -i *rpm

Sind alle Pakete mit Abhängigkeiten vorhanden, ist das Malheur in Minuten beseitigt. Allerdings muß man ganz schön viele Pakete runterladen, deswegen zuerst nur DNF und seine Abhängigkeiten installieren, dann per DNF alles, was bei dem Erase mit eliminiert wurde.

Wer eine Liste braucht :  grep Erased /var/log/dnf.rpm.log

Oct 18 00:37:20 INFO Erased: abrt-desktop-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-cli-2.8.0-5.fc23.x86_64
Oct 18 00:37:20 INFO Erased: abrt-addon-vmcore-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-gui-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-gui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: initial-setup-0.3.37-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: abrt-addon-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-core-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: anaconda-tui-23.19.10-1.fc23.x86_64
Oct 18 00:37:21 INFO Erased: python3-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: python3-meh-0.43-1.fc23.noarch
Oct 18 00:37:21 INFO Erased: yumex-3.0.17-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-utils-1.1.31-508.fc23.noarch
Oct 18 00:37:22 INFO Erased: yum-langpacks-0.4.5-2.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-gui-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: python-meh-0.43-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: dnf-plugin-system-upgrade-0.7.1-1.fc23.noarch
Oct 18 00:37:22 INFO Erased: createrepo-0.10.3-3.fc21.noarch
Oct 18 00:37:22 INFO Erased: anaconda-yum-plugins-1:1.0-10.fc20.noarch
Oct 18 00:37:22 INFO Erased: abrt-python-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-addon-ccpp-2.8.0-5.fc23.x86_64
Oct 18 00:37:22 INFO Erased: abrt-gui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-pstoreoops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-tui-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: yum-3.4.3-507.fc23.noarch
Oct 18 00:37:23 INFO Erased: dnf-yum-1.1.10-1.fc23.noarch
Oct 18 00:37:23 INFO Erased: abrt-addon-kerneloops-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: gnome-abrt-1.2.2-3.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-retrace-client-2.8.0-5.fc23.x86_64
Oct 18 00:37:23 INFO Erased: libreport-python-2.6.4-2.fc23.x86_64
Oct 18 00:37:23 INFO Erased: abrt-addon-xorg-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-plugin-bodhi-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: setroubleshoot-3.3.11-1.fc23.x86_64
Oct 18 00:37:24 INFO Erased: policycoreutils-devel-2.4-21.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-java-connector-1.1.0-6.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-dbus-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-python3-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: abrt-2.8.0-5.fc23.x86_64
Oct 18 00:37:24 INFO Erased: libreport-python3-2.6.4-2.fc23.x86_64
Oct 18 00:37:24 INFO Erased: dnf-1.1.10-1.fc23.noarch

Natürlich kann man das jetzt mit etwas Bashmagie automatisch reinstallieren lassen. Kleiner Denkanstoß :

grep „Erased:“ /var/log/dnf.rpm.log | sed -e „s/^.*Erased:/dnf install -y/g“ | bash

Eine kleine Nacharbeit muß man dann aber noch tun: die Configfiles für YUM und DNF sollten restauriert werden, denn nach dem Install sind die wieder default. Zum Glück ist RPM clever und legt bei sowas eine Sicherungsdatei an:

-rw-r–r–. 1 root root 833 18. Okt 01:00 /etc/yum.conf
-rw-r–r–. 1 root root 833  3. Apr 2016  /etc/yum.conf.rpmsave

Und immer dran denken: bis auf  „dd if=/dev/zero of=/dev/sda1“ aka „format c:“ kann man alles unter Linux reparieren.

Java Swing und das Repainten von Komponenten

Von Zeit zu Zeit muß man Dinge tun, welche die Entwickler von Swing nicht vorgesehen hatten. Da wäre z.B. das Updaten einer JTextArea, während das Programm läuft.

Kleines Beispiel:

        for(int i=0;i<names.length;i++ ) {
            infotext = "Uploading file ... "+names[i];
            if ( infotext.length()> 55 ) 
                    infotext = infotext.substring(0, 55);
            updateInfo( infotext );
            String link = p.uploadFile(names[i].trim(),"/");
            result += "File: "+names[i].trim()+"\nShare: "+link+"\n";
        }
    JTextArea text = new JTextArea("");

    public void updateInfo(String text) {
            this.text.setText(text);
    }

Jetzt sollte man annehmen, daß die JTextArea jeweil nach dem setText() den neuen Text anzeigt. Tut sie aber nicht und das betrifft nicht nur JTextArea, sondern so ziemlich alle Komponenten von Swing.

Warum ist das so ?

Swing cacht quasi die ganzen Änderungen und führt diese erst durch, wenn Ruhe eingekehrt ist, d.b. wenn das Programm wartet. Das passiert z.b. wenn eine Dialogbox angezeigt wird. Die Verarbeitung des Programms ist dann eingestellt und es wartet z.B. auf das Drücken des OK Buttons in einem InfoRequester.

Solange das Programm aktiv läuft, gibt es keine Updates, weil das Rechenleistung kostet und sich mit der Zeit einige Inhalteänderungen ergeben haben können, die man dann gemeinsam durchführen kann. So spart das Guisystem Zeit und Resourcen.

Nun ist das Delay einer solchen Sparmaßnahme natürlich kontraproduktiv, wenn es um die kontinuierliche Anzeige neuer Inhalte geht, wie z.b. einem Progressbar oder eben einem textlichen Infofeld wie einer JTextArea.

Die Swing API bietet für Komponenten nun eine Methode repaint() an, die Swing mitteilt, daß die Komponente sich geändert hat und neu gezeichnet werden muß. Soweit, so gut. Leider wird der Rendercall wie schon erwähnt irgendwann gemacht und damit kann man repaint() solange aufrufen, bis man schwarz wird.

Dies Problem haben viele Javaentwickler. Auf den diversen Hilfeseiten findet man die wildesten und vor allem komplett falschen Lösungen für das Problem, in dem Mantraähnlich repaint() oder validate() empfohlen wird.

Alles falsch Leute, die Lösung sieht so aus:

	
        public void updateInfo(String text) {
			this.text.setText(text);
			this.paintComponents( this.getGraphics() );
	}

this bezieht sich dabei auf den eigentlichen Frame z.B. das Panel in dem die Komponente untergebracht ist. paintComponents(g) zeichnet alles neu und damit auch den aktualisierten Text der Area. Der Grund wieso Swing mit Delays arbeitet zeigt sich deutlich, wenn man mehrfach pro Sekunde paintComponents(g) aufruft. Nicht nur daß man die Updates im Viewport sehen kann, es dauert auch so lange, daß man tatsächlich Performanceeinbrüche haben kann. Damit wäre geklärt, wieso es normalerweise delayed ist.

Fazit: Swing ist eindeutig zu langsam konstruiert.