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, des 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

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.

Fedora – GDM stürzt wegen SELinux ab

Ein schlecht ausgerolltes Update der SELinux Policies unter Fedora 27 führt dazu, daß der Loginbildschirm, im Fachjargon „Greeter“ genannt, mit einer unschönen Meldung absemmelt.

Fehleranalyse

Betroffene Version:  sellinux-policy 3.13.1-283.35

Wenn Eurer GDM Greeter also mit dem „blah blah ‚Benutzer abmelden'“ Fehler stehen bleibt, dann prüft folgendes:

1. „STRG+F2“ damit Ihr eine Root Konsole bekommt

2. „grep gdm /var/log/messages oderjournalctl -xe | grep gdm

kommt dabei das hier raus:

Jul 8 01:40:51 eve systemd[1627]: selinux: avc: denied { status } for auid=n/a uid=42 gid=42 cmdline=“/usr/libexec/gdm-x-session gnome-session –autostart /usr/share/gdm/greeter/autostart“ scontext=system_u:system_r:xdm_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=system permissive=0

dann hilft Euch das hier weiter, falls keine neuere Version im Repository verfügbar ist (also vorher mit dnf -y update checken) :

dnf -y downgrade selinux-policy*
systemctl restart gdm

und anschließend das erneute Update mit dem Eintrag „exclude=selinux-p*“ in die /etc/dnf/dnf.conf verhindern.

Fazit

So eine Scheiße will einem um 1.10 Uhr nachts wirklich nicht passieren!

Probleme mit SELinux reparieren

SELinux mal wieder mal um die Ohren geflogen? Vielleicht kann dieser Artikel helfen.

Es war einmal eine neue SSD …

Vor einigen Tagen habe ich meine Systemfestplatte durch eine SSD ersetzt. Da die ganze Platte verschlüsselt war, folgte ein ziemlich aufwändiger Prozess um die Inhalte zu kopieren. Dabei wurde SELinux allerdings vergessen, was dazu geführt hat, daß Linux danach nicht mehr ganz störungsfrei lief.

Alles in allem häuften sich Meldungen wie diese :

Mar 22 23:10:48 eve python: SELinux is preventing /usr/lib64/firefox/plugin-container from open access on the file .

Da stellt sich einem Admin erstmal die Frage, welches File er da nicht öffnen konnte und wieso nicht. Leider bleibt diese Frage unbeantwortet, da das Audit von SELinux dazu schweigt. Dummerweise weiss man nicht welche Datei gemeint ist und was falsch sein könnte. Solange mein Bugreport nicht zu einer Änderung führt, werden wir das auch nie erfahren, da nicht mal strace herausfindet, welche Datei gemeint ist.

Wie Anfangs schon erwäht, wurden Daten von einer Platte auf eine andere kopiert und letztlich war das das Problem.

Was macht SELinux ?

SELinux (ab jetzt nur SEL ) kennt für fast jede Datei einen Zugriffscontext, fcontext genannt. Mit einem ls sieht man diesen Context nicht gleich, dazu muß man die -Z Option benutzen :

# ls -lad /home/
drwxr-xr-x. 4 root root 4096 20. Mär 07:03 /home/

# ls -ladZ /home/
drwxr-xr-x. root root system_u:object_r:home_root_t:s0 /home/

Das Verzeichnis /home/ hat also als Defaultcontext „home_root_t“ ( die enden fast alle auf _t, nicht fragen ). Alle Dateien in /home/ bekommen auch erstmal diesen Context. Programm die in einem Context gestartet wurden, können erstmal nicht auf Dateien in einem anderen Context zugreifen. Das verhindert, daß man durch den Hack z.b. des Apache Webservers auf systemrelevante Dateien zugreifen kann, auch wenn man durch den Hack Rootuser geworden ist. An sich eine Supersache was Security angeht.

Damit das klappt gibt es unter „/etc/selinux/targeted/contexts/files“ eine Liste mit Contexten, die Dateien zugeordnet sind. Wenn man jetzt TAR benutzt um den Inhalt einer Platte von A-> B zu kopieren, geht der Context verloren, aber SELinux findet beim Start seine Configdateien und handelt danach.

Jetzt wurden aus Platzgründen auf der SSD diese Dateien beim Kopieren beschädigt, weswegen der Rechner überhaupt gebootet hat, weil damit der Regelsatz gelöscht war. Da aber andere Dateien mit Contexten versehen wurden, was automatisch beim Anlegen einer Datei passiert (z.b. mit cp a b/) , gab es einige Contexte und andere nicht. Besonders das Home-Verzeichnis strotzt nur so vor Contexten.

