Jitsi-Meet-Docker failed mit Cgroups2

Ich habe es bei FlatPak gesagt, ich habe es bei Snap gesagt, und ich sags bei Docker: Container sind Scheisse!

Jitsi-Meet-Docker failed mit Cgroups2

Die Jitsi-Meet-Docker Instanz hatte ja bereits am Anfang leichte Probleme: Das erste Update ging gründlich schief, weil es mit der selbst erstellten Laufzeitconfig nicht mehr zurecht kam. Ein komplettes „rm -rf“ war die Folge. Zum Glück lies es sich dann recht einfach reinstallieren. Die Folge war allerdings, daß es nachts abstürzte und per Cron restartet werden mußte.

Der Wechsel von Fedora 30 ( CGroups V1 ) auf Fedora 31 ( CGroups V2 ) hat dem Dockerimage dann den Rest gegeben. zwei der vier Server starten halt nicht mehr.

# ./update.sh
Removing docker-jitsi-meet_web_1 … done
Removing docker-jitsi-meet_prosody_1 … done
Removing network docker-jitsi-meet_meet.jitsi
Bereits aktuell.
Creating network „docker-jitsi-meet_meet.jitsi“ with the default driver
Creating docker-jitsi-meet_web_1 …
Creating docker-jitsi-meet_prosody_1 … error
Creating docker-jitsi-meet_web_1 … error
ERROR: for docker-jitsi-meet_prosody_1 Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for docker-jitsi-meet_web_1 Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for prosody Cannot start service prosody: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown

ERROR: for web Cannot start service web: OCI runtime create failed: this version of runc doesn’t work on cgroups v2: unknown
ERROR: Encountered errors while bringing up the project.

Der resultierende Bugreport im GitHub wird seit dem ignoriert.

Die mangelnden Updates am den Basisimages, bzw. die Vorherschaft von Debianimages in den Containern führt wegen dem lahmen Updatezyklus von Debian und dem mangelnden Druck zu Updates durch die Containerhersteller, dann unweigerlich ins Nirvana.

Fazit: Man kann eben doch nicht einfach Container von A nach B und zwischen Osen verschieben wie man will.

Schweres Defizit im Dockersystem

Wie ich gerade feststellen muß, ist es nicht möglich in einen nicht laufenden Container zuwechseln. Das macht das Debuggen natürlich extrem toll, wenn man nicht mal die Logfiles auslesen kann!

# docker-compose ps
Name Command State Ports
——————————————————–
docker-jitsi-meet_prosody_1 /init Exit 128
docker-jitsi-meet_web_1 /init Exit 128
# docker-compose logs web
Attaching to docker-jitsi-meet_web_1

Ich hab jetzt keine große Lust das Filesystem umständlich zu mounten und da so reinzusehen 🙁

So lustige Sachen wie : „docker export CONTAINER|tar -t“ gehen auch nicht.

Meine Meinung: wer Docker produktiv einsetzt, sollte aus dem Zirkel der ITler exkommuniziert werden.

UPDATE – LÖSUNG

Es gibt noch Leute, die da durchblicken, „{hier ihre Gottheit einsetzen} sei Dank“!

Seit ner Weile gibt es im Kernel die neuen Control Groups 2. Fedora hat mit 31 auf cgroups2 umgestellt, aber Docker kann das nicht, weswegen die Container sauber wegcrashen.

Die Lösung des Problems ist zwar einfach, aber sollte echt nicht nötig sein:

# cat /etc/default/grub
…
GRUB_CMDLINE_LINUX=“rhgb quiet audit=0 systemd.unified_cgroup_hierarchy=0“
…

Dann die grub Config neu erzeugen, oder einfach die /boot/grub/grub.cfg (Legacy)  kurz anpassen und rebooten. (Mehr Hinweise dazu in: Wenn sich Grub und Grubby uneins sind )

Danach starten die Container wieder, außer der Container hat beim Update was anderes verbrochen, was Jitsi tatsächlich hinbekommen hat:

Die JICOFO Komponente prüft doch jetzt tatsächlich, ob das Passwort nicht das Defaultpasswort ist. Das finde ich ja prinzipielle richtig gut, wäre da nicht der Umstand, daß das gar nicht eingeschaltet ist 😀

