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.