Flatpak - een beveiligingsnachtmerrie

In het afgelopen decennium is de Linux-desktop echter drastisch verbeterd: Flatpak, Wayland, Portals, PipeWire en FreeDesktop hebben allemaal gewerkt om van Linux een besturingssysteem te maken dat beter geschikt is voor moderne (desktop)systemen. Ik zal die niet allemaal behandelen; zoals je aan de titel kunt zien, gaat dit over Flatpak!

Geschiedenis

Laten we kort naar de serverwereld kijken. Het is niet ongebruikelijk om servers te zien die kernels en libraries van tien jaar oud (soms zelfs nog ouder!) draaien. Dit is logisch, aangezien hun opstarttijden lang zijn en er bij elke systeemupdate een risico is op defecten die vervolgens gedebugd moeten worden. Hierbij gaat waardevolle uptime verloren, zeker voor een dienst zo groot als Google. Natuurlijk hebben zij een manier ontwikkeld om de meest relevante delen van het systeem snel te patchen, zodat beveiliging niet te veel een probleem wordt.

De software die ze echter draaien, kan mogelijk alleen nieuwere functies van nieuwere libraries gebruiken, en niet de oude, versleten software die de servers zelf draaien. Hoe hebben ze dat opgelost?

Containers. Deze worden normaal gesproken gebruikt om software op een consistente en veiligere manier naar verschillende klanten te verzenden. Ze maken het mogelijk om software te isoleren in een klein "doosje" met alle benodigde dependencies in de gespecificeerde versies, met beperkte toegang tot het gastsysteem.

Het heden

We hebben Android, macOS en iOS, die allemaal beperkte toegang tot het systeem hebben en tussenkomst van de eindgebruiker vereisen om toegang te krijgen tot bepaalde bronnen. Maar hoe zit het met de Linux-desktop?

In 2015 werd Flatpak uitgebracht, waarbij alle technologie van containerisatie op servers werd toegepast op desktopsystemen. Hiermee kwamen Portals en de Freedesktop SDK. Dit gaf ontwikkelaars een consistent en generiek platform en API, een drastische verandering ten opzichte van wat voorheen een slagveld was van variërende dependency-versies, kernsysteem-libraries en verpakkingsformaten.

Natuurlijk was dit, na enkele decennia waarin de distributie- en developmentsituatie hetzelfde was gebleven, een te grote verandering om in één keer door te voeren. Veel van de benodigde API's bestaan, maar ontwikkelaars moeten tijd vrijmaken om hiernaar te migreren. Sommige gebruikers (specifiek degenen die een hekel hebben aan Flatpak) weigeren pertinent te helpen de situatie te verbeteren en hameren erop dat we vasthouden aan de oude manier van doen, waarbij software honderden keren opnieuw moet worden verpakt voor duizenden verschillende systemen.

Kortom: natuurlijk gaf niemand die daar verstand van heeft daar om. Veel nieuwe applicatie-ontwikkelaars creëren hun apps met een afgeschermde omgeving in gedachten en leveren hun software via Flathub, waardoor de software de eindgebruiker op een snelle en veilige manier bereikt.

Applicatie-isolatie

Maar hoe zit het met de oude applicaties? Je vindt immers apps van tien jaar oud op Flathub. Vanuit deze applicaties ontstonden artikelen zoals Flatpak - a security nightmare (ja, die naam herken je misschien!), en diverse reacties van bekende personen binnen de FOSS-community die bedoeld waren om desinformatie en agressie uit die artikelen tegen te gaan.

Voor deze apps kiezen FUD-artikelen (fear, uncertainty, and doubt) graag de ergste overtreders uit om vervolgens te stellen dat het niet de moeite waard is om Flatpak te promoten. Ik wil dat graag adresseren.

Deze applicaties waren ontworpen voor een onbeperkte omgeving, en de API's die daarvoor nodig zijn bestonden op dat moment niet of zijn niet bijgewerkt om de nieuwe API te gebruiken. Het selecteren van deze specifieke apps om aan te tonen dat de Flatpak-sandbox "geen sandbox is", is geen geldig argument; het laat alleen zien dat de applicaties zelf onveilig zijn.

Natuurlijk zijn oudere apps niet de enige boosdoeners. Omdat nieuwe API's mogelijk nog niet volwassen genoeg zijn, moeten zowel nieuwere als oudere apps soms terugvallen op statische permissies om correct te kunnen werken. Voor de meeste nieuwere applicaties is dit prima, omdat zij hun permissies veel strikter kunnen beperken dan oudere applicaties kunnen.

Flatpak is een sandbox. En Flatpak is veilig. De applicaties zijn dat niet. Het helpt niemand om de betekenis van het woord "sandbox" te veranderen. Alleen omdat de sandbox die sommige apps gebruiken niet op het niveau van iOS of Android zit, diskwalificeert dat het niet als sandbox. Als je daar Flatpak de schuld van wilt geven, zoek het maar uit. Het feit dat apps vertrouwen op statische permissies laat zien dat de applicaties onveilig zijn en vertrouwen op inconsistente interfaces, en in sommige gevallen dat de huidige API's nog niet genoeg zijn verbeterd voor hun specifieke use-cases. We zouden ons moeten richten op het verbeteren van die situatie, niet op het afbreken ervan.

