Fedora: wie man mit RPM sein System auf Integrität prüft.

Heute geht es um Dateiintegrität und wie man das mit RPM prüft und ggf. behebt. Grund ist das Pinephone.

Fedora: wie man mit RPM sein System auf Integrität prüft.

Wenn man sein Pinephone zum ersten mal bootet, startet es mit dem Image auf der internen Storage mmcblk2. Will man etwas anderes Booten, so steckt man eine SD Karte rein, auf dem das Bootimage drauf ist. Das ist gerade am Anfang, wenn man viel Testet eine normale Sache, weil man die MicroSD Karte leicht wieder mit einem SD-Kartenreader am PC neu bespielen kann.

Wenn man aber zu an einen Punkt gekommen ist, wo das System gut genug funktioniert, möchte man es auf die interne Speicherkarte kopieren. Das könnt Ihr via rsync machen, oder Ihr kopiert die SD-Karte mit dem Tool dd rüber. Das hat aber einen Haken: Von dem System habt Ihr gerade gebootet und das läuft noch. Da man die Karte im laufenden Betrieb nicht wechseln sollte, steht Ihr vor einem Problem. Rsync umgeht das, aber Systemfiles lassen nicht so einfach syncen. Würde man so z.b. ein Fedora 33 auf ein anderes Fedora 33 syncen, würde es vermutlich laufen, aber (wie hier) ein Fedora auf Manjaro Syncen geht sehr wahrscheinlich voll in die Hose.

Wenn wir also dd steigt zwar die Erfolgschance, aber ein Datenverlust steht im RAM, weil die Programme auf der Partition rumwerkeln und die sich beim Kopieren ändern. Also am besten ALLES was geht beenden: Desktop, Services, alles bis auf SSHd und das Netzwerk.

Schritt 1 – Ermitteln was drauf ist

Dazu führt Ihr „rpm -qa > rpms“ aus. Nicht vergessen das File nachher wieder zu löschen.

Schritt 2 – jedes Paket prüfen

Dazu brauchen wir awk und ein klein wenig Bashmagie:

awk < rpms ‚{print „rpm -V –nolinkto –nomtime –nomode –nouser –nogroup –nordev –nodeps „$1;}‘ | bash > log

Das liest die Liste der RPMs Zeile-für-Zeile ein und prüft das Paket, ob die Checksummen mit den Dateien übereinstimmen. Einige Tests sind absichtlich abgeschaltet worden, weil für den Test, ob eine Datei beschädigt ist oder nicht, nicht nötig. Ob ich da mal dran war und die absichtlich verändert habe, war nicht die Aufgabe, kann man so aber auch machen, wenn man die –no Flags weglässt. „–nodeps“ sollte man aber drin lassen, weil sonst jedes Paket immer mit allen Abhängigkeiten geprüft wird und wir prüfen eh alle einzeln 😉

Schritt 3 – Defekte Dateien finden

Da wir in Schritt 2 eine Log-Datei angelegt haben, werten wir die aus und lassen uns gleich die Paketnamen der defekten Dateien geben. Das „sort -u“ wirft doppelte raus:

grep „\.5\.\.“ log | grep -v “ c “ | grep -v “ d „| grep -v ^S | awk ‚{print „rpm -qf „$2;}‘ | bash | sort -u

.5… ist die Ausgabe, wenn die Datei beschädigt ist und z.b. keine Configdatei ist. Configs können sich natürlich jederzeit ändern, deswegen sind die nicht gleich defekt.

Ein paar Beispiele was die Ausgaben so meinen:

S.5…… c /etc/ssh/sshd_config  Datei hat andere Checksumme, ist aber eine Configdatei
fehlend d /usr/share/man/fr/man1/manconv.1.gz Datei ist eine Dokumentation, nicht tragisch, wenn die nicht da ist.
fehlend /boot/efi/overlays/adau1977-adc.dtbo Datei fehlt und sollte aber da sein.
..5…… /usr/bin/mokutil Datei ist defekt und sollte ersetzt werden.

Schritt 4 – Reparieren

Nun haben wir eine Liste mit Paketnamen und müssen die nur noch reparieren. In meinem Fall waren es vier defekte Pakete:

dnf reinstall dcraw efibootmgr f2fs-tools mokutil -y

Das muß natürlich bei Euch so nicht passen, es könnte auch gut gehen oder andere Dateien betreffen!

Vom efibootmgr wissen wir jetzt, daß er gar nicht nötig ist auf einem Pinephone, weil das U-Boot benutzt und so gesehen kein EFI Bios vorhanden ist.

