Und du meinst also bei flatpack könnte nichts passieren?
Hast du dir mal durchgelesen, was mit dem xz-Problem dieses Jahr eigentlich erreicht werden sollte?
Und wie dies überhaupt geschah?
Gibt es 4 schöne Artikel in einem C't Sonderheft.....
Mit so etwas ist es egal ob flatpack oder Repo oder was auch immer.
Ihr könnt da auch noch stundenlang darüber diskutieren. Das führt aber zu nichts. In der IT ist nur eines absolut sicher ... nämlich, das nichts, aber auch gar nichts sicher ist. Ich denke, darauf können wir uns alle verständigen.
Edit: Wen die xz Geschichte interessiert, ich habe hier in meinem Archiv mal einen Link heraus gekramt:
Alles anzeigenUnd du meinst also bei flatpack könnte nichts passieren?
Hast du dir mal durchgelesen, was mit dem xz-Problem dieses Jahr eigentlich erreicht werden sollte?
Und wie dies überhaupt geschah?
Gibt es 4 schöne Artikel in einem C't Sonderheft.....
Mit so etwas ist es egal ob flatpack oder Repo oder was auch immer.
Flatpak ist in einem anderen Sicherheitskontext. Bei Flatpak werden keine Repo-Pakete überschrieben, und für eine Kompromittierung von Systemdaten bräuchte man eine Exploit-Chain, was objektiv schwerer ist, als ein bösartiges Paket in Packman auszutauschen. Es geht hierbei wieder um Wahrscheinlichkeiten, und was das kleinere Übel ist. Und Flatpak Apps sind aus Sicht der Sicherheit und Systemstabilität das kleinere Übel. Distros wie Debian empfehlen explizit Flatpak vor Dritt-Repos, wenn eine App nicht im Hauptrepo sei.
Die xz Lücke ist imho eine ganz andere Kategorie als Supply Chain attack. Bei Packman ist die größte Gefahr keine Supply Chain Attack, sondern dass ein inkompetenter/Bösartiger Akteur direkt Pakete manipuliert. Das heißt, dem entsprechen ist hier von der Wahrscheinlichkeit Packman gefährlicher, weil von xz-Lücke betroffen, aber gleichzeitig auch noch zusätzlich von den o.g. Gefahren als Dritt-Repo. Und die xz Lücke bei Flatpak wäre dann immer noch in einem Sandbox Kontext und im Worst Case erstmal nur Teile der Userdaten betroffen und ohne Exploit Chain und Manipulation von SE Linux bliebe alles im User-Kontext und nicht als root.
Und um Alero aufzugreifen:
Ja, es gibt keine Sicherheit. IT Security bedeutet nur sicherzustellen, dass dein System etwas schwerer zu übernehmen ist, als das eines anderen. Der Angreifer wählt i.d.R. den leichtesten Weg.
In dem Sinne: Wenn ein Angreifer die openSUSE Leap/Tumbleweed User in der Breite kompromittieren wollen würde, wäre der leichteste Weg, das Packman Repo anzugreifen. Das ist bei den meisten unbedarften Usern Standard.
In dem Sinne: Wenn ein Angreifer die openSUSE Leap/Tumbleweed User in der Breite kompromittieren wollen würde, wäre der leichteste Weg, das Packman Repo anzugreifen. Das ist bei den meisten unbedarften Usern Standard.
Das würde genauso auffallen als wenn ich bei flatpack eingreife.
Die Kompromittierung geschieht schon in den Sourcen.
Die xz Attacke sollte ja eigentlich ein essentielles Paket kompromittieren:
openssh.
Noch einmal:
Kauf dir das C't Sonderheft und lies dir die 4 Artikel über diese Attacke mal durch, dann weißt du was auch das grundlegende Problem ist:
Vertrauen.
Und nicht mal eben schnell ein Paketbau ändern.......
dann weißt du was auch das grundlegende Problem ist:
Vertrauen.
Das ist prinzipiell richtig. Aber wenn wir das jetzt mal hinterfragen ... wem kann man vertrauen? Kann ich den Erstellern der Distributionen vollständig vertrauen? Kann ich einem Betriebssystem vollständig vertrauen bzw. den Machern?
Wie das xz Problem schön vor Augen führt kann man selbst opensource nicht vertrauen. Kann ich einem Programm vertrauen? Einer Verschlüsselung? Man will diese ja schon aushebeln. Selbst wenn ich verschlüsselte Chats nutze habe ich trotzdem immer ein saures Gefühl.
Wem oder was kann man also wirklich! vertrauen? In der IT eigentlich so gut wie niemandem. Alles ist angreifbar. Man kann also, meiner Meinung nach, Vertrauen und Computer nicht in einem Satz erwähnen.
Alles ist angreifbar. Man kann also, meiner Meinung nach, Vertrauen und Computer nicht in einem Satz erwähnen.
Man kann es wohl erwähnen, denn man muss:
vertrauen.....
denn man muss:
vertrauen.....
Einfach aus dem Grunde, weil man keine andere Wahl hat.
Bei Packman vertraue ich der Community. Funktioniert seit ca. 1995 bei mir. Da werde ich also nichts umstellen - hat sich ja ausgezahlt.
Bei offiziellen Repos bürgen die Distributoren für Sicherheit. Aber die sind eh' eingebunden - was auch sonst.
Nur: Das Böse ist immer und überall. Eine Firma hat weniger Augen, evtl genervte Mitarbeiter, als "freie Verfechter einer Ideologie, die auch praktisch funktioniert" (Linuxer).
Was Flatpak angeht - warum nicht? Allerdings gilt hier, dass die meisten Flatpaks von Flathub kommen. Hier verlassen sich Nutzer tatsächlich oft auf eine zentrale Instanz statt auf die Maintainer ihrer spezifischen Distribution.Flatpak kompensiert dieses "fremde Vertrauen" durch technische Barrieren: Anwendungen laufen in einer Sandbox. Selbst wenn ein Paket kompromittiert wäre, hat es theoretisch keinen Zugriff auf Ihre restlichen Daten, sofern die Berechtigungen nicht zu weit gefasst sind.Das Risiko: Die Sicherheit kann "aufgeweicht" werden, wenn Flatpaks mit zu vielen Berechtigungen (z.B. Zugriff auf das gesamte Dateisystem) ausgeliefert werden oder wenn Sicherheitslücken in der Sandbox selbst existieren.Als es noch gar kein Flatpak gab, stellte Linux das erste funktionierende 64-Bit Betriebssystem vor. Packman war immer dabei, damit dieses tat, was es sollte.Man kann immer weiter theoretisieren, aber es bleibt dabei: Der Mensch ist und bleibt der größte "Schwachkopf". Wo aber die Mehrzahl Vernünftiger in die "Open-Source Eingeweide" schauen kann, ist man wegen der Transparenz die maximale menschlich-mögliche Sicherheit.Das fällt mir zu diesem Thema als Pragmatiker, bzw. Praktiker, bzw. praktischer Theoretiker ... oder besser theoretischer Pragmatiker ... oder auch theoretischer Theoretiker usw. ein.
Alles anzeigenDas würde genauso auffallen als wenn ich bei flatpack eingreife.
Die Kompromittierung geschieht schon in den Sourcen.
Die xz Attacke sollte ja eigentlich ein essentielles Paket kompromittieren:
openssh.
Noch einmal:
Kauf dir das C't Sonderheft und lies dir die 4 Artikel über diese Attacke mal durch, dann weißt du was auch das grundlegende Problem ist:
Vertrauen.
Und nicht mal eben schnell ein Paketbau ändern.......
Das sind aber trotzdem unterschiedliche Angriffsvektoren.
xz ist eine supply chain attack, wo eine essentielle Softwarekomponente mit bösartigem Code versehen wird und darauf gehofft wird, dass downstream Projekte ihre dutzenden/hunderten eingebundenen libs nicht prüfen und der Code schließlich in Produktivsystemen landet, wo er unter Umständen exploited werden kann.
Bei einem theoretischen Angriff auf Packman müsste nicht mal upstream die sources infiziert werden, da muss man "nur" im Bauprozess eingreifen. Das ist wieder eine Sache von Wahrscheinlichkeiten, aber bei einem Supply Chain Angriff gibts auf Zeit ein viel größeres Risiko, aufzufliegen. Bei einem erfolgreichen Angriff auf Packman wäre das eine Sache von Stunden zwischen Code Injektion und Ankunft auf Clients.
Flatpak ist auch gefährlich, weil da noch eine Komplexitätsschicht hinzugefügt wird, und die Maintainer z.T. überhaupt kein Vertrauensvorschuss verdienen, da irgendwelche Randoms (Deswegen sollte man da auch auf das Github Projekt des Flatpaks schauen, wer das macht. In Falle dieses Threads hab ich nur FFx und VLC empfohlen, bei denen der Flatpak Maintainer der originale Entwickler der App ist). Aber da hast du dann eine komprommitierte App, die in einer Sandbox mit eingeschränkten Rechten läuft, und darüber hast du noch Sicherheitssysteme wie Apparmor und SELinux. Da kann vorher schon Schaden angerichtet werden, aber da müssen noch mehr Hürden genommen werden, um aus dem Confinement auszubrechen und Root rechte zu bekommen, oder wie bei xz nach außen via SSH komplett offen zu sein. (Ich klammere die Möglichkeit eines DAU Users mal aus, der ein Flatpak trotz Warnung ohne Sandbox installiert).
Bei Packman ist für mich (ich wiederhole mich) das grundsätzliche Problem, dass es nicht nur zusätzliche Pakete gibt, sondern Systempakete ersetzt, die das System destabilisieren können, und bei einer Infektion mit Schadcode direkt unter höheren Rechten laufen.
Das ist für mich einfach ein wahrscheinlicher Angriffsvektor als die xz Lücke. Klar ist das eine schon passiert, und ne feindliche Übernahme von Packman nur Theorie, aber hey, es ist zu 100% Sicher dass es 20 Jahre alte RCE Lücken im Linux Kernel gibt, die noch nie jemand gesehen hat. Das ist schon passiert und wird auch wieder passieren, und das ändert auch nix an meiner Argumentation oben.
Bei Packman vertraue ich der Community. Funktioniert seit ca. 1995 bei mir. Da werde ich also nichts umstellen - hat sich ja ausgezahlt.
Das heißt in Fachkreisen: Du hast solange gute IT Security, bis etwas passiert ist. Aber dass so lange nichts passiert ist, macht den Incident ja nicht weg.
>snip>Das heißt in Fachkreisen: Du hast solange gute IT Security, bis etwas passiert ist. Aber dass so lange nichts passiert ist, macht den Incident ja nicht weg.
Hat auch niemand behauptet. Würde ja auch keinen Sinn machen, weil das ganze Leben ein Risiko ist - nicht nur die Nutzung der IT Welt, als Teilbereich menschlichen Lebens.
So ist eben nicht auszuschließen, dass ausgerechnet dort eingebrochen wird, wo vermeintlich die höchstmögliche Sicherheit umgesetzt ist.
Eigentlich hat Alero es längst auf den Punkt gebracht in # 32!
