Dopo due anni e mezzo di sviluppo, è stata pubblicata una nuova versione stabile del toolkit Flatpak 1.16, che fornisce un sistema per la creazione di pacchetti autonomi, non legati a distribuzioni Linux specifiche e eseguiti in un contenitore speciale che isola l'applicazione dal resto del sistema. Il supporto per l'esecuzione dei pacchetti Flatpak è garantito per Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux e Ubuntu. I pacchetti Flatpak sono inclusi nel repository di Fedora e supportati nei programmi di gestione delle applicazioni di GNOME e KDE.
Novità principali nella versione Flatpak 1.16:
- È avvenuto il passaggio all'uso del sistema di build Meson. Il supporto per la build tramite il toolkit Autotools è stato interrotto. Per costruire Flatpak ora è necessario avere Python installato nel sistema, versione 3.5 o superiore.
- È stata implementata la condivisione del socket gssproxy, che consente di utilizzare l'autenticazione tramite Kerberos nelle applicazioni eseguite in modalità sandbox.
- Nella creazione di socket per Wayland è stato utilizzato il contesto di sicurezza dell'estensione, tramite il quale il compositore un server può identificare e limitare le applicazioni eseguite in modalità di isolamento sandbox. È stata aggiunta l'opzione «—socket=inherit-wayland-socket» per ereditare il socket esistente per Wayland.
- Dopo l'installazione o l'aggiornamento delle applicazioni, è garantito il riavvio automatico della configurazione del bus di sessione D-Bus per acquisire i nuovi servizi D-Bus esportati dalle applicazioni.
- I distributori hanno la possibilità di definire i repository con i pacchetti Flatpak, utilizzando la directory «/usr/share/flatpak/remotes.d», oltre a «/etc/flatpak/remotes.d».
- Sono state effettuate operazioni per suddividere grandi file di codice sorgente in piccoli moduli.
- È stata aggiunta l'opzione «—device=input» per accedere ai dispositivi di input attraverso /dev/input.
- Per l'isolamento delle applicazioni è stata impiegata una nuova versione dello strumento bubblewrap 0.11. Nelle distribuzioni che compilano Flatpak utilizzando il file eseguibile di sistema bwrap, è richiesta almeno la versione bubblewrap 0.11. Potenziata la protezione contro la creazione di spazi identificatori utente (user namespace) annidati negli ambienti sandbox.
- La configurazione di lingue aggiuntive è stata semplificata. È ora possibile determinare le lingue in base alle informazioni utente fornite dal servizio AccountsService di DBus.
- Alle applicazioni che utilizzano l'isolamento sandbox annidato, ad esempio basate sul motore WebKit, è consentito l'uso del protocollo AT-SPI per interagire con i lettori di schermo. È stata aggiunta l'opzione «flatpak run —a11y-own-name» per selezionare il bus attraverso cui accedere agli strumenti per persone con disabilità.
- Eseguendo il comando «flatpak run -vv », viene mostrata tutte le opzioni applicabili di isolamento sandbox.
- È stata aggiunta l'opzione «—device=usb», così come i parametri «—usb» e «—no-usb» per gestire l'accesso dell'applicazione ai dispositivi USB.
- È stato aggiunto il supporto per il framework KCompletion, utilizzato per l'autocompletamento delle chiavi di ricerca in KDE.
- Sono state aggiunte le variabili d'ambiente «FLATPAK_DATA_DIR» e «FLATPAK_DOWNLOAD_TMPDIR» per ridefinire le directory dei dati (/usr/share/flatpak) e dei file temporanei scaricati (/var/tmp).
- È stata aggiunta l'uscita delle sequenze di escape per visualizzare il progresso delle operazioni nei terminali.
Ricordiamo che Flatpak semplifica la distribuzione di software non incluso nei repository ufficiali delle distribuzioni, creando un unico contenitore universale che solleva gli sviluppatori dalla necessità di creare versioni separate per ogni distribuzione. Per gli utenti attenti alla sicurezza, Flatpak offre la possibilità di eseguire applicazioni sospette in un contenitore, fornendo un accesso limitato solo alle funzionalità di rete e ai file necessari. Per coloro che sono interessati alle novità, Flatpak consente di installare le versioni più recenti, sia in fase di testing che stabili, senza dover apportare modifiche al sistema. Ad esempio, i pacchetti Flatpak sono disponibili per LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio, ecc.
Per ridurre le dimensioni, il pacchetto include solo le dipendenze specifiche per l'applicazione. Le librerie di sistema e grafiche di base (GTK, Qt, librerie GNOME e KDE, ecc.) vengono fornite come ambienti runtime standard. La principale differenza tra Flatpak e Snap è che Snap utilizza i componenti dell'ambiente del sistema principale e l'isolamento basato sulla filtrazione delle chiamate di sistema, mentre Flatpak crea un contenitore separato dal sistema e opera con ampi set di runtime, fornendo come dipendenze non pacchetti, ma ambienti di sistema standard (ad esempio, tutte le librerie necessarie per eseguire applicazioni GNOME o KDE).
Oltre all'ambiente di sistema standard (runtime), installato tramite un repository speciale, vengono fornite dipendenze aggiuntive (bundle) necessarie per il funzionamento dell'applicazione. Insieme, il «runtime» e il «bundle» formano il nucleo del contenitore, dove il «runtime» viene installato separatamente e collegato a più contenitori, evitando la duplicazione dei file di sistema comuni ai contenitori.
In un sistema possono essere installati diversi «runtime» (GNOME, KDE) o più versioni dello stesso «runtime» (GNOME 46, GNOME 47). Il container dell'applicazione come dipendenza utilizza il binding solo a uno specifico «runtime», senza tenere conto dei singoli pacchetti che formano il «runtime» selezionato. Tutti gli elementi mancanti vengono impacchettati direttamente con l'applicazione. Durante la creazione del container, il contenuto del «runtime» viene montato come partizione /usr, mentre il «bundle» viene montato nella directory /app.
Il nucleo del «runtime» e dei contenitori delle applicazioni è generato utilizzando la tecnologia OSTree, attraverso la quale l'immagine viene aggiornata in modo atomico da un repository simile a Git, permettendo di applicare tecniche di controllo delle versioni ai componenti della distribuzione (ad esempio, è possibile ripristinare rapidamente il sistema a uno stato precedente). I pacchetti RPM vengono traslati nel repository OSTree mediante un livello intermedio rpm-ostree.
L'installazione selettiva e l'aggiornamento dei pacchetti all'interno dell'ambiente di lavoro non sono supportati: il sistema viene aggiornato non a livello di componenti singoli, ma globalmente, cambiando atomisticamente il proprio stato. Sono forniti strumenti per applicare aggiornamenti incrementali, evitando la necessità di una sostituzione completa dell'immagine a ogni aggiornamento.
L'ambiente isolato creato è completamente indipendente dal sistema operativo utilizzato e, se configurato correttamente, non ha accesso ai file e ai processi dell'utente o del sistema principale, né può accedere direttamente all'hardware, ad eccezione dell'output tramite DRI. L'output grafico e l'organizzazione dell'input sono realizzati tramite il protocollo Wayland o tramite il forwarding del socket X11. L'interazione con l'ambiente esterno è costruita attraverso un sistema di messaggistica DBus e un'API Portals specifica.
Per l'isolamento viene utilizzato uno strato di Bubblewrap e tecnologie tradizionali di virtualizzazione dei container per Linux, basate sull'uso di cgroups, spazi dei nomi (namespaces), Seccomp e SELinux. Per l'uscita audio si impiega PulseAudio o PipeWire. Durante la creazione del pacchetto, l'isolamento può essere disattivato, una pratica usata dagli sviluppatori di molti pacchetti popolari per ottenere accesso completo al file system e a tutti i dispositivi nel sistema.
Ad esempio, con la modalità di isolamento limitato che consente l'accesso completo alla directory home, vengono forniti pacchetti come GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity e VLC. In caso di compromissione dei pacchetti con accesso alla directory home, nonostante la presenza dell'etichetta «sandboxed» nella descrizione del pacchetto, per l'attaccante è sufficiente modificare il file ~/ .bashrc per eseguire il proprio codice. Un ulteriore questione riguarda il controllo delle modifiche ai pacchetti e la fiducia nei costruttori di pacchetti, che spesso non sono legati al progetto principale o ai distributori.
Fonte: opennet.ru
