En ny stabil gren av Flatpak 1.12-verktøysettet har blitt publisert, som gir et system for å bygge selvstendige pakker som ikke er knyttet til spesifikke Linux-distribusjoner og kjøres i en spesiell beholder som isolerer applikasjonen fra resten av systemet. Støtte for å kjøre Flatpak-pakker er gitt for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux og Ubuntu. Flatpak-pakker er inkludert i Fedora-depotet og støttes av den opprinnelige GNOME-applikasjonsbehandleren.
Nøkkelinnovasjoner i Flatpak 1.12-grenen:
- Forbedret administrasjon av nestede sandkassemiljøer brukt i flatpak-pakken med klienten for Steam-spillleveringstjenesten. I nestede sandkasser er det tillatt å lage separate hierarkier av /usr- og /app-katalogene, som brukes i Steam for å starte spill i en separat beholder med sin egen /usr-partisjon, isolert fra miljøet med Steam-klienten.
- Alle pakkeforekomster med samme applikasjonsidentifikator (app-ID) deler katalogene /tmp og $XDG_RUNTIME_DIR. Alternativt, ved å bruke "--allow=per-app-dev-shm"-flagget, kan du aktivere bruken av den delte katalogen /dev/shm.
- Forbedret støtte for Text User Interface (TUI)-applikasjoner som gdb.
- En raskere implementering av "ostree prune"-kommandoen er lagt til build-update-repo-verktøyet, optimert for arbeid med repositories i arkivmodus.
- Sårbarheten CVE-2021-41133 i implementeringen av portalmekanismen, assosiert med mangelen på blokkering av nye systemanrop relatert til montering av partisjoner i seccomp-reglene, er rettet. Sårbarheten tillot applikasjonen å opprette en nestet sandkasse for å omgå "portal"-verifiseringsmekanismene som brukes til å organisere tilgang til ressurser utenfor beholderen.
Som et resultat kan en angriper, ved å utføre monteringsrelaterte systemanrop, omgå sandkasseisoleringsmekanismen og få full tilgang til innholdet i vertsmiljøet. Sårbarheten kan bare utnyttes i pakker som gir applikasjoner direkte tilgang til AF_UNIX-sockets, slik som de som brukes av Wayland, Pipewire og pipewire-pulse. I utgivelse 1.12.0 ble ikke sikkerhetsproblemet fullstendig eliminert, så oppdatering 1.12.1 ble sluppet på høykant.
La oss minne deg på at Flatpak lar applikasjonsutviklere forenkle distribusjonen av programmene deres som ikke er inkludert i standard distribusjonslagre ved å klargjøre en universalbeholder uten å lage separate sammenstillinger for hver distribusjon. For sikkerhetsbevisste brukere lar Flatpak deg kjøre en tvilsom applikasjon i en container, og gir kun tilgang til nettverksfunksjonene og brukerfilene knyttet til applikasjonen. For brukere som er interessert i nye produkter, lar Flatpak deg installere de siste test- og stabile utgivelsene av applikasjoner uten å måtte gjøre endringer i systemet. For eksempel er Flatpak-pakker bygget for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
For å redusere pakkestørrelsen inkluderer den bare applikasjonsspesifikke avhengigheter, og de grunnleggende system- og grafikkbibliotekene (GTK, Qt, GNOME og KDE biblioteker, etc.) er utformet som plug-in standard kjøretidsmiljøer. Den viktigste forskjellen mellom Flatpak og Snap er at Snap bruker komponentene i hovedsystemmiljøet og isolasjon basert på filtrering av systemanrop, mens Flatpak oppretter en container separat fra systemet og opererer med store kjøretidssett, og gir ikke pakker som avhengigheter, men standard. sine systemmiljøer (for eksempel alle biblioteker som er nødvendige for driften av GNOME- eller KDE-programmer).
I tillegg til standard systemmiljø (runtime), installert gjennom et spesielt depot, leveres ytterligere avhengigheter (bunt) som kreves for driften av applikasjonen. Totalt sett utgjør runtime og bunt fyllingen av containeren, til tross for at runtime er installert separat og knyttet til flere containere samtidig, noe som lar deg unngå duplisering av systemfiler som er felles for containere. Ett system kan ha flere forskjellige kjøretider installert (GNOME, KDE) eller flere versjoner av samme kjøretid (GNOME 3.40, GNOME 3.42). En container med en applikasjon som avhengighet bruker en binding kun til en spesifikk kjøretid, uten å ta hensyn til de individuelle pakkene som utgjør kjøretiden. Alle manglende elementer pakkes direkte med applikasjonen. Når en beholder dannes, monteres kjøretidsinnholdet som /usr-partisjonen, og bunten monteres i /app-katalogen.
Runtime- og applikasjonsbeholderne er bygget ved hjelp av OSTree-teknologi, der bildet er atomisk oppdatert fra et Git-lignende depot, som lar versjonskontrollmetoder brukes på distribusjonskomponentene (du kan for eksempel raskt rulle tilbake systemet til en tidligere tilstand). RPM-pakker oversettes til OSTree-depotet ved hjelp av et spesielt rpm-otree-lag. Separat installasjon og oppdatering av pakker i arbeidsmiljøet støttes ikke; systemet oppdateres ikke på nivå med individuelle komponenter, men som en helhet, og endrer atomisk tilstand. Gir verktøy for å bruke oppdateringer trinnvis, og eliminerer behovet for å erstatte bildet fullstendig med hver oppdatering.
Det genererte isolerte miljøet er helt uavhengig av distribusjonen som brukes, og med riktige innstillinger av pakken, har ikke tilgang til filer og prosesser til brukeren eller hovedsystemet, kan ikke få direkte tilgang til utstyret, med unntak av utdata via DRI, og anrop til nettverksdelsystemet. Grafikkutgang og inndataorganisering implementeres ved hjelp av Wayland-protokollen eller via X11-socket-videresending. Interaksjon med det eksterne miljøet er basert på DBus meldingssystem og en spesiell Portals API.
For isolasjon brukes Bubblewrap-laget og tradisjonelle Linux-beholdervirtualiseringsteknologier, basert på bruk av cgroups, namespaces, Seccomp og SELinux. PulseAudio brukes til å sende ut lyd. I dette tilfellet kan isolasjon deaktiveres, som brukes av utviklerne av mange populære pakker for å få full tilgang til filsystemet og alle enhetene i systemet. For eksempel kommer GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity og VLC med en begrenset isolasjonsmodus som gir full tilgang til hjemmekatalogen.
Hvis pakker med tilgang til hjemmekatalogen blir kompromittert, til tross for tilstedeværelsen av "sandboxed"-etiketten i pakkebeskrivelsen, trenger angriperen bare å endre ~/.bashrc-filen for å utføre koden sin. Et eget problem er kontroll av endringer i pakker og tillit til pakkebyggere, som ofte ikke er knyttet til hovedprosjektet eller distribusjonene.
Kilde: opennet.ru