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.

 

Docker – Genauso schlimm wie befürchtet

Jetzt ist es also endlich soweit, jemand hat man genauer hingeschaut und Dockerimages auf Schwachstellen untersucht. Das Ergebnis: Es ist genauso schlimm wie das von den Skeptikern erwartet wurde!

Kaum Sicherheitsupdates

Zunächst mal zur Quelle der Daten:

https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/

Da ist eine schöne Grafik über die Anzahl der gefundenen Schwachstellen per speziellem Dockercontainer. Das NODE dabei übelst abgeschnitten hat, wundert mich seit meinen Kontakten damit nicht im geringsten. Ohne darauf groß einzugehen, eine Repoumgebung, die zig Versionen der gleichen Erweiterung bereithält, anstatt nur die mit den wenigsten Löchern drin, kann man nicht ernsthaft als Basis für irgendwas benutzen.

Jetzt zur Analyse oben

Die Skeptiker, Altbackenden, Konservativen, die Im-Weg-Steher hatten es von Anfang an gesagt:

Wenn man Apps in Container packt und eine für diese App gangbare Umgebung dazu legt, dann wird man am Ende jede Menge Container mit Sicherheitslücken haben. Und genau das ist dabei rausgekommen. Weil sie keiner updated, obwohl das möglich ist, dümmpelt eine Sicherheitslücke neben der anderen rum.

Der sicherere Ansatz ist und bleibt, daß jemand das OS vorgibt und sich die Apps an die Umgebung anpassen müssen. Damit sind die gezwungen Updates zu machen und das dient dann der allgemeinen Sicherheit.

QED. Und es wurde gerade demonstriert!

Abzulehnen ist also alles, was eine App installiert, die mit eigener Umgebung kommt, sowas wie FlatPak, Docker und Snap.

 

Zwei Sicherheitslücken auf die wir lange warten mußten!

Darauf mußten wir lange, lange warten:

THN: 36 Jahre alte Sicherheitslücke in SCP entdeckt!

Wie die Hacker News berichten, gibt es in SCP eine 36 Jahre alte Lücke, die es einem böswilligen Server erlaubt, beliebige Files beim Benutzer zu überschreiben.Da fast alle Implementierung vom alten Originalcode abstammen, sind sehr viele Anwendungen davon betroffen. Es können z.B. verstecke Bash-Files im Home (eines Unix/Linux/Macusers ) erzeugt werden, die als ANSI Codes übermittelt werden. Möglich wird die mangels guter Prüfung des erhaltenen Contents durch SCP. Da scp üblicherweise in der Shell eingesetzt wird, könnte das praktische ausnutzen der Schwachstelle in der Regel schwierig werden, da man sich nur zu bekannten Server mit SCP verbindet. Jemanden da per Spam hin zu bekommen, könnte schwer fallen.

Auch lange warten mußten wir auf diese Meldung, die nicht minder prikär ist, vielleicht sogar noch schlimmer:

heise.de : Forscher brechen aus Docker-Container aus

Ich persönlich warte ja schon länger auf diese Meldung, aber verwundern wird sie wohl keinen. Die Hauptkritik an Container ist ja, daß die darin enthaltene Software nicht aktuell gehalten sein wird, weil sonst könnte der Entwickler die Anwendung ja auch prima auf einem normalen System starten. Natürlich gibt es noch andere Gründe für einen Container: Transferierbarkeit, Skalierbarkeit  usw. aber uns interessiert die Sicherheit natürlich mehr. Wenn ich jetzt Software von Anno Schnee in einem Container habe, der nicht aktualisiert wird, weil „wieso, geht doch!“, das übliche Argument der Neulandmanager halt, dann habe ich jetzt endlich den Exploit, der mir bisher fehlte, um aus dem Schrott auszubrechen. VMs sind übrigens nicht anders, nur einer VM kann ich ( ICH!! ) sagen, daß das System dadrin aktualisiert werden soll. Bei „Docker“ ist das ein Heckmeck sondergleichen, wenn die Funktion nicht vorgesehen ist.

Die „Play with Docker“ Containerumgebung wird nicht die Einzige sein, die mit „wieso, kann doch keiner ausbrechen“ als Argument, die Anwendung mit erhöhten Rechten laufen läßt. Es wird also spannend werden, wenn man Docker einsetzt. Eine Lücke mehr, die man stopfen muß. Das sollte man sich vor Augen halten.