È stata pubblicata una nuova versione stabile dello strumento Flatpak 1.12, che fornisce un sistema per la creazione di pacchetti autosufficienti, non legati a distribuzioni Linux specifiche e eseguiti in un contenitore speciale, isolando l'applicazione dal resto del sistema. Il supporto per l'esecuzione dei pacchetti Flatpak è garantito per Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux e Ubuntu. I pacchetti Flatpak sono inclusi nel repository di Fedora e sono supportati nel programma di gestione delle applicazioni GNOME.
Innovazioni chiave nella versione Flatpak 1.12:
- Migliorata la gestione degli ambienti sandbox nidificati utilizzati nel pacchetto flatpak con il client per il servizio di distribuzione giochi Steam. Negli ambienti sandbox nidificati è consentita la creazione di gerarchie di directory separate /usr e /app, che sono utilizzate in Steam per avviare i giochi in un contenitore separato con la propria partizione /usr, isolata dall'ambiente del client Steam.
- In tutte le istanze di pacchetti con lo stesso identificatore dell'applicazione (app-ID) è garantito il riutilizzo delle directory /tmp e $XDG_RUNTIME_DIR. Facoltativamente, utilizzando il flag "--allow=per-app-dev-shm", è possibile abilitare l'uso della directory condivisa /dev/shm.
- Migliorato il supporto per le applicazioni con interfaccia utente testuale (TUI), come gdb.
- Nell'utility build-update-repo è stata aggiunta una realizzazione più veloce del comando "ostree prune", ottimizzata per lavorare con repository in modalità archivio.
- Risolta la vulnerabilità CVE-2021-41133 nell'implementazione del meccanismo dei portali, relativa all'assenza di regole seccomp per bloccare nuove chiamate di sistema legate al montaggio delle partizioni. La vulnerabilità consentiva all'applicazione di creare un sandbox nidificato per eludere i meccanismi di verifica dei "portali" utilizzati per gestire l'accesso alle risorse al di fuori del contenitore.
Di conseguenza, un attaccante, eseguendo chiamate di sistema legate al montaggio, potrebbe eludere il meccanismo di isolamento sandbox e ottenere accesso completo al contenuto dell'ambiente host. L'exploitation della vulnerabilità è possibile solo nei pacchetti che forniscono alle applicazioni accesso diretto ai socket AF_UNIX, che vengono ad esempio utilizzati in Wayland, Pipewire e pipewire-pulse. Nella release 1.12.0 la vulnerabilità è stata risolta solo parzialmente; pertanto, a caldo, è stato rilasciato l'aggiornamento 1.12.1.
Ricordiamo che lo sviluppo di applicazioni Flatpak offre la possibilità di semplificare la distribuzione dei propri programmi, che non rientrano nei repository ufficiali delle distribuzioni, preparando un unico contenitore universale senza dover creare build separate per ogni distribuzione. Per gli utenti attenti alla sicurezza, Flatpak consente di eseguire applicazioni sospette all'interno di un contenitore, fornendo accesso solo alle funzioni di rete e ai file dell'utente collegati all'applicazione. Per gli utenti interessati alle novità, Flatpak permette di installare le versioni più recenti di applicazioni sia in fase di test che stabili, senza necessità di modificare il sistema. Ad esempio, i pacchetti Flatpak vengono creati per LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, ecc.
Per ridurre la dimensione del pacchetto, include solo le dipendenze specifiche per l'applicazione, mentre le librerie di base di sistema e grafiche (GTK, Qt, librerie GNOME e KDE, ecc.) sono organizzate come ambienti runtime standard collegabili. La principale differenza tra Flatpak e Snap è che Snap utilizza componenti dell'ambiente di sistema principale e un'isolamento basato sulla filtrazione delle chiamate di sistema, mentre Flatpak crea un contenitore separato dal sistema e opera con grandi insiemi di runtime, fornendo come dipendenze non pacchetti, ma ambienti di sistema standard (ad esempio, tutte le librerie necessarie per l'esecuzione dei programmi GNOME o KDE).
Oltre all'ambiente di runtime standard (runtime), installato tramite un repository speciale, vengono fornite dipendenze aggiuntive (bundle) necessarie per il funzionamento dell'applicazione. Insieme, runtime e bundle costituiscono il contenuto del container, con la specifica che il runtime viene installato separatamente e può essere collegato a più container, evitando così la duplicazione di file di sistema comuni ai container. In un sistema possono essere installati diversi runtime (GNOME, KDE) o più versioni di uno stesso runtime (GNOME 3.40, GNOME 3.42). Un container con un'applicazione come dipendenza utilizza il collegamento solo a uno specifico runtime, senza prendere in considerazione i singoli pacchetti che compongono il runtime. Tutti gli elementi mancanti vengono confezionati direttamente con l'applicazione. Durante la creazione del container, il contenuto del runtime è montato come la partizione /usr, mentre il bundle è montato nella directory /app.
Il contenuto del runtime e dei container delle applicazioni è creato utilizzando la tecnologia OSTree, che consente di aggiornare in modo atomico un'immagine da un repository simile a Git, consentendo di applicare metodi di controllo delle versioni ai componenti della distribuzione (ad esempio, è possibile ripristinare rapidamente il sistema a uno stato precedente). I pacchetti RPM vengono tradotti nel repository OSTree tramite uno strato speciale chiamato rpm-ostree. L'installazione e l'aggiornamento di pacchetti all'interno dell'ambiente di lavoro non sono supportati; il sistema viene aggiornato non a livello di singoli componenti, ma completamente, cambiando in modo atomico il proprio stato. Sono fornuti strumenti per l'applicazione incrementale degli aggiornamenti, eliminando la necessità di una sostituzione completa dell'immagine ad ogni aggiornamento.
L'ambiente isolato creato è completamente indipendente dalla distribuzione utilizzata e, con le impostazioni appropriate del pacchetto, non ha accesso ai file e ai processi dell'utente o del sistema principale, non può accedere direttamente all'hardware, tranne che per l'output tramite DRI, e alle richieste al sottosistema di rete. L'output grafico e l'organizzazione dell'input vengono realizzati tramite il protocollo Wayland o attraverso il passaggio della socket X11. L'interazione con l'ambiente esterno è basata sul sistema di messaggistica DBus e su un'API speciale chiamata Portals.
Per l'isolamento si utilizza uno strato di Bubblewrap e le tradizionali tecnologie di virtualizzazione dei contenitori di Linux, basate sull'uso di cgroups, spazi dei nomi (namespaces), Seccomp e SELinux. Per l'uscita audio viene utilizzato PulseAudio. Tuttavia, l'isolamento può essere disattivato, cosa di cui approfittano gli sviluppatori di molti pacchetti popolari per ottenere accesso completo al file system e a tutti i dispositivi nel sistema. Ad esempio, i pacchetti GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity e VLC vengono forniti con una modalità di isolamento limitata, che consente un accesso completo alla home directory.
In caso di compromissione dei pacchetti con accesso alla home directory, nonostante la presenza nel descrittivo del pacchetto dell'etichetta "sandboxed", per l'attaccante è sufficiente modificare il file ~/ .bashrc per eseguire il proprio codice. Un'altra questione è il controllo delle modifiche ai pacchetti e la fiducia nei costruttori di pacchetti, che spesso non sono legati al progetto principale o alle distribuzioni.
Fonte: opennet.ru
