Flatpak und Snap sind nicht die Lösung des Problems, sondern machen es noch schlimmer

Im Moment wird heftig darüber diskutiert, ob der Support von Flatpak in Fedora 27 weiter ausgebaut werden soll oder nicht.

Ich persönlich halte Flatpak und Snap für den völlig falschen Ansatz, das Problem mit der Bereitstellung von Software für verschiedene Distributionen zu lösen. Beide haben in meinen Augen das große Problem, das im Grunde jedes Snap-/Flatpak-Paket seine eigenen Versionen von benötigten Shared-Objects mitbringt und man damit irgendwann so etwas ähnliches, wie die DLL-Hölle von Windows hat: zig verschiedene Versionen eines Shared-Object von denen die meisten im schlimmsten Fall auch noch verwundbar für Angriffe sind.

Zumal die meisten technisch unbedarften Anwender wahrscheinlich davon ausgehen werden, das der Paketmanager des Systems (z.B. dnf oder PackageKit) auch die Shared-Objects der Flatpak-Pakete aktualisiert, was aber eben genau nicht der Fall ist. Stattdessen müssen sich die Nutzer darauf verlassen, das die Anbieter der von ihnen verwendeten Flatpaks/Snaps verwundbare Versionen der von ihren Apps verwendeten Shared-Object zeitnah aktualisieren – eine Wette, die ich persönlich nicht eingehen möchte. Das funktioniert ja schon bei Windows Anwendungen eher bescheiden, warum sollte es dann diesmal besser klappen?

Nein, Flatpak und Snap sind in meinen Augen das, was man sprichwörtlich „den Teufel mit dem Beelzebub austreiben“ nennt: ein Problem lösen und dabei ein anderes Problem schaffen. Man macht es einfacher, Anwendungen für verschiedene Distributionen bereit zu stellen, öffnet damit aber ohne Not zusätzliche Angriffsvektoren, indem man dem Paketmanager die Kontrolle über einen Teil der installierten Software entreißt und die Anwender damit zwingt darauf zu vertrauen, das Dritte – von denen man im Grunde nicht weiß, wie vertrauenswürdig sie sind – ihre Hausaufgaben machen!

IMHO ist der Kommentar von Fedora-Blog.de.
IMHO = In My Humble Opinion (Meiner bescheidenen Meinung nach).

Fedora hat jetzt ein Security Team

Eric H. Christensen hat heute offiziell das neu gegründete Fedora Security Team auf der Devel-Announce-Liste vorgestellt.

Hauptaufgabe des Teams soll es sein, Paketbetreuer bei der Behebung von Sicherheitsproblemen zu helfen. So kann das Team z.B. dem Upstream eines Paketes dabei helfen, einen Patch für das Problem zu entwickeln oder ein neues Release, welches das Problem beseitigt, bereitzustellen. Anschließend soll das Team dann mit dem Paketbetreuer zusammen daran arbeiten, möglichst schnell aktualisierte Pakete bereitzustellen.

Nach Aussage von Christensen verfügt das Security Team bereits über 20 Mitglieder. Mit der heutigen Ankündigung stehen interessierten jedoch die Türen für die Mitarbeit im Security Team von Fedora offen.

Generalschlüssel für X.Org 1.11

Wie heise security berichtet, existiert in der X.Org Version 1.11 ein Generalschlüssel, womit sich z.B ein gesperrter Bildschirm mühelos entsperren lässt.

Ein aktuelles Fedora enthält bereits einen Fix, daher sollte man unbedingt darauf achten, dass die Pakete auf dem aktuellen Stand sind – oder die im Artikel beschriebenen Workarounds durchführen.

Ultrakurztipp: SELinux in zwei Schritten loswerden

Wer keinen Bedarf an Security-Enhanced Linux (SELinux) unter Fedora 15 hat, kann es mit nur 2 Schritten los werden:

1. Konfigurationsdatei bearbeiten

su -
vi /etc/selinux/config

Hier ändern wir SELINUX=enforcing in SELINUX=disabled und speichern danach die Datei. Dies funktioniert natürlich auch mit jedem anderen Texteditor, nicht nur mit VI.

2. X-Server neustarten
Mit Strg-Alt-Backspace starten wir den X-Server neu oder starten einfach den Rechner komplett neu.

Update:
Da SELinux kernelbasiert läuft, ist ein kompletter Reboot notwendig.
Danke an red für den Hinweis!

Das war’s!