Warnung: Libreswan kann Ihren Bootprozess stören – F29

Argss! Ja Argss! Da upgraded man 7800 Schritte lang seinen Desktop-PC auf ein Fedora 29, das auf den Servern ohne Probleme eingespielt werden konnte, auf dem Tablet und Laptop läuft, wo es exakt so per DNF eingespielt wurde, nur um dann festzustellen, daß das System nicht mehr bootet! Warum? Weil das Libreswan Paket wohl „defekt“ ist. ARGS!

Da tust Du alles um sicher zu sein und dann das!

Von dem Gedanken, das mein Desktop schnell mal eben auf ein neues Fedora hochgezogen werden kann, habe ich mich ja schon vor Jahren verabschiedet. Seit 0AD da drauf ist, dauert allein das  Herunterladen der Paket 25 Minuten und mehr, und 7800 Updateschritte brauchen auch mit SSD Support so um die 2 Stunden. Also schnappt man sich das Tablet, während der Desktop sein Upgrade fährt und macht was sinnvolles.. Kernel Updates einspielen z.B. 😉

Irgendwann war auch der Desktop durch und das obligatorische „reboot“ war fällig. Getan, gewartet, Festplattenpasswort eingetippt und …. tod.

Weil sich das schwer beschreiben läßt, hier der Bootlogauszug dazu:

Jun 14 19:13:06 meinpc systemd[1]: Started Restorecon maintaining path file context.
Jun 14 19:13:06 meinpc systemd[1]: Started LSB: Init script for live image..
Jun 14 19:13:06 meinpc systemd[1]: avahi-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-logind.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> Caught signal, shutting down...
Jun 14 19:13:06 meinpc ModemManager[1625]: <info> ModemManager is shut down
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: systemd-machined.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: NetworkManager.service: Start operation timed out. Terminating.
Jun 14 19:13:06 meinpc systemd[1]: rtkit-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start RealtimeKit Scheduling Policy Service.
Jun 14 19:13:06 meinpc systemd[1]: accounts-daemon.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Accounts Service.
Jun 14 19:13:06 meinpc systemd[1]: ModemManager.service: Failed with result 'timeout'.
Jun 14 19:13:06 meinpc systemd[1]: Failed to start Modem Manager.
Jun 14 19:13:06 meinpc systemd[1]: Started NTP client/server.
Jun 14 19:13:06 meinpc systemd[1]: Started Hardware Monitoring Sensors.
Jun 14 19:13:06 meinpc systemd[1]: Starting SYSV: Late init script for live image....
Jun 14 19:13:06 meinpc systemd[1]: Starting ABRT Automated Bug Reporting Tool...
Jun 14 19:14:37 meinpc systemd[1]: Failed to get initial list of names: Connection timed out
Jun 14 19:14:37 meinpc systemd[1]: systemd-logind.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd[1]: Failed to start Login Service.
Jun 14 19:14:37 meinpc systemd[1]: systemd-machined.service: Failed with result 'timeout'.
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Due to PID 1 having crashed coredump collection will now be turned off.
Jun 14 19:14:37 meinpc systemd[1]: Caught <ABRT>, dumped core as pid 1748.
Jun 14 19:14:37 meinpc systemd[1]: Freezing execution.
Jun 14 19:14:37 meinpc kernel: printk: systemd: 61 output lines suppressed due to ratelimiting
Jun 14 19:14:37 meinpc systemd-coredump[1749]: Process 1748 (systemd) of user 0 dumped core.

Stack trace of thread 1748:
#0 0x00007fa4b3f9087b kill (libc.so.6)
#1 0x00005583475eeeda n/a (systemd)
#2 0x00007fa4b4133070 __restore_rt (libpthread.so.0)
#3 0x00007fa4b3f9057f raise (libc.so.6)
#4 0x00007fa4b3f7a895 abort (libc.so.6)
#5 0x00007fa4b3fd39c7 __libc_message (libc.so.6)
#6 0x00007fa4b3fda2cc malloc_printerr (libc.so.6)
#7 0x00007fa4b3fdbafc _int_free (libc.so.6)
#8 0x00007fa4b4066ac7 __vasprintf_chk (libc.so.6)
#9 0x00007fa4b43d0630 log_format_iovec (libsystemd-shared-239.so)
#10 0x00007fa4b43d0b09 log_struct_internal (libsystemd-shared-239.so)
#11 0x0000558347610a0f n/a (systemd)
#12 0x00005583476132cb n/a (systemd)
#13 0x000055834766368e n/a (systemd)
#14 0x000055834763fb3b n/a (systemd)
#15 0x00005583476436aa n/a (systemd)
#16 0x0000558347626eed n/a (systemd)
#17 0x00007fa4b4455f02 n/a (libsystemd-shared-239.so)
#18 0x00007fa4b4457da5 sd_event_dispatch (libsystemd-shared-239.so)
#19 0x00007fa4b4457f30 sd_event_run (libsystemd-shared-239.so)
#20 0x00005583476300f6 n/a (systemd)
#21 0x00005583475ea78b n/a (systemd)
#22 0x00007fa4b3f7c413 __libc_start_main (libc.so.6)
#23 0x00005583475ec41e n/a (systemd)

So, jetzt sitzt der User da und hat kein System mit dem er was machen könnte, weiß nicht, was da nicht ging und hat natürlich auch kein Backup gemacht, von dem der User jetzt eh nicht wüßte, wie er es in dem Zustand zurückspielen sollte 🙂

Was also machen ?

  1.  Resetknopf drücken, wenn alle Festplattenindikatoren aufgehört haben zu blinken.
  2.  Kernelbootmenü abwarten
  3.  „e“ drücken, und die Zeile „linux ……“ um “ 1 init=/bin/bash“ am Ende erweitern, ggf. noch „splash quite rghb“ entfernen,  damit man bei nächsten boot was sieht.
  4.  STRG+x drücken
  5.  Jede Menge Kernel Meldungen laufen über den Bildschirm, wenn die aufhören, RETURN drücken.
  6.  /etc/init.d/network start
  7.  mount / -o remount,rw
  8.  dnf update

Jetzt wird uns dnf erzählen, daß crypto-policies wegen libreswan-libs nicht installiert werden kann. Das löst man so auf:

dnf erase libreswan*

es fliegen runter :

NetworkManager-libreswan-gnome-1.2.10-1.fc29.x86_64
NetworkManager-libreswan-1.2.10-1.fc29.x86_64
libreswan-3.27-1.fc29.x86_64

und jetzt kann man mit dnf update auch das letzte Paket für einen aktuelles Fedora installieren und oh Wunder, der Rechner booted wieder. Bugreport filed!

Hinweis: Dieses Problem wird natürlich nur ausgelöst, wenn man libreswan auch mal irgendwann installiert hatte 😉

Bitte lesen Sie auch das Update dazu : Update: Fedora 29 bootet nicht nach Upgrade

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.