Gelöst: Netflix M7702-1003 & FireFox 66

Schlafen Sie gut, weil Sie ein Backup von Ihren Daten und Computern haben? Dann sollten Sie jetzt nicht weiter lesen, es könnte für schlaflose Nächte sorgen.

Backups

„Backups“ der Mythos von der Unverwundbarkeit eines Computers. Ich wußte schon immer, daß es nie so schön ist, wie man sich das einredet. Aber so krass….. Es hat sich ja eingebürgert, daß man bei Geschichten nicht am Ende anfängt, sondern vorn. Also machen wir das mal:

Es war ein regnerischer Tag im März, vorgestern um genau zu sein. Da sollte ein Gerät, dessen Name nicht genannt wird, sagen wir mal vom Typus Tabletus, zur Präsentation eines Films bei einer Veranstaltung benutzt werden. Der DisplayPort->HDMI Adapter hatte vor Wochen bereits gezeigt, daß er funktioniert und den Ton auch zum HDMI leitet. Schön, an sich. Blöd, weil ging nicht. Da stehste wie der Ochs vorm Scheuentor und der Ton muß per Chinch und selbstgestricktem Klinkenbuchsenadapter an die Lautsprecheranlage geleitet werden. Wie peinlich.

Zuhause hingesetzt und analysiert, also eigentlich direkt nach der Veranstaltung hingesetzt und Laptop mit Tablet verglichen. Laptop Ton geht, Tablet Ton geht nicht.Ton geht nicht, weil snd modul für Kernel  nicht geladen. Module nachgeladen, immer noch kein Ton. F***. Eingepackt. Nach Hause geschleppt, aufgestellt HDMI-Monitor dran, Ton bleibt weg. F***² .Ok, USB… USB… U S B ! Livedisk an den Adapter gesteckt, Reboot ins Bios, USB Bootdevice gewählt und *ZACK*  Bootentry vom OS gelöscht.. WTF!!!! Kommt auch nach Reset nicht wieder, bleibt weg, Langer M$ Mittelfinger -> Tschüss Linux!

„Nicht mit mir Burschi!“

Die Antwort auf die Frage „Wie kann einem DAS bitte in einem Bios passieren?“ lautet „Es ist von Microsoft!“.

Das Tablet hat eins der ersten von M$ selbst gebauten Biose drin und das merkt man auch. Wer packt schon einen Trademark Hinweis auf eine eigene Seite im Bios?! Das Booten von verschiedenen Bootdevices passiert mit Wischen von Rechts nach Links. Wenn man aber von „Links nach Rechts“ wischt, löscht man den Eintrag, ohne Nachfrage. Welcher Volldepp auf diese Idee gekommen ist, weiß ich nicht, aber der oder die gehört gevierteilt. Jetzt klingt es ja so, also ob ich von Links nach Rechts gewischt hätte, aber habe ich gar nicht. Ich habe gar nicht gewischt, sondern gedrückt, auf den Booteintrag, um den in der Liste zu verschieben. Das Bios ist halt nicht perfekt 🙁

Irgendwann morgens um 4 Uhr, als ich ins Bett ging, war ich so frustriert, daß alle Fixe per efibootmgr versagt haben, daß ich noch schnell ein TAR Backup vom HOME gemacht habe, es  auf einen anderen Server geschoben habe und dann ins Bett ging. Gegen 10 Uhr habe ich dann das OS neu installiert. So gegen 18 Uhr war alles wieder auf Stand. Gnome mit allen Extensions war da, FF hatte alle Plugins, alle Seiten usw. weil ich natürlich einfach mein Backup eingespielt habe, statt das alles neu zu konfigurieren und bis auf zwei Kleinigkeiten, lief das auch gut, bis Netflix dran war. Login geht. Trailer gehen, Film abgespielt und da kam Sie …  M7702-1003 . Die Fehlermeldung des Schwamms schlecht hin. Nichtmal Netflix weiß wieso die kommt. Woher ich das weiß, weil ich da gefragt habe 😉