Ein Wort noch zum Pinephone:

Kopiert das System ruhig auf die interne Karte, weil das dann ca. 5x schneller ist: beim Booten, beim Runterfahren, Apps starten und updaten. Es lohnt sich wirklich.

Systemd: Aus den Wirren des Paketmanagements

„Aus den Wirren der Paketabhängigkeiten im Dschungel von Systemd“ man könnte einen Roman damit betiteln 🙂  Gestern abend, es war mal wieder Serverupdatezeit, flutschte eine Anzeige eines Fedora-Paketes, daß keinen Sinn machte, über den Bildschirm: qrencode-libs

QR Codes auf einem Server?

Ja, wenn man eine Webseite hat, die z.b. QR Codes ausgibt, weil eine HandyApp einen Bestätigungscode haben will, warum nicht. Dummerweise hatte dieser Server genau einen Job und der hatte nichts mit QR Codes zu tun. „Naja,ok, das wird jemand mal irgendwann für was ausprobiert haben… kann weg!“ denkste Dir so.. und dann kommt das Erwachen: „Wieso will dnf jetzt systemd löschen?“

$ sudo dnf erase qrencode-libs
[sudo] Passwort für  ….. :
Fehler:
Problem: The operation would result in removing the following protected packages: systemd

Das kommt so …

Der Systemd hat eine harte Abhängigkeit auf die lib von dem qrencoder :

$ rpm -q -R systemd | grep qrenc
libqrencode.so.3()(64bit)

ganz genau genommen ist es journalctl:

$ ldd /usr/bin/journalctl |grep qrenc
libqrencode.so.3 => /lib64/libqrencode.so.3 (0x00007fef36540000)

„Kann mir bitte einer erklären, wieso journalctl QR CODES bauen können müßte ?????“

Kann ja wohl nur ein Fehler sein 😉   Der Maintainer bei Redhat war da jetzt anderer Meinung:

What do you mean "wrongfully"? It's "rightfullly" linking against qrencode-libs because that functionality is used by journalctl.
While somewhat unfortunate, it's correct.

Steht aber allein da, denn auch bei Manjaro Linux ist das schon mal jemandem vor mir aufgefallen und siehe:

https://forum.manjaro.org/t/systemd-238-51-1-has-picked-up-a-dependency-on-qrencode/43070

Could this be due to a dirty chroot?

$ ldd `which journalctl`
	linux-vdso.so.1 (0x00007fff47fc9000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f55fd82e000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f55fd477000)
	libsystemd-shared-238.so => /usr/lib/systemd/libsystemd-shared-238.so (0x00007f55fd027000)
	libqrencode.so.4 => not found

I’m pretty certain journalctl doesn’t need qrencode?

Das sehe ich auch so, trotzdem habe ich mal etwas geforscht und die Ursache gefunden:

journalctl .c

#if HAVE_QRENCODE
/* If this is not an UTF-8 system don’t print any QR codes */
if (is_locale_utf8()) {
fputs(„\nTo transfer the verification key to your phone please scan the QR code below:\n\n“, stderr);
print_qr_code(stderr, seed, seed_size, n, arg_interval, hn, machine);
}
#endif

Jetzt wirds spannend:

Wozu wird das benutzt?

Um, wenn es ein UTF8-System ist UND der Code mit dem QR Support kompiliert wurde, einen Verifikations Schlüssel als QR CODE fürs Handy auszugeben, um mit dem Versiegelungs-Schlüssel abgesicherte Journaleinträge zu prüfen.

Das Verfahren heißt bei Systemd Forward Secure Sealing (FSS).  Keine Ahnung wer das Feature von Journald nutzt. Es klingt jedenfalls nach einer brauchbaren Idee, falls ein Hacker die Einträge manipuliert. Ich bezweifle aber stark, daß der Key dabei per QR Code an ein Handy übermittelt werden muß, statt per SCP an einen anderen Server.

Für diese eine Zeile Code da oben, die kaum jemand jemals einsetzen wird (Bitte Zahlen liefern, wer welche hat), immer noch diese Lib mit sich rumschleppen… was solls, GB sind billig  😉

Wie man sich RPM Scripte ansieht

Heute geht es um RPMs und die Install und Uninstall Scripte die RPMs so mit sich rumschleppen.

Wie man RPM-Files genauer betrachtet

