After two and a half years of development, a new stable branch of the Flatpak toolkit 1.16 has been released, providing a system for building self-contained packages that are independent of specific Linux distributions and run in a special container that isolates the application from the rest of the system. Support for running Flatpak packages is available for Fedora, CentOS, Debian, Arch Linux, Gentoo, Linux Mint, Alt Linux, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the default application management programs GNOME and KDE.
Key innovations in the Flatpak 1.16 branch:
- Transition to the Meson build system has been made. Support for building with the Autotools toolkit is discontinued. Now, building Flatpak requires Python to be installed in the system, version 3.5 or higher.
- Shared access to the gssproxy socket has been implemented, allowing for Kerberos authentication in applications running in sandbox isolation mode.
- When creating a socket for Wayland, the security-context extension is used, through which the compositor server can identify and restrict applications running in sandbox isolation mode. An option ‘—socket=inherit-wayland-socket’ has been added to inherit the existing socket for Wayland.
- After installing or updating applications, the configuration of the D-Bus session bus is automatically reloaded to capture new D-Bus services exported by the applications.
- Distributions are provided with the capability to define repositories with Flatpak packages using the directory ‘/usr/share/flatpak/remotes.d’, in addition to ‘/etc/flatpak/remotes.d.’
- Work has been done to split large source code files into smaller modules.
- An option ‘—device=input’ has been added for accessing input devices through /dev/input.
- A new branch of the bubblewrap 0.11 toolkit has been employed for application isolation. Distributions building Flatpak using the system executable bwrap must have at least version bubblewrap 0.11. Protection against creating nested user namespaces in sandbox environments has been enhanced.
- The configuration of additional languages has been simplified. Language definitions are ensured based on user information provided by the DBus service AccountsService.
- Applications using nested sandbox isolation, such as those based on the WebKit engine, are allowed to use the AT-SPI protocol to interact with screen readers. The option "flatpak run —a11y-own-name" has been added to select the bus through which access to accessibility tools is provided.
- When executing the command "flatpak run -vv ", all applicable sandbox isolation parameters are displayed.
- The option "—device=usb" has been added, as well as the parameters "—usb" and "—no-usb" for controlling the application’s access to USB devices.
- Support for the KCompletion framework has been added, which is used for autocompleting search keywords in KDE.
- Environment variables "FLATPAK_DATA_DIR" and "FLATPAK_DOWNLOAD_TMPDIR" have been added to override the directories for data (\/usr\/share\/flatpak) and temporary downloaded files (\/var\/tmp).
- Escape sequences output has been added to display progress during operations in terminal emulators.
It is worth noting that Flatpak simplifies the distribution of applications not included in the standard distribution repositories by preparing a single universal container, freeing developers from the need to create separate builds for each distribution. For security-conscious users, Flatpak allows running potentially questionable applications in a container, providing selective access only to necessary network functions and user files. For users interested in novelties, Flatpak allows installing the latest testing and stable releases of applications without the need to make changes to the system. For example, Flatpak packages are built for LibreOffice, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Telegram Desktop, Android Studio, etc.
To reduce size, the package includes only application-specific dependencies. Basic system and graphical libraries (GTK, Qt, GNOME and KDE libraries, etc.) are provided as plug-in standard runtime environments. The key difference between Flatpak and Snap is that Snap uses the main system environment components and isolation based on filtering system calls, while Flatpak creates a separate container from the system and operates large runtime sets, providing not packages as dependencies but standard system environments (for example, all the libraries needed for GNOME or KDE applications).
In addition to the standard system environment (runtime) installed via a special repository, additional dependencies (bundle) required for the application to work are provided. Together, the 'runtime' and 'bundle' form the container's core, with 'runtime' installed separately and bound to multiple containers, thus avoiding duplication of common system files across containers.
Multiple different 'runtime' environments (GNOME, KDE) or several versions of the same 'runtime' (GNOME 46, GNOME 47) can be installed on one system. A container with an application as a dependency binds only to a specific 'runtime', ignoring the individual packages that form the chosen 'runtime'. All missing elements are packaged directly with the application. When creating a container, the contents of the 'runtime' are mounted as the /usr partition, while the 'bundle' is mounted in the /app directory.
The core of the 'runtime' and application containers is formed using OSTree technology, where the image is atomically updated from a Git-like repository, allowing version control methods to be applied to distribution components (for example, the system can be quickly rolled back to a previous state). RPM packages are translated into the OSTree repository using the rpm-ostree layer.
Selective installation and updating of packages within the working environment is not supported—the system is updated not at the level of individual components, but as a whole, atomically changing its state. Tools are provided for the incremental application of updates, eliminating the need for a complete image replacement with each update.
The isolated environment formed is completely independent of the distribution used and, with proper package settings, has no access to user files and processes of the main system, nor can it directly interact with hardware, except through DRI output. Graphics output and input organization are implemented using the Wayland protocol or via socket forwarding with X11. Interaction with the external environment is established through the DBus messaging system and a special API for Portals.
For isolation, Bubblewrap and traditional Linux container virtualization technologies are used, based on cgroups, namespaces, Seccomp, and SELinux. PulseAudio or PipeWire is used for sound output. When creating a package, isolation can be disabled, which many developers of popular packages utilize to gain full access to the filesystem and all devices in the system.
For example, packages such as GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, and VLC come with a limited isolation mode that allows full access to the home directory. In the event of package compromise with access to the home directory, despite the package description bearing the 'sandboxed' label, the attacker can execute their code simply by modifying the file ~/ .bashrc. A separate issue is controlling changes to packages and trusting package builders, who are often not associated with the main project or distributions.
Source: opennet.ru
