Podman Update verhindert Start alter Container

Ein Update von Podman verhindert das Starten von alten Containern. Das betrifft auch Toolbox.

Podman Update verhindert Start alter Container

Die Fedora Toolbox benutzt Podman um Container zu erstellen und zu starten. Das geht aber mit Podman 4.6.x nicht mehr für jeden Container, da dazu nicht mehr die nötigen Limits erlaubt werden, die noch mit 4.5.x dem Container zugewiesen wurden. Eine Datenmigration ist das einzige Mittel, alte Container wieder zu starten.

Die meist angesprochene Endlösung war das Löschen und Neuerstellen der betroffenen Container, was aber mit einem Datenverlust einhergehen würden, so man den Daten in dem Container drin hat. Einige Benutzer merkten an, daß Toolbox gar nicht für dauerhafte Container ausgelegt wäre, und man sich nicht wundern müßte, wenn Daten verloren gingen, da gegen den „Sinn“ von Toolbox gehandelt wurde.

Das ist natürlich per se kein Argument, weil Toolbox ja nur das Kontrollwerkzeug ist. Was man mit dem Container dann anstellt, ist ja jedem selbst überlassen 😉

Aber ist das Überhaupt ein Problem? Wir fragen Prof. Dr. Besser-Weiß von der Uni Kassel-Schwarzensee.

Das Interview

„Herr Professor Besser-Weiß, ist das Update von Podman überhaupt ein Problem?“
„Nein.“
„Herr Professor, wir danken für das Gespräch.“

Die Migration

Im Podman Issue[0] gibt es dafür folgende Migrationslösung:

$ podman export $CONTAINER_NAME -o output.tar
$ podman import output.tar $NEW_IMAGE_NAME
$ podman container rm $CONTAINER_NAME
$ toolbox create --image localhost/$NEW_IMAGE_NAME -i $CONTAINER_NAME

Danach kann der Container wieder gestartet werden.

Wer tatsächlich keine Daten in dem Container hat, was bei meinen Experimenten mit Cheese auf dem Surface Tablet z.B. der Fall war, weil Cheese seine  Daten im Home speichert, hat ohnehin kaum Hemmung den Container zu löschen und einfach neu anzulegen.

Da Fedora das Podman Update bereits ins Stable getan hat, solltet Ihr Euch bei Zeiten, also jetzt, darum kümmern, bevor Ihr das Programm im Container nochmal braucht.

[0] Quelle: https://github.com/containers/podman/issues/19634

Red Hat Politikänderungen wirken auch auf Fedora nach

Red Hat hatte ja einige Änderungen am Engagement für Desktopelemente in Aussicht gestellt, die jetzt langsam durchschlagen.

Red Hat Politikänderungen wirken auch auf Fedora nach

Bastien Nocera schreibt in seinem Blog, daß er von Red Hat in ein anderes Team versetzt wurde und die ohnehin schon geringe Arbeit an „fprint, fprintd, gnome, gvfs, iio-sensor-proxy, kernel, libfprint, low-memory-monitor, power-profiles-daemon, rhythmbox, sound-juicer, switcheroo-control, thumbnailer, totem“ einstellen mußte. Das führte zum Verwaisung der Pakete bei Fedora.

Langzeit Maintainer Michael Catanzaro, der auch bei Red Hat angestellt ist, schrieb dazu am Montag auf der Fedora Dev ML:

„Red Hat has instructed us to stop work on several core desktop components. All of these components need new maintainers now. The switcheroo-control repo has now been archived, and a future new maintainer will need to recreate the repo in a new location. It’s certainly not good news. :(„

Cinnamon & Nvidia Maintainer Leigh Scott nahm das zum Anlass um wenigsten einige der Pakete von der LinuxMint Gruppe übernehmen zu lassen. Dutzende andere Pakete warten aber noch auf einen neuen Maintainer.

Der ‚Umorientierung‘ bei Red Hat, der mutmaßlich von IBM inszeniert wurde, geht also weiter und wird sicherlich noch spürbare Ausmaße annehmen, weil Red Hats Engagement weitest gehend im  Stillen abgelaufen ist. Das wird sich sicherlich jetzt ändern.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Vor einigen Tagen hatte ich ja was zum Kernel Bug geschrieben, nämlich, daß ich mir mehr Sorgen mache, daß eins der Desktopprogramme geknackt wird. Jetzt ist es bei Ghostscript soweit.

Der Ghostscript Exploit, der in andere Anwendungen eskaliert

Ghostscript < 10.1.02  hat eine Schwachstelle, die das Ausführen von Code erlaubt. Das an sich ist schon schlimm, wenn man dann erfährt, daß das bei den Maintainer untergegangen ist 🙁

Schlimmer ist aber, daß die Lücke in andere Anwendungen wie InkScape, LibreOffice und Gimp eskaliert, dort also auch funktioniert. Möglich macht dies das Äquivalent der größten Container-Sorge überhaupt: Diese Anwendungen halten sich eine selbst gepatchte Version von Ghostscript in der Codebasis und naja, in der ist der Bug auch drin.

Das ist vergleichbar mit einer Sammlung von Docker Containern,Snaps & Flatpaks, welche alle die gleiche ausnutzbare libPNG drin haben und jetzt alle geupdated werden müssen, wo ja eigentlich nur eine Komponente das Update wirklich bräuchte: Ghostscript. Was zeigt das: Dumme Entscheidungen brauchen kein Containermodell 😉

Anstatt einer Komponente, müssen jetzt ein Haufen unübersehbarer Anwendungen aktualisiert werden, wozu man erstmal rausfinden muß, wo das überall drin ist. Das muß man erst mal schaffen. Log4J lässt so derbe grüßen, daß heute wohl Murmeltiertag ist.

Da zu allem Überfluss ein POC-Exploit bekannt ist, werden echte Exploits nicht lange auf sich warten lassen.

Die Situation auf Debian ist besser als die von Fedora, weil Debian immerhin das erste GS Update ausgeschickt hat, bei Fedora aber nichts am Horizont ist. Dagegen habe ich mal was gemailt…

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-36664

https://www.kroll.com/en/insights/publications/cyber/ghostscript-cve-2023-36664-remote-code-execution-vulnerability