Das Transscript dieses Gespräches mit einer BOT KI hebe ich mir für einen anderen Tag auf. Der Bot hat doch glatt behauptet, er wäre kein Bot, weil er ja Rechtschreibfehler durchs Tippen machen würde. Der hat aber so viele gemacht, das es schon wieder auffällig war und seine Argumente, liefen auch immer im Kreis, son typischer Eliza halt ;D Gut, ok, Netflix war nicht Schuld, aber halt auch keine Hilfe um überhaupt mal zu erfahren, was genau schief läuft. Was genau schief läuft wollte mir nicht mal STRACE sagen und wenn das nicht weiter weiß, gibt es nur einen anderen Grund..

S E L I N U X

Herleitung:

Wir brauchen strace  z.b. mit “ strace -f -p `pidof firefox |sed -e „s/ /,/g“` 2>/tmp/log “ und grepen dann mal durch das log und suchen nach widevine :

[pid 26822] writev(2, [{iov_base=“Sandbox: „, iov_len=9}, {iov_base=“failed to open plugin file /home/marius/.mozilla/firefox/mbmcq51y.default/gmp-widevinecdm/4.10.1196.0/libwidevinecdm.so: Permission denied“, iov_len=138}, {iov_base=“\n“, iov_len=1}], 3

Permission denied“ jo, ok, klar, Rechte falsch, kann passieren, wie auch immer, aber wäre möglich also schauen wir mal :

# pathdiscover /home/marius/.mozilla/firefox/mbmcq51y.default/gmp-widevinecdm/4.10.1196.0/libwidevinecdm.so

‚/home/marius/.mozilla/firefox/mbmcq51y.default/gmp-widevinecdm/4.10.1196.0/libwidevinecdm.so‘ translates to ‚/home/marius/.mozilla/firefox/mbmcq51y.default/gmp-widevinecdm/4.10.1196.0/libwidevinecdm.so‘

6834 kb        marius/marius -rwx—— :     libwidevinecdm.so ( regular file )
4096 Bytes   marius/marius drwxr-xr-x :   4.10.1196.0 ( directory )
4096 Bytes   marius/marius drwxr-xr-x :   gmp-widevinecdm ( directory )
4096 Bytes   marius/marius drwxrwxr-x : mbmcq51y.default ( directory )
4096 Bytes   marius/marius drwx—— :   firefox ( directory )
4096 Bytes   marius/marius drwxr-xr-x :  .mozilla ( directory )
36864 Bytes marius/marius drwx—— :   marius ( directory )
4096 Bytes  root/root            drwxr-xr-x : home ( directory )

Das sieht ja mal blöd aus. Blöd, weil alles korrekt!  WTF.. und wenn Du dann WTF sagst, sag auch gleich SELINUX 😀  Ein setenforce 0 später und schon lud Firefox das Modul wieder und NetFlix plärrte mit einem anderen Fehler weiter rum, der lag aber an dem Netflix HD Addon und war dann schnell behoben! Jetzt gibts zwei Wege, entweder man richtet den Context jedes Files einzeln, oder man erspart sich das, touched mal kurz /.autorelabel und macht einen Reboot!

Netflix Fehlercode: M7702-1003 … Gelöst! Nächstes Rätsel!

Und der Bot wollte unbedingt von mir, daß ich Chrome benutze :DD

Powertop SegFaultet … schon wieder

TPM2 Update zerlegt Fedorainstallation

Ihr habt einen TPM Chip im System ? Ihr setzt Fedora ein und habt deswegen den TPM Chip im Bios abgeschaltet ? Dann jetzt bloß nicht updaten!

Was passiert, wenn SEL auf TPM trifft

Ich fürchte ja, daß es dafür schon zu spät ist, aber sei es drum: NICHT UPDATEN! Sperrt das Paket in /etc/dnf/dnf.conf mit => „exclude=tpm2*“

Ok, das wird jetzt kompliziert, also langsam lesen.

Q: Wen betrifft das ?
A: Rechnerhardware mit einem TPM Chip auf dem Mainboard.

Q: Was ist TPM ?
A: Der Trusted Platform Modul – Chip signiert und prüft im Bootprozess, ob am System rumgespielt wurde und verweigert dann ggf. den Boot. Das macht in der Theorie den Rechner sicherer. Davon ab, kann man in dem Chip auch Digitale Signaturen und andere Kryptografische Informationen speichern und prüfen.

Q: Woher weiß ich, daß ich reinen TPM Chip habe?
A: Schaut ins Bios, der Chip wird da eine Option zum Ein- und Ausschalten haben.

Q: Was verursacht das Problem ?
A: Das Paket tpm2-abrmd-policies in der Version ( tpm2-abrmd-selinux-2.0.0-3.fc29 )  aktiviert beim Update wohl den TPM Chip und/oder setzt falsche SEL Policies im System, so daß der Rechner nicht mehr sauber bootet.

Q: Passiert das immer ?
A: Wissen wir noch nicht, ich war der einzige mit Fedora und TPM Chip.

Q: Sind spezielle Kernel im Spiel ?
A: Nein, wir haben 5.0.3, 4.19.23 und 4.20.5 ausprobiert => spielt keine Rolle.

Q: Wie wirkt sich das aus ?
A: Während des Bootprozesses stürzt der Kernel mit diversen Kernel-OOPS Meldungen ab. Mit Glück bootet er durch, bei mir war vor GDM Schluß mit lustig => System halt.
Wenn er durchbootet, dann bekommt man vom ABRT laufend Meldungen über Kernel-Abstürze, die automatisch behoben werden, teilweise 4x pro Minute.

Gegenmaßnahmen

als Root: systemctl stop tpm2-abrmd;systemctl disable tpm2-abrmd;

Dann rebooten und im BIOS den TPM Chip abschalten. Das hat bei mir dazu geführt, daß der vorherige Kernel 4.19.23 ( zu 4.20.5 ) sauber gestartet ist und im Bootprozess die SEL-Policies neu gesetzt wurden, im ganzen System, was ein Weilchen dauern kann. Danach lief jeder Kernel wieder normal, auch 5.0.3 .

Ein Bugreport wurde bei Red Hat abgesetzt. Ich wette, daß auch die TPM Maintainer vor einem Rätsel stehen, aber ich habe Augen- und Ohrenzeugen, da es mitten in unserer wöchentlichen LUG Sitzung passierte 😉

Update: Beitragstitel geändert, war zu reißerisch.

 

selinux-policies auf den letzten funktionierenden Stand bringen

Wie Ihr ( und .tux. )  im letzten Bericht zu selinux-policy lesen konntet, wurde das SEL Problem mit einem generellen Downgrade erstmal behoben. Heute schauen wir uns an, wie man das trotz aller Gegenwehr von Red Hat wieder auf den letzten aktuellen Stand geupdated bekommt 😉

Fedora und die Repostrukturen

Wenn man dnf downgrade benutzt, bekommt man nicht automatisch die letzte Version von einem Paket installiert, sondern nur die nächst kleinste im Repository (Repo) und genau da happerts meiner Meinung nach bei Fedora und Red Hat. Man sollte ja annehmen, daß die aktuelle Version und die vorherige Version eines Paketes zur Verfügung stehen, tun Sie aber nicht. Fedora betreibt ein Basis Repo und ein Updates Repo. Eine funktionierende alte Fassung liegt im Basis Repo, die aktuellste im Updates Repo. Zwischenversionen gibt es leider keine und das ist, denke ich, ein Fehler von Seiten der Distribution.

Immer wieder Koji

Und wieder ist es Koji, die Buildverwaltung für Fedora, die uns bei der Sache als nützliche Datenquelle dient:

https://koji.fedoraproject.org/koji/buildinfo?buildID=1076199

Dort holen wir uns die nötigen RPMs für die lokale Installation:

https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-targeted-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-devel-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-doc-3.13.1-283.34.fc27.noarch.rpm
https://kojipkgs.fedoraproject.org//packages/selinux-policy/3.13.1/283.34.fc27/noarch/selinux-policy-3.13.1-283.34.fc27.noarch.rpm

Wer meiner Anweisung gefolgt ist, und in die dnf.conf eine Sperre für das Paket eingetragen hat, muß diese Sperre jetzt natürlich wieder entfernen, bevor er das Update durchführen kann.

Manuelles DNF Update

Der Befehl „dnf update ./selinux-policy-*“ ist unser Freund:

[root]# dnf update ./selinux-policy-*
Letzte Prüfung auf abgelaufene Metadaten: vor 0:24:25 am Di 10 Jul 2018 09:59:33 CEST.
Abhängigkeiten sind aufgelöst.
================================================================================================================================================================================================================================================================================
Paket Arch Version Paketquelle Größe
================================================================================================================================================================================================================================================================================
Aktualisieren:
selinux-policy noarch 3.13.1-283.34.fc27 @commandline 541 k
selinux-policy-devel noarch 3.13.1-283.34.fc27 @commandline 1.4 M
selinux-policy-doc noarch 3.13.1-283.34.fc27 @commandline 2.7 M
selinux-policy-targeted noarch 3.13.1-283.34.fc27 @commandline 10 M

Transaktionsübersicht
================================================================================================================================================================================================================================================================================
Aktualisieren 4 Pakete

Gesamtgröße: 15 M
Ist dies in Ordnung? [j/N]:j
Pakete werden heruntergeladen:
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 
Aktualisieren : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Aktualisieren : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Aktualisieren : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Ausgeführtes Scriptlet: selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Aufräumen : selinux-policy-devel-3.13.1-283.14.fc27.noarch 5/8 
Aufräumen : selinux-policy-doc-3.13.1-283.14.fc27.noarch 6/8 
Aufräumen : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Ausgeführtes Scriptlet: selinux-policy-targeted-3.13.1-283.14.fc27.noarch 7/8 
Aufräumen : selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Ausgeführtes Scriptlet: selinux-policy-3.13.1-283.14.fc27.noarch 8/8 
Running as unit: run-ra699effd01cd4ceba2ad927e7889ce3b.service
Running as unit: run-r27b6453c4a5e4d2ab971a1766a434a30.service
Überprüfung läuft : selinux-policy-3.13.1-283.34.fc27.noarch 1/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.34.fc27.noarch 2/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.34.fc27.noarch 3/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.34.fc27.noarch 4/8 
Überprüfung läuft : selinux-policy-targeted-3.13.1-283.14.fc27.noarch 5/8 
Überprüfung läuft : selinux-policy-3.13.1-283.14.fc27.noarch 6/8 
Überprüfung läuft : selinux-policy-devel-3.13.1-283.14.fc27.noarch 7/8 
Überprüfung läuft : selinux-policy-doc-3.13.1-283.14.fc27.noarch 8/8

Aktualisiert:
selinux-policy.noarch 3.13.1-283.34.fc27 selinux-policy-devel.noarch 3.13.1-283.34.fc27 selinux-policy-doc.noarch 3.13.1-283.34.fc27 selinux-policy-targeted.noarch 3.13.1-283.34.fc27

Fertig.

Nicht vergessen die dnf.conf wieder mit einer Sperre zu versehen :

# cat /etc/dnf/dnf.conf
[main]
gpgcheck=1
installonly_limit=3
clean_requirements_on_remove=True
exclude=selinux-pol*

Damit wären wir jetzt auf dem Stand, vor dem defekten Paket und bekommen erstmal keine Updates mehr für die selinux-policies.

Ob das so clever war, die automatischen Tests zu umgehen?

Wenn ich der Darstellung im Buildsystem glauben darf, dann wurde für den Push Tests umgangen. Da es nachweislich in die Hose gegangen ist, ist das wohl keine gute Idee.

Wissen eigentlich alle was diese Policies so machen ?

mit dem Befehl „rpm -qi selinux-policy“ bekommen wir eine Beschreibung des Pakets. Leider ist die in diesem Fall äußerst schmal geraten:

„SELinux Base package for SELinux Reference Policy – modular.
Based off of reference policy: Checked out revision 2.20091117“

Daher schauen wir doch mal in ein solches Paket rein. Jetzt ist selinux-policy kein sehr nützliches Beispiel, es setzt nämlich lediglich die System-Konfiguration und andere Metainfos. Viel spannender ist das selinux-policy-targeted Paket, daß die eigentlichen Regeln enthält. U.a. finden wir dies File darin:

/usr/share/selinux/targeted/default/active/modules/100/gnome/cil

Wenn man sich das jetzt mit less ansieht, sieht man nichts, da es bzip2 komprimiert ist. Daher brauchen wir jetzt das hier:

bzless /usr/share/selinux/targeted/default/active/modules/100/gnome/cil

u.A. findet man dann dort die Beschreibungen welche Dateien welche SEL-Contexte haben sollen:

(Die Liste ist nicht vollständig und nur für die eine Gnome Klasse)

(filecon „/var/run/user/[^/]*/\.orc(/.*)?“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/dconf(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/var/run/user/[^/]*/keyring.*“ any (system_u object_r gkeyringd_tmp_t ((s0) (s0))))
(filecon „/root/\.cache(/.*)?“ any (system_u object_r cache_home_t ((s0) (s0))))
(filecon „/root/\.color/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.config(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.kde(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.gconf(d)?(/.*)?“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.dbus(/.*)?“ any (system_u object_r dbus_home_t ((s0) (s0))))
(filecon „/root/\.gnome2(/.*)?“ any (system_u object_r gnome_home_t ((s0) (s0))))
(filecon „/root/\.gnome2/keyrings(/.*)?“ any (system_u object_r gkeyringd_gnome_home_t ((s0) (s0))))
(filecon „/root/\.gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.cache/gstreamer-.*“ any (system_u object_r gstreamer_home_t ((s0) (s0))))
(filecon „/root/\.local.*“ any (system_u object_r gconf_home_t ((s0) (s0))))
(filecon „/root/\.local/share(/.*)?“ any (system_u object_r data_home_t ((s0) (s0))))
(filecon „/root/\.local/share/icc(/.*)?“ any (system_u object_r icc_data_home_t ((s0) (s0))))
(filecon „/root/\.Xdefaults“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/root/\.xine(/.*)?“ any (system_u object_r config_home_t ((s0) (s0))))
(filecon „/etc/gconf(/.*)?“ any (system_u object_r gconf_etc_t ((s0) (s0))))
(filecon „/tmp/gconfd-USER/.*“ file (system_u object_r gconf_tmp_t ((s0) (s0))))
(filecon „/usr/share/config(/.*)?“ any (system_u object_r config_usr_t ((s0) (s0))))
(filecon „/usr/bin/gnome-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/bin/mate-keyring-daemon“ file (system_u object_r gkeyringd_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gconf-defaults-mechanism“ file (system_u object_r gconfdefaultsm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/gnome-system-monitor-mechanism“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))
(filecon „/usr/libexec/kde(3|4)/ksysguardprocesslist_helper“ file (system_u object_r gnomesystemmm_exec_t ((s0) (s0))))

und in der findet sich dann kein Hinweis auf den gdm-greeter oder die gnome-session .. Womit es undefiniert ist.

Ich hab versucht da  durchzusteigen, aber das ist echt komplex das Zeugs 😉 Vielleicht will ja mal einer ein Diagnosetool dafür bauen, da berichte ich dann gerne drüber.