Als je een praktijkvoorbeeld wilt van hoe een gedeeltelijke sandbox nog steeds effectief is, kijk dan naar de "fractureiser"-malware. Zelfs als de malware in eerste instantie niet functioneel was op Linux, is het nog steeds een voorbeeld van hoe traditionele verpakking faalt om het feit aan te pakken dat moderne desktopsystemen talloze manieren hebben om gecompromitteerd te worden. Software draaien "die je vertrouwt" is niet genoeg om jezelf te beschermen. Om de relevante aantekeningen uit het gelinkte bericht te citeren:

Als je Linux gebruikt, gebruik dan de PrismLauncher Flatpak en wees zeer voorzichtig met waar je toegang toe geeft via utilities zoals Flatseal. Standaard heeft het geen toegang tot de mappen die nodig zijn om het systeem te compromitteren.

Bij het bekijken van de gedecompileerde broncode blijkt dat het inderdaad niet zal functioneren binnen de standaard PrismLauncher Flatpak-sandbox; de huidige malware hardcodeert de ~/.config/ directory van de gebruiker. Het aanmaken van bestanden binnen de Flatpak-sandbox, als de app geen toegang heeft tot dat werkelijke pad, resulteert erin dat deze worden geschreven naar een tmpfs die wordt gewist bij een herstart van de sandbox. Ook systemd is niet beschikbaar binnen de Flatpak-sandbox, dus het uitvoeren van dat commando zal mislukken. De malware lijkt niet te proberen deze beperkingen te omzeilen en gaat ervan uit dat deze onbeveiligd draait.

(Disclaimer: ik heb de bovenstaande aantekeningen zelf geschreven)

Voor een diepgaander inzicht in statische permissies en Portals, zie Overview of Flatpak’s Permission Models door TheEvilSkeleton.

Verouderde dependencies

Sommigen brengen ook verouderde dependencies aan in de discussie. Nee, dat doet er niet toe. De runtime zelf wordt bijgewerkt zodra een benodigde beveiligingsupdate beschikbaar is (soms wordt zelfs de ABI gebroken als het ernstig genoeg is) en applicatie-ontwikkelaars hoeven niet na te denken over het handmatig bijwerken van gebundelde dependencies dankzij automatische update-checks. Bovendien kunnen veel belangrijke libraries, zoals je GPU-drivers, apart van je runtime worden bijgewerkt als je dat wilt. Verouderde dependencies is dus eigenlijk geen valide argument.

In het geval dat een applicatie wél verouderde libraries gebruikt — of dat nu komt omdat een update het buildproces heeft gebroken of omdat de ontwikkelaar is vergeten de data-checker in te stellen — is er de sandbox rondom alle Flatpak-applicaties die kan helpen deze problemen te mitigeren terwijl de ontwikkelaar ze oplost.

De toekomst

De hoop is dat de Linux-desktop overstapt op softwaredistributie- en programmeermethoden die vriendelijker zijn voor ontwikkelaars en sandboxing. We hebben al grote stappen gezet met PipeWire, wat de weg vrijmaakt voor veel mooie functies voor audio en video (inclusief meerdere apps die tegelijkertijd je camera gebruiken!), en FreeDesktop. Maar we hebben ongetwijfeld nog een weg te gaan voordat Linux een levensvatbaar platform is voor ontwikkelaars om software voor te targeten en te distribueren.

We kunnen niet vooruit zonder moderne software zoals Wayland en Flatpak, ongeacht hoeveel men de situatie met Xorg en traditionele verpakking wil herstellen. Als we blijven proberen terug te keren naar de oude manier van doen, is het enige dat we aan ontwikkelaars laten zien dat Linux geen platform is om serieus te overwegen. Dit resulteert in een slechtere situatie voor eindgebruikers; een "wat kwam eerst: de kip of het ei?"-scenario, wat leidt tot een zeer slechte gebruikerservaring (UX).

Dat willen we voorkomen.

Verdere lectuur

Voor meer informatie over Flatpak en over het algemeen over hoe het werkt en wat de huidige situatie is, zijn de volgende artikelen het lezen waard:

• Response to flatkill.org - TheEvilSkeleton
• Response to “Flatpak Is Not the Future” - TheEvilSkeleton
• Traditional Packaging is not Suitable for Modern Applications - TheEvilSkeleton
• Overview of Flatpak’s Permission Models - TheEvilSkeleton
• Response to “Developers are lazy, thus Flatpak” - TheEvilSkeleton
• Distribution packaging for Linux desktop applications is unsustainable - memoryfile
• You are not actually mad at Flatpak - Jordan Petridis