Efter to et halvt år med udvikling er den nye stabile version af værktøjet Flatpak 1.16 offentliggjort, som giver et system til at bygge selvforsynende pakker, der ikke er bundet til specifikke Linux-distributioner og køres i en særlig container, der isolerer applikationen fra resten af systemet. Understøttelse af kørsel af Flatpak-pakker er sikret for Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkluderet i Fedora-repositoriet og understøttes i de standard applikationsadministrationsprogrammer GNOME og KDE.
Nøglefunktioner i Flatpak 1.16:
- Overgangen til Meson build-systemet er gennemført. Understøttelse af byggeri ved hjælp af Autotools er ophørt. For at bygge Flatpak kræves nu, at systemet har Python, mindst version 3.5.
- Implementeret adgang til gssproxy-socketen, som muliggør autentificering gennem Kerberos i applikationer, der køres i sandbox-isolationsmode.
- Ved oprettelse af socket for Wayland anvendes udvidelsen security-context, som gør det muligt for en compositor server at identificere og begrænse applikationer, der kører i sandbox-isolationsmode. Tilføjet mulighed for „--socket=inherit-wayland-socket” for at arve en eksisterende socket for Wayland.
- Efter installation eller opdatering af applikationer sikres automatisk genstart af D-Bus sessionsbussen for at inkludere nye D-Bus-tjenester, der eksporteres af applikationer.
- Distributionerne har fået muligheden for at definere repositorier med Flatpak-pakker ved hjælp af kataloget „/usr/share/flatpak/remotes.d”, udover „/etc/flatpak/remotes.d”.
- Der er blevet arbejdet på at opdele store filer med kildekode i mindre moduler.
- Tilføjet mulighed for „--device=input” for adgang til input-enheder gennem /dev/input.
- For at isolere applikationer er den nye version af værktøjet bubblewrap 0.11 blevet taget i brug. I distributioner, der bygger Flatpak ved hjælp af den systemiske bwrap-eksekverbare fil, er det nødvendigt at have mindst version 0.11 af bubblewrap. Beskyttelsen mod oprettelse af indlejrede brugernavnrum i sandbox-miljøer er blevet styrket.
- Opsætningen af yderligere sprog er blevet forenklet. Der er sikret sprogidentifikation baseret på oplysninger om brugerne, udstedt af D-Bus-tjenesten AccountsService.
- Applikationer, der bruger indlejret sandbox-isolering, for eksempel baseret på WebKit-motoren, får lov til at anvende AT-SPI-protokollen til interaktion med skærmlæsere. En mulighed «flatpak run —a11y-own-name» er tilføjet for at vælge den bus, der bruges til at få adgang til værktøjer for personer med handicap.
- Når kommandoen «flatpak run -vv » udføres, vises alle anvendelige indstillinger for sandbox-isolering.
- Muligheden «—device=usb» samt parametrene «—usb» og «—no-usb» tilføjes for at styre applikationens adgang til USB-enheder.
- Support til rammeværket KCompletion er tilføjet, som anvendes til automatisk udfyldning af søgeord i KDE.
- Miljøvariablerne «FLATPAK_DATA_DIR» og «FLATPAK_DOWNLOAD_TMPDIR» er tilføjet for at omdefinere kataloger for data ( /usr/share/flatpak ) og midlertidige filer til downloads ( /var/tmp ).
- Escape-sekvenser til visning af fremdrift af operationer i terminal-emulatorer er tilføjet.
Lad os minde om, at Flatpak forenkler distributionen af programmer, der ikke er inkluderet i standardrepositoryerne for distributioner, ved at forberede en enkelt universel container, der sparer udviklere for at skulle lave separate builds for hver distribution. Brugere, der bekymrer sig om sikkerheden, kan køre tvivlsomme applikationer i en container og give selektiv adgang kun til de nødvendige netværksfunktioner og brugerfiler. Brugere, der er interesseret i nyheder, kan installere de nyeste beta- og stabile versioner af applikationer uden at skulle ændre systemet. For eksempel bygges Flatpak-pakkerne til LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio mv.
For at reducere størrelsen inkluderer pakken kun applikationsspecifikke afhængigheder. Grundlæggende system- og grafiske biblioteker (GTK, Qt, GNOME og KDE biblioteker osv.) leveres som plug-in type runtime-miljøer. Den vigtigste forskel mellem Flatpak og Snap er, at Snap bruger komponenter fra det primære systems miljø og isolering baseret på filtrering af systemopkald, mens Flatpak opretter en separat container fra systemet og opererer med store runtime-sæt, der leverer typiske systemmiljøer som afhængigheder (for eksempel alle biblioteker nødvendige for at køre GNOME eller KDE programmer).
Udover det typiske systemmiljø (runtime), der installeres via et specielt repository, leveres der yderligere afhængigheder (bundle), der kræves for at køre applikationen. Sammen danner "runtime" og "bundle" fyldet i containeren, hvor "runtime" installeres separat og knyttes til flere containere, hvilket gør det muligt at undgå at duplicere fælles systemfiler for containere.
Flere forskellige «runtime» (GNOME, KDE) eller flere versioner af én «runtime» (GNOME 46, GNOME 47) kan installeres på ét system. Containeren med applikationen som afhængighed bruger binding kun til det bestemte «runtime», uden hensyntagen til de enkelte pakker, der udgør det valgte «runtime». Alle manglende elementer pakkes direkte sammen med applikationen. Når der oprettes en container, monteres indholdet af «runtime» som sektionen /usr, og «bundle» monteres i katalogen /app.
Indholdet af "runtime" og applikationscontainere dannes ved hjælp af OSTree-teknologi, hvor billedet atomart opdateres fra et Git-lignende lager, der gør det muligt at anvende versioneringsmetoder til komponenterne i distributionen (for eksempel kan systemet hurtigt rulles tilbage til en tidligere tilstand). RPM-pakker transkriberes til OSTree-repositoriet ved hjælp af lag af rpm-ostree.
Valgfrie installationer og opdateringer af pakker inden for arbejdsmiljøet understøttes ikke — systemet opdateres ikke på niveauet for enkelte komponenter, men fuldt ud, atomart ændring af sin tilstand. Der leveres værktøjer til inkrementel anvendelse af opdateringer, der fjerner behovet for fuld udskiftning af billedet ved hver opdatering.
Det isolerede miljø dannes fuldstændigt uafhængigt af den anvendte distribution, og ved passende konfigurationer har pakken ikke adgang til brugerens eller hovedsystemets filer og processer, og den kan heller ikke direkte kontakte hardwaren, undtagen gennem DRI. Grafikudgang og indgangsorganisation er realiseret ved hjælp af Wayland-protokollen eller gennem X11-socket forwarding. Interaktion med den eksterne verden er bygget gennem DBus-meddelelsessystemet og et specialiseret API kaldet Portals.
Til isolering anvendes Bubblewrap-laget og traditionelle Linux-teknologier til containervirtualisering, baseret på brugen af cgroups, namespaces, Seccomp og SELinux. Lydudgang håndteres via PulseAudio eller PipeWire. Når pakken oprettes, kan isoleringen deaktiveres, hvilket mange populære pakkeudviklere udnytter for at få fuld adgang til filsystemet og alle enheder i systemet.
For eksempel leveres pakker som GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity og VLC med en begrænset isolationsmodus, der giver fuld adgang til hjemmemappen. I tilfælde af kompromittering af pakker med adgang til hjemmemappen, til trods for at pakken er markeret som 'sandboxed', er det tilstrækkeligt for angriberen at ændre filen ~/ .bashrc for at eksekvere sin kode. Et særskilt spørgsmål er kontrollen over ændringer i pakkerne og tilliden til pakke-buildere, som ofte ikke er tilknyttet det primære projekt eller distributionerne.
Kilde: opennet.ru