Zunächst schauen wir mal in ein RPM am Beispiel des Zoomclienten für Linux rein, was überhaupt drin ist:

# rpm -ql ./zoom_x86_64.rpm

Allerdings sieht man dabei nur die Dateien des RPM, aber nicht die Scripte oder die Info des RPM:

# less zoom_x86_64.rpm

Ja, genau, less 🙂 Wer hätte das gedacht, daß dies beides gleichzeitig anzeigt 🙂

Name : zoom
Version : 2.8.183302.0415
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : default
Size : 246299262
License : see https://www.zoom.us/
Signature : RSA/SHA1, Di 16 Apr 2019 09:02:21 CEST, Key ID b903bf1861a7c71d
Source RPM : zoom-2.8.183302.0415-1.src.rpm
Build Date : Di 16 Apr 2019 08:59:45 CEST
Build Host : localhost
Relocations : / 
Packager : Zoom Linux Team <linux-dev@zoom.us>
Vendor : Zoom Video Communications, Inc.
URL : https://www.zoom.us
Summary : Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
Description :
Zoom, #1 Video Conferencing and Web Conferencing Service \nZoom, the cloud meeting company, unifies cloud video conferencing, simple online meetings, and group messaging into one easy-to-use platform. Our solution offers the best video, audio, and screen-sharing experience across Zoom Rooms, Windows, Mac, Linux, iOS, Android, and H.323/SIP room systems.
-rw-rw-r-- 1 root root 513 Jul 26 2018 /opt/zoom/Droplet.pcm
-rw-rw-r-- 1 root root 140 Sep 13 2018 /opt/zoom/Qt/WebSockets/qmldir
-rw-rw-r-- 1 root root 2637 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/DayOfWeekRow.qmlc
-rw-rw-r-- 1 root root 2703 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qml
-rw-rw-r-- 1 root root 8747 Sep 13 2018 /opt/zoom/Qt/labs/calendar/MonthGrid.qmlc
-rw-rw-r-- 1 root root 2645 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qml
-rw-rw-r-- 1 root root 7835 Sep 13 2018 /opt/zoom/Qt/labs/calendar/WeekNumberColumn.qmlc
-rwxrwxr-x 1 root root 117816 Sep 13 2018 /opt/zoom/Qt/labs/calendar/libqtlabscalendarplugin.so
-rw-rw-r-- 1 root root 4968 Sep 13 2018 /opt/zoom/Qt/labs/calendar/plugins.qmltypes
-rw-rw-r-- 1 root root 187 Sep 13 2018 /opt/zoom/Qt/labs/calendar/qmldir
-rwxrwxr-x 1 root root 64624 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/libqmlfolderlistmodelplugin.so
-rw-rw-r-- 1 root root 2341 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/plugins.qmltypes
-rw-rw-r-- 1 root root 124 Sep 13 2018 /opt/zoom/Qt/labs/folderlistmodel/qmldir

Geht natürlich auch direkt mit rpm :

# rpm -qi foo.rpm

und wer auch die Changelogs sehen will:

# rpm -qi –changelog foo.rpm

Jetzt ging es aber um die Installationsscripte, die ausgeführt werden, wenn man Pakete installiert oder eben deinstalliert:

# rpm -qp –scripts foo.rpm

Wenn man das beim Beispiel Zoom macht, kommt das raus:

# rpm -qp –scripts zoom_x86_64.rpm

Warnung: zoom_x86_64.rpm: Header V4 RSA/SHA1 Signature, Schlüssel-ID 61a7c71d: NOKEY
postinstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package installation

echo "run post install script, action is $1..."

#ln -s -f /opt/zoom/ZoomLauncher /usr/bin/zoom

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

echo current home is $HOME
remove_folder "$HOME/.cache/zoom"

update-mime-database /usr/share/mime || true
#update-desktop-database || true
if [ -x "/usr/bin/update-desktop-database" ]; then 
update-desktop-database || true
fi
postuninstall scriptlet (using /bin/sh):
#!/bin/bash
# Program:
# script to be run after package removal

echo "run post uninstall script, action is $1 ..."

[ "$1" == "0" ] || exit 0

echo current home is $HOME

if [ -L "/usr/bin/zoom" ]; then 
rm /usr/bin/zoom 
fi

#$1 folder path
function remove_folder
{
if [ -d $1 ]; then
rm -rf $1
fi
}

#$1 file path
function remove_file
{
if [ -f $1 ]; then
rm -f $1
fi
}

remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"
#remove_file "$HOME/.config/zoomus.conf"

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Orange ist das Installscript, Grün ist das Uninstallscript

Denn Sie wissen nicht, was Sie tun

Ok, was fällt uns daran auf?

echo current home is $HOME
...
remove_folder "/opt/zoom"
remove_folder "$HOME/.zoom/logs"
remove_folder "$HOME/.cache/zoom"

Es soll also im Home des Users etwas gelöscht werden ? Jetzt zeige ich Euch mal was das Script ausgegeben hat :

# dnf erase zoom
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Entfernen:
zoom x86_64 2.8.183302.0415-1 @@commandline 235 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Entfernen 1 Paket

Freigegebener Speicherplatz: 235 M
Ist dies in Ordnung? [j/N]:j
Transaktionsüberprüfung wird ausgeführt
Transaktionsprüfung war erfolgreich.
Transaktion wird getestet
Transaktionstest war erfolgreich.
Transaktion wird ausgeführt
Vorbereitung läuft : 1/1 
Löschen : zoom-2.8.183302.0415-1.x86_64 1/1 
Ausgeführtes Scriptlet: zoom-2.8.183302.0415-1.x86_64 1/1 
run post uninstall script, action is 0 ...
current home is /root
Überprüfung läuft : zoom-2.8.183302.0415-1.x86_64 1/1

Entfernt:
zoom.x86_64 2.8.183302.0415-1

Fertig.

Na? Wer hats gesehen?  … Richtig: „current home is /root“  wie sinnvoll dort Configs u.ä. zu löschen oder gar anzulegen, wo Root doch gar nicht der User ist, des es ausgeführt hat. Um das zu beheben, war der Code hier mal gedacht:

#logged_in_users=$(who -q | head -n 1)
#sorted_users=$(echo "$logged_in_users"|tr " " "\n"|sort|uniq|tr "\n" " ")
#for user in $sorted_users;do
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom..."
# remove_folder "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.zoom"
# echo "removing $(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf..."
# remove_file "$(grep -w ^$user /etc/passwd | cut -d ":" -f6)""/.config/zoomus.conf"
#done

Selbst wenn das einkommentiert gewesen wäre, wäre das wenig hilfreich gewesen, weil was wenn der User gar nicht eingeloggt ist, wenn das Uninstallscript läuft? Genau, dann würden die Files auch nicht gelöscht werden 😀  Da haben sie es dann gleich gelassen 😉

Einmal mit Profis und so..

Wieso habe ich das eigentlich nach Benutzung gelöscht? Ach ja, wegen der sechs CVE Sicherheitslücken allein in den statisch gelinkten QT5 Libraries seit September 2018 😀

#CVE IDCWE ID# of ExploitsVulnerability Type(s)Publish DateUpdate DateScoreGained Access LevelAccessComplexityAuthenticationConf.Integ.Avail.
1CVE-2018-19873119Overflow2018-12-262019-01-08
7.5
NoneRemoteLowNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. QBmpHandler has a buffer overflow via BMP data.
2CVE-2018-198723692019-03-212019-04-24
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt 5.11. A malformed PPM image causes a division by zero and a crash in qppmhandler.cpp.
3CVE-2018-198714002018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. There is QTgaFile Uncontrolled Resource Consumption.
4CVE-2018-198704762018-12-262019-04-25
6.8
NoneRemoteMediumNot requiredPartialPartialPartial
An issue was discovered in Qt before 5.11.3. A malformed GIF image causes a NULL pointer dereference in QGifHandler resulting in a segmentation fault.
5CVE-2018-19869202018-12-262019-04-25
4.3
NoneRemoteMediumNot requiredNoneNonePartial
An issue was discovered in Qt before 5.11.3. A malformed SVG image causes a segmentation fault in qsvghandler.cpp.
6CVE-2018-198655322018-12-052019-05-10
5.0
NoneRemoteLowNot requiredPartialNoneNone
A keystroke logging issue was discovered in Virtual Keyboard in Qt 5.7.x, 5.8.x, 5.9.x, 5.10.x, and 5.11.x before 5.11.3.

Den Rest der App zu analysieren habe ich mir dann gleich erspart 😉

Beworben wurde das RPM übrigens mit „ab Fedora 21“ .. das ist ja auch nur schon 4 Jahre her. Daher hat ich dann das Filedatum der Libs verwundert, denn die stammen von 2018. Ob das damit wirklich noch „ab Fedora 21“ läuft, hmm, wer weiß, ich probier es jedenfalls nicht aus 😉