Jede Fehlermeldung von SELinux wird dem User präsentiert. Dazu poppt auf dem Desktop eine Warnung auf. In dieser Warnung steht auch, was man dem System zu sagen hat, damit es diesen Zugriff zuläßt. Diese Ausnahmen muß es geben, damit Programme über verschiedene Contexte hinweg Daten austauschen können, z.b. Dateien per SSH ins Webverzeichnis spielen, per Samba Dateien kopieren usw.

Heute morgen hat das Chaos dann komplett zugeschlagen. Systemd konnte nicht mehr booten, da erneut SEL-rechte geändert wurden. Das führte zum komischsten Bootbug bisher. „failure to access /dev/initctl“, wo Systemd auf den „initctl“ Socket nicht mehr zugreifen konnte, also auf den eigentlichen Initprozess.

Wie man es behebt

In meinem Fall habe ich von der „alten“ Platte gebootet und systemd neu installiert, damit waren die komischen Bootprobleme behoben, aber die Gnomeshell startete trotzdem nicht. Was im Einzelnen nicht lief, lies sich nicht feststellen, damit man nicht mal mehr im Debugmodus ins System kam.

Abhilfe schaffte das Abschalten von SEL in /etc/selinux/config :

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing – SELinux security policy is enforced.
#     permissive – SELinux prints warnings instead of enforcing.
#     disabled – No SELinux policy is loaded.
SELINUX=permissive
#SELINUX=enforcing
# SELINUXTYPE= can take one of these two values:
#     targeted – Targeted processes are protected,
#     minimum – Modification of targeted policy. Only selected processes are protected.
#     mls – Multi Level Security protection.
SELINUXTYPE=targeted

Der Permissive Modus ist eine Art Debugmode, SEL meckert zwar über die Sicherheitsprobleme, verhindert Sie aber nicht. Damit kann das System wieder booten und man kann die SEL Einstellungen und Probleme reparieren.

Ursachenbeseitigung

Wie sich nach nun umfassender Analyse der SEL Konfigurationen gezeigt hat, war der Policyordner defekt. Dateien mit 0 Bytegröße waren die Regel ( weil die Platte zwischenzeitlich voll war ) .

Das Verzeichnis /etc/selinux/targeted stellt den Regelsatz dar, den SEL befolgen soll, so stehts in der config (siehe oben). Diesen Ordner löscht man und ersetzt ihn anschliessend mit einer alten Kopie. In meinem Fall, von der alten Festplatte. Die Verzeichnisstruktur hat sich nicht geändert, also paßt der Regelsatz, da er „Laufwerke“ nicht beachtet, sondern nur „Pfade“ enthält. Der Name des Bootdevices spielt also keine Rolle.

Nun gibt man noch ein :

# restorecond -R -v /*

Das dauert eine Weile, weil alle Files auf der Platte auf den im Regelsatz enthaltenen Wert zurück gesetzt werden. Mit einer SSD ist man in Minuten durch, mit einer SATA dauert es eine halbe Ewigkeit. Vor den vielen Ausgaben nicht erschrecken, es werden fast alle Dateien auf der Platte gerichtet!

Nun stellt man noch SEL in der /etc/selinux/config auf enforcing um :

# SELINUX=permissive
SELINUX=enforcing

Nun kann man rebooten und der Rechner läuft wieder.

Kleiner Tip an die Gemeinde: Kauft gleich eine TB große SSD, wenn Ihr Videos auf der Platte habt. Spart euch das Linken auf die alte Platte, damit spart Ihr euch eine Menge zusätzlichen Ärgers. Das Musik-  und Videos-Verzeichnis hat genauso Contexte wie alles andere und die müssen passen.

So habe ich das gemacht :

# ls -ladZ /home/marius/Videos
lrwxrwxrwx. marius marius unconfined_u:object_r:user_home_t:s0 /home/marius/Videos -> /sata_home/marius/Videos

]$ ls -ladZ /sata_home /sata_home/marius/
drwxr-xr-x. root root system_u:object_r:user_home_dir_t:s0 /sata_home/
drwx——. marius marius unconfined_u:object_r:user_home_dir_t:s0 /sata_home/marius/

In der /etc/fstab dann noch :

/dev/mapper/luks-53246778-9093-123d-235b-4f35522234211 /sata_home ext4 defaults,x-systemd.device-timeout=0 1 2

Eingetragen um die alte Home Partition als /sata_home zu mounten. Da die Passwörter für die Platten gleich sind ( beim Einrichten & Partitionieren der neuen Platte einfach so eintippen ) , wird diese Lukspartition auch automatisch beim Booten entschlüsselt und kann dann gemountet werden.