2. UPDATE:

Kleines Sicherheitsloch bei Jitsi-Meet:

Die Passwörter für die Instanzen werden in ENV variablen übergeben und nie gelöscht. Sobald jemand, wie auch immer, Zugang zur Prozessenviron bekommt, kann man das auslesen. Da potentiell noch andere priviligierte Prozesse im System laufen, ist generell eine dumme Idee.

Infos aus ENV variablen, die man nicht mehr braucht, gehören getilgt, in dem die Variable entfernt wird. Passwörter gehören übrigens GAR NICHT in ENV Variablen.

 

ClamAV < 0.102.3 mit DOS Schwachstelle

Derzeit ist kein Update für Fedora in Sicht, daher ggf. den Mailserver so umkonfigurieren, daß er keine PDF Files scannt.

Update 14.5.: die Updates für Fedora stehen bereit. Es wird aber noch etwas dauern, bis die in den Stables sind. Im Koji kann man sich die Builds für FC30-FC33 bereits ziehen. Exemplarisch für FC30, wäre das hier:

https://koji.fedoraproject.org/koji/search?terms=clamav-0.102.3-1.fc30&type=build&match=glob

Für FC30 haben wir den Build ausprobiert. er funktioniert. kann also bedenkenlos eingespielt werden.

Eilmeldung: ClamAV mit DOS Schwachstelle

Leider ist derzeit keine Fedora Version in der Mache für diese Schwachstelle:

Versionen: ClamAV < 0.102.3

In ClamAV bestehen mehrere Schwachstellen bei der Verarbeitung von bösartigen ARJ Archiven und PDF Dateien. Ein Angreifer kann dadurch den Virenscanner zum Absturz bringen. Zur Ausnutzung genügt es, eine entsprechende ARJ oder PDF Datei mit ClamAV zu scannen.

Hier die Meldung komplett:

ClamAV 0.102.3 is a bug patch release to address the following issues:

  • – CVE-2020-3327: Fixed a vulnerability in the ARJ archive-parsing module in ClamAV 0.102.2 that could cause a denial-of-service condition. Improper bounds checking of an unsigned variable results in an out-of-bounds read which causes a crash. Special thanks to Daehui Chang and Fady Othman for helping identify the ARJ parsing vulnerability.
  • – CVE-2020-3341: Fixed a vulnerability in the PDF-parsing module in ClamAV 0.101 – 0.102.2 that could cause a denial-of-service condition. Improper size checking of a buffer used to initialize AES decryption routines results in an out-of-bounds read, which may cause a crash. OSS-Fuzz discovered this vulnerability.
  • – Fixed „Attempt to allocate 0 bytes“ error when parsing some PDF documents.
  • – Fixed a couple of minor memory leaks.
  • – Updated libclamunrar to UnRAR 5.9.2.

Das hat wohl einige kalt erwischt, als das Bürger-CERT dazu heute eine Warnung rausgehauen hat. Ich werde Euch Informieren, wenn sich das ändert.

Quellen:https://blog.clamav.net/2020/05/clamav-01023-security-patch-released.html

 

Installer loggen LUKS Passwort mit

Moin, Moin,

na auch schon die Platte aufgeräumt und die alten Installerlogfiles gelöscht?

Installer loggen LUKS Passwort mit

Ubuntu ist da mal was „passiert“ was wohl auch anderen Installern in der Gemeinde passiert sein könnte:

https://bugs.launchpad.net/ubuntu/+source/curtin/+bug/1878115

Der Bugreporter hat festgestellt, daß sein Ubuntuinstaller sein LUKS Festplattenpasswort einfach mal mit ins Logfile geschrieben hat. Diese Datei liegt zwar in der verschlüsselten Platte selbst, könnte aber durch einen „Besucher“ geleakt werden oder in Backups gefunden werden, die nicht auch in der Krypto vergraben wurden.

Da hat der Bugreporter wohl recht, auch wenn ich das Risiko als äußerst gering ansehe. Die Logfiles landen z.B. bei Anaconda üblicherweise in /root/, wenn da ein Besucher dran kommt, hat man ganz andere Probleme als das es da drinsteht. Insofern: gut gebrüllt, Kätzchen 😀