Category Archives: Leap 42.3

Update zu Opensuse 42.3 – kleine Probleme mit nvidia und libvirt/kvm

Posted on by

Das aktuelle Drama um Meltdown und Spectre verlangt auch von Linux-Usern starke Nerven. Bei Opensuse steht zudem das Auslaufen des Support-Zeitraums für Opensuse Leap 42.2 an. Es lohnt sich also, hier auch noch ein Upgrade betroffener Systeme auf Opensuse Leap 42.3 vorzunehmen. In der Reihenfolge

  1. Anwendung aktueller Kernel-Patches (man suche z.B. unter YaST > Software Management” mit dem Begriff “kernel” nach entsprechenden RPM-Paketen und deren Updates) sowie von Intel- bzw. AMD-Microcode-Patches (Pakete “ucode-intel”, “ucode-intel-blob” bzw. “ucode-amd”) unter Opensuse Leap 42.2.
  2. Bei Einsatz von qemu, kvm, libvirt: Update entsprechender Pakete unter Leap 42.2.
  3. Upgrade auf Opensuse Leap 42.3 (z.B. gem. der Anleitung unter https://kamarada.github.io/en/2017/08/03/how-to-upgrade-from-opensuse-leap-422-to-423/)
  4. Soweit dann noch nötig: Anwendung aktueller Kernel-Patches, von Intel- bzw. AMD-Microcode-Patches und Updates von qemu/kvm/libvirt-Paketen unter Leap 42.3
  5. [Für Mutige (und Sicherheitsbewusste): Upgrade auf ein aktuelles Kernel-Paket zur Version 4.14 aus dem “kernel”-Repository “http://download.opensuse.org/repositories/Kernel:/stable/standard/”.]

Das klappt eigentlich ganz gut. Bei zwei Systemen bin ich dabei im Zuge des Standard-Upgrades aber auf zwei kleinere Problemchen mit “kvm/qemu” und dem proprietären “Nvidia”-Treiber gestoßen.

Nvidia-Problem => Deinstallation des Pakets “drm-kmp-default”

Im Zuge der Installation des proprietären Nvidia-Treibers (z.B. über das Installations-File “NVIDIA-Linux-x86_64-384.98.run”), den man sich von der Nvidia-Web-Site laden kann, klappt zwar die Kompilation des Treibers, nicht aber das Laden des Moduls “nvidia-drm.ko”. Es kommt eine entsprechende Meldung zum Fehlschlag der Nvidia-Installation. Ursache ist ein Paket “drm-kmp-default”, das aus mir nicht nachvollziehbaren Gründen installiert wird, aber in seiner Version nicht zum aktualisierten Default-Kernel (z.Z. 4.4.104-39.1) des Leap 42.3-Systems passt. Hier hilft es, das Paket “drm-kmp-default” zu deinstallieren. Das “drm”-Modul wird dennoch geladen und vom Modul “drm-nvidia” auch korrekt verwendet.

qemu/kvm-Problem: Korrekten Eintrag zu “namespaces” in der Datei qemu.conf vornehmen

Nach dem Upgrade auf Leap 42.3 und Aktualisierung aller Virtualisierungspakete ließen sich leider keine KVM-Gastsysteme mehr starten. Ich erhielt ganz unabhängig von der Art des Gastes und dessen Betriebssystem eine Meldung der Art:

Error starting domain: internal error: child reported: Kernel does not provide mount namespace: Permission denied

Ursache ist ein fehlender Eintrag

#namespaces = [ “mount” ]
namespaces = []

(bzw. ein unwirksamer Default-Eintrag (namespaces = [ “mount” ])) in der Datei “/etc/libvirt/qemu.conf”.
Ich tippe darauf, dass dieses Problem durch Rückportierungen bestimmter neuer Kernel-Features auf die relativ veraltete 4.4-Version von Leap 42.3 verursacht wurde. Im Standard-4.4-Kernel brauchte man den Eintrag in der vorliegenden Form nämlich nicht. Auf die Lösung dieses Problems bin ich nicht selbst gekommen; s. zu diesem Thema die unten angegebenen Links.

Viel Spaß weiterhin mit Opensuse – trotz des aktuellen Security Super-GAUs. Das beste Gegenmittel gegen Spectre ist – neben laufenden System-Updates – maximale Vorsicht beim Öffnen jeglicher externer Quellen, das Verifizieren von Update-Quellen für System- und Anwendungsdateien und das Verifizieren von Web-Sites im Internet über https-Verbindungen, das Kontrollieren der Hash-Summen für alle Updates sowie der Einsatz von “Noscript
“-Plugins in euren Browsern. Soweit ich das verstehe, erfordert ein Ausnutzen der Spectre-Schwachstelle in den aktuellen Prozessoren das Ausführen malignen Codes. Ein Einfangen von Schadcode muss man vermeiden – diese Binsenwahrheit gilt und erfordert nunmehr weiter erhöhte Wachsamkeit – im besonderen beim Browsen im Internet.

Vielleicht denken einige Unternehmen und Webseiten-Programmierer nun auch wieder ein wenig mehr darüber nach, ob und wann Javascript für den Betrieb einer öffentlichen Web-Seite überhaupt erforderlich ist. Auf vielen Seiten erfolgt der Einsatz oftmals weniger aus funktionalen Gründen als vielmehr deshalb, damit das Nutzerverhalten aus kommerziellen Gründen getrackt werden kann …..

Links

https://forums.opensuse.org/showthread.php/527697-Can-t-load-nvidia-drm-ko-after-update
https://forums.opensuse.org/showthread.php/527394-KVM-guest-will-not-start-with-latest-version-of-kernel
https://www.redhat.com/archives/libvirt-users/2017-March/msg00033.html
https://www.redhat.com/archives/libvirt-users/2017-March/msg00035.html

firejail firecfg – Problem mit dem KDE-Login unter Opensuse Leap 42.3 – .ssh-Dateien und ssh-agent als Ursache

Posted on by

Experimentiert man unbedarft mir neuen Dingen, muss man sich nicht wundern, wenn man sich Probleme schafft. Jetzt passierte mir das mit firejail.

Ich muss manchmal Skype benutzen. Zu meinem großen Ärger, da jede Art von Closed Source UDP-Streaming Applikation ein prinzipielles Sicherheitsrisiko darstellt. In einen UDP-Datenstrom können immer Pakete integriert werden, die ganz anderen Zwecken dienen als der Übertragung der eigentlichen Audio- und Videodaten. Und wenn man dann den Code nicht kennt … Neben dem Aufsetzen eines speziell konfigurierten Containers ist die Nutzung von Firejail eine Gegenmaßnahme, solchen Applikationen das Vordringen ins System zu erschweren.

Opensuse 42.3 bietet im Repository “Virtualization”
ein RPM-Paket firejail 0.9.5 zum Download an. Das habe ich installiert. nach der Installation war zunächst auch ein kein Problem feststellbar.

Aber dann habe ich ein wenig in der Dokumentation gestöbert. Auf der Seite https://firejail.wordpress.com/documentation-2/ findet man dann unter dem Titel “I’ve just installed Firejail, now what?!” Hinweise zu bestimmten Kommandos, um “pulseaudio” [PA] zu korrigieren (wundert mich nicht) und auch das Kommando “firecfg” auszuführen:

$ firecfg –fix-sound
$ sudo firecfg

Beides hat u.U. aber unangenehme Nebenwirkungen:

1) Pulseaudio zunächst nicht mehr deaktivierbar
Das erste Kommando korrigiert “pulseaudio”-Konfigurationsdateien zwar; es sorgt aber auch dafür, dass man unter Opensuse PA nicht mehr einfach über YaST und die dortige Audio-Konfiguraiton abschalten kann. Bekanntermaßen verwende ich PA nur, wenn nicht umgehbar. So erzwangen etwa frühere Skype Versionen für Linux ( u.a. die Version 4.3) die Nutzung von PA. Das ist beim aktuellen “skypeforlinux” (Beta) nicht der Fall; das kooperiert auch direkt mit Alsa.

Das ist auf meinem Laptop auch gut so, denn PA erzeugt dort ein dauerhaftes unangenehmes Hintergrundsgeräusch (niederfrequenter Pfeifton; keine Rückkopplung) auf meinem eingebauten Mikrophon (unabhängig von Skype). Das ließ sich auch durch Ändern der Empfindlichkeit und der Regelung von Verstärkungsfaktoren unter dem PA-eigenen “pavucontrol” nie beseitigen. Ein solches Geräusch tritt bei mir im reinen Alsa-Betrieb dagegen nicht auf.

Beseitigt habe ich die Aktivierung von PA dann durch Umbenennen/Verschieben der Datei “~/.pulseaudio” und anschließende erneute Deaktivierung von PA über YaST.

2) Kein KDE-Login und kein X11-Start mehr für bestimmte Accounts möglich
Schlimmer ist dagegen eine Auswirkung des zweiten Kommandos: Es erzeugt eine Liste von Links unter dem Verzeichnis von “/usr/local/bin“, die alle auf firejail verweisen. Normalerweise führt das dazu, dass viele Programme/Anwendungen über firejail gestartet und geschützt werden. Leider ist die Liste der Profile für Anwendungen aber keineswegs vollständig. Wird für eine Anwendung nichts gefunden, dann kommt wohl ein “default.profile” zum Einsatz. Letzteres verhindert aber den Zugriff u.a. auf ~/.ssh und ~/.gnupg-Verzeichnisse und dortige Dateien. Das wird aber unter Umständen unter Opensuse zu einem Megaproblem beim Start von KDE aus SDDM oder KDM heraus:

