Een nieuwe stabiele tak van de Flatpak-toolkit 1.12 is gepubliceerd. Deze biedt een systeem voor het bouwen van zelfvoorzienende pakketten die niet aan specifieke Linux-distributies gebonden zijn en die in een speciale container draaien, waardoor de toepassing van de rest van het systeem is geïsoleerd. Ondersteuning voor het uitvoeren van Flatpak-pakketten is beschikbaar voor Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux en Ubuntu. Flatpak-pakketten zijn opgenomen in de Fedora-repository en worden ondersteund in de standaardapplicatiebeheerprogramma's van GNOME.
Belangrijkste vernieuwingen in de Flatpak 1.12-tak:
- Verbeterd beheer van geneste sandbox-omgevingen die worden gebruikt in het Flatpak-pakket met de client voor de game delivery service Steam. In de geneste sandboxen is het toegestaan om afzonderlijke hiërarchieën van mappen /usr en /app te creëren, wat in Steam wordt gebruikt om games in een aparte container met een eigen /usr-partitie uit te voeren, die is geïsoleerd van de omgeving met de Steam-client.
- In alle exemplaren van pakketten met dezelfde applicatie-ID (app-ID) is het delen van de mappen /tmp en $XDG_RUNTIME_DIR verzekerd. Optioneel kan met behulp van de vlag "—allow=per-app-dev-shm" het gebruik van de gezamenlijke map /dev/shm worden ingeschakeld.
- Verbeterde ondersteuning voor toepassingen met een tekstgebaseerde gebruikersinterface (TUI), zoals gdb.
- De build-update-repo-tool heeft een snellere implementatie van het commando "ostree prune" gekregen, geoptimaliseerd voor gebruik met repositories die zich in de archiefmodus bevinden.
- Een kwetsbaarheid CVE-2021-41133 in de implementatie van het portalmechanisme is verholpen, die te maken had met het ontbreken van regels in seccomp voor het blokkeren van nieuwe systeemaanspraken die verband houden met het mounten van partities. Deze kwetsbaarheid stelde de toepassing in staat om een geneste sandbox te creëren om de verificatiemechanismen van de "portalen" te omzeilen, die worden gebruikt voor toegang tot bronnen buiten de container.
Als gevolg hiervan kon een aanvaller via het uitvoeren van gekoppelde systeemaanroepen het sandbox-isolatiemechanisme omzeilen en volledige toegang krijgen tot de inhoud van de host-omgeving. Het exploiteren van de kwetsbaarheid was alleen mogelijk in pakketten die toepassingen directe toegang tot AF_UNIX-sockets boden, zoals die gebruikt worden in Wayland, Pipewire en pipewire-pulse. In release 1.12.0 was de kwetsbaarheid niet volledig verholpen, waardoor kort na de release een update 1.12.1 is uitgebracht.
Laten we niet vergeten dat Flatpak-ontwikkelaars de mogelijkheid biedt om de distributie van hun programma's te vereenvoudigen, die niet in de standaardrepositories van distributies zitten, door één universele container voor te bereiden zonder afzonderlijke builds voor elke distributie. Voor gebruikers die zich zorgen maken over veiligheid, stelt Flatpak hen in staat om een twijfelachtig programma in een container uit te voeren, met alleen toegang tot netwerkfuncties en bestanden van de gebruiker die verband houden met het programma. Voor gebruikers die geïnteresseerd zijn in nieuwigheden, maakt Flatpak het mogelijk om de nieuwste test- en stabiele versies van applicaties te installeren zonder wijzigingen in het systeem aan te brengen. Bijvoorbeeld, Flatpak-pakketten worden verzameld voor LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, enzovoort.
Om de pakketgrootte te verminderen, bevat het alleen de applicatiespecifieke afhankelijkheden, terwijl de basis systeem- en grafische bibliotheken (GTK, Qt, GNOME- en KDE-bibliotheken, enz.) worden gepresenteerd als optionele standaard runtime-omgevingen. Het belangrijkste verschil tussen Flatpak en Snap is dat Snap componenten van de hoofdsysteemomgeving gebruikt en isolatie toepast op basis van het filteren van systeemaanroepen, terwijl Flatpak een aparte container van het systeem creëert en werkt met grote runtime-sets, waarbij niet pakketten als afhankelijkheden worden verstrekt, maar standaard syste omgevingen (bijvoorbeeld alle bibliotheken die nodig zijn voor het draaien van GNOME- of KDE-applicaties).
Naast de standaard runtime-omgeving, die via een speciale repository wordt geïnstalleerd, worden aanvullende afhankelijkheden geleverd die vereist zijn voor de werking van de applicatie. Samen vormen de runtime en de bundle de inhoud van de container, waarbij de runtime afzonderlijk wordt geïnstalleerd en aan meerdere containers kan worden gekoppeld, waardoor duplicatie van systeemfiles die gemeenschappelijk zijn voor de containers kan worden vermeden. In één systeem kunnen verschillende runtimes (GNOME, KDE) of meerdere versies van één runtime (GNOME 3.40, GNOME 3.42) zijn geïnstalleerd. De container met de applicatie als afhankelijkheid maakt alleen binding aan een specifieke runtime, zonder rekening te houden met de aparte pakketten waaruit de runtime bestaat. Alle ontbrekende elementen worden direct samen met de applicatie verpakt. Bij het vormen van de container wordt de inhoud van de runtime gemonteerd als de partitie /usr, terwijl de bundle wordt gemonteerd in de directory /app.
De inhoud van de runtime en de applicatiecontainers wordt gevormd met behulp van de technologie OSTree, waarbij het beeld atomair wordt bijgewerkt vanuit een Git-achtige opslagplaats, die het mogelijk maakt om versiebeheermethoden toe te passen op de componenten van de distributie (bijvoorbeeld kan de systeemstatus snel worden teruggedraaid naar een eerdere staat). RPM-pakketten worden omgezet naar de OSTree-repository met behulp van een speciale laag genaamd rpm-ostree. Op zichzelf staat de afzonderlijke installatie en update van pakketten binnen de werkende omgeving niet toe; het systeem wordt niet op het niveau van afzonderlijke componenten bijgewerkt, maar geheel, door atomair zijn toestand te veranderen. Er worden middelen geboden voor incrementele toepassing van updates, zodat volledige vervanging van het beeld bij elke update niet nodig is.
De gecreëerde geïsoleerde omgeving is volledig onafhankelijk van de gebruikte distributie en heeft bij juiste instellingen geen toegang tot de bestanden en processen van de gebruiker of het primaire systeem, en kan niet rechtstreeks communiceren met de hardware, met uitzondering van uitvoer via DRI en verzoeken aan de netwerksubsystemen. Grafische uitvoer en invoer zijn gerealiseerd via het Wayland-protocol of door middel van X11-socketdoorsturing. Interactie met de externe omgeving is gebaseerd op het DBus-berichtenuitwisselingssysteem en een speciale API genaamd Portals.
Voor isolatie wordt gebruikgemaakt van de Bubblewrap-laag en traditionele Linux-technologieën voor containervirtualisatie, gebaseerd op cgroups, namespaces, Seccomp en SELinux. Voor geluidsweergave wordt PulseAudio gebruikt. Hierbij kan isolatie worden uitgeschakeld, wat door ontwikkelaars van veel populaire pakketten wordt benut om volledige toegang te krijgen tot het bestandssysteem en alle apparaten in het systeem. Bijvoorbeeld, pakketten zoals GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity en VLC worden geleverd met een beperkte isolatiemodus die volledige toegang tot de thuismap mogelijk maakt.
In het geval van compromittering van pakketten met toegang tot de thuismap, kan een aanvaller, ondanks de markering "sandboxed" in de pakketbeschrijving, zijn code uitvoeren door eenvoudigweg het bestand ~/.bashrc aan te passen. Een apart punt is de controle over wijzigingen in pakketten en het vertrouwen op pakketbouwers, die vaak niet zijn verbonden met het hoofdproject of de distributies.
Bron: opennet.ru