Ich konnte mich unter bestimmten Accounts nach dem Absetzen von firecfg nicht mehr von KDM oder SDDM aus in KDE (Plasma 5) einloggen. X11 wurde nicht gestartet; man landet nach ca. 1 Sekunde wieder auf dem KDM oder SDDM-Login-Schirm.

Die Fehlermeldungen hierzu waren unzureichend. Nach mühsamen Experimenten mit Konfigurationsdateien stieß ich schließlich darauf, dass allein die Existenz eines “~/.ssh“-Verzeichnisses zu Fehlern beim KDE-Start
führte. Entfernte ich das Verzeichnis komplett, ließen sich KDE und X11 wieder regulär starten.

Wer oder was will im Start “~/.ssh” auslesen? Mir fiel dazu zunächst nichts ein. Dann stieß ich auf ssh-agent. Und tatsächlich ergab sich unter Opensuse Leap 42.3 folgendes Bild: 

mytux:~ # ps aux | grep ssh
root      1574  0.0  0.0  53492  5816 ?        Ss   13:30   0:00 /usr/sbin/
sshd -D
myself       4065  0.0  0.0  20136  1868 ?        S    13:30   0:00 /usr/bin/dbus-launch --sh-syntax --exit-with-session /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/
agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc
myself       4067  0.0  0.0  13312   332 ?        Ss   13:30   0:00 /usr/bin/ssh-agent /usr/bin/gpg-agent --sh --daemon --keep-display --write-env-file /home/myself/.gnupg/agent.info-mytux.mydomain.de:0 /etc/X11/xinit/xinitrc

Offenbar klappt diese Art des X-Starts nicht mit dem komplett gefüllten “/usr/local/bin” (genauer mit den dortigen Links). Ich sehe die Ursache – wie gesagt – im “default.profile”.

Die Link-Orgie unter “/usr/local/bin” beseitigt man übrigens mit

firecfg –clean

Danach klappt der Login in das X11/KDE-Gespann alles wieder. Meine Strategie ist im Moment, die Profile für verschiedene Anwendungen zu checken und “/usr/local/bin” langsam und systematisch mit Links zu füllen, die nur bestimmte Anwendungen betreffen.

Bei manchen alten Accounts habe ich zudem festgestellt, dass die Anlage der Links unter /usr/local/bin” auch dazu führt, dass jeglicher Netzwerkzugriff unterbunden ist. Hier bin ich noch an der Ursachenforschung.

Merke: Nicht gleich alles machen, was Manuals vorschlagen, wenn man von einer neuen Anwendung noch zu wenig versteht.