A new stable branch of the Flatpak toolkit 1.14 has been released. This toolkit provides 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. Flatpak package execution is supported for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux, and Ubuntu. Flatpak packages are included in the Fedora repository and are supported in the standard GNOME application management program.
Key innovations in the Flatpak 1.14 branch:
- Support for creating a directory for files in the state (.local/state) and setting the environment variable XDG_STATE_HOME to point to this directory.
- Conditional checks like "have-kernel-module-name" have been added to determine the presence of kernel modules (a universal alternative to the previously suggested check have-intel-gpu, which can now be replaced with the expression "have-kernel-module-i915").
- Implemented the command "flatpak document-unexport --doc-id=…".
- Export of Appstream metadata for use in the main environment has been provided.
- Autocompletion rules for flatpak commands have been added to the Fish shell.
- Network access to X11 and PulseAudio services has been enabled (with the addition of the corresponding settings).
- The main branch in the Git repository has been renamed from "master" to "main", as the term "master" has recently been considered politically incorrect.
- Support for rewriting launch scripts in case of application renaming has been provided.
- The install command has been updated with options "--include-sdk" and "--include-debug" for installing SDK and debuginfo files.
- Support for the parameter "DeploySideloadCollectionID" has been added to flatpakref and flatpakrepo files, which will set the collection ID when adding a remote repository, rather than after downloading the metadata.
- Support for creating nested sandbox environments for handlers in sessions with separate MPRIS (Media Player Remote Interfacing Specification) names has been enabled.
- Command-line utilities now provide information about the usage of deprecated runtime extensions.
- A confirmation prompt before removing runtime or runtime extensions that are still in use has been implemented in the uninstall command.
- Support for the option "--socket=gpg-agent" has been added to commands like "flatpak run".
- A vulnerability has been fixed in libostree that could potentially allow a user to delete arbitrary files in the system through manipulation of the flatpak-system-helper handler (by sending a delete request with a specially formatted branch name). This issue only affects older versions of Flatpak and libostree released before 2018 (< 0.10.2) and does not impact current releases.
It is worth noting that Flatpak allows application developers to simplify the distribution of their software, which is not included in the standard repositories of distributions, by preparing a single universal container without creating separate builds for each distribution. For users concerned about security, Flatpak allows running potentially dubious applications in a container, providing access only to the network functions and user files related to the application. For users interested in new features, Flatpak allows the installation of the latest test and stable releases of applications without requiring changes to the system. For example, Flatpak packages are built for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 A.D., Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
To reduce the package size, it includes only application-specific dependencies, while the basic system and graphic libraries (GTK, Qt, GNOME and KDE libraries, etc.) are provided as reusable standard runtime environments. The key difference between Flatpak and Snap is that Snap uses components of the base system's environment and isolation based on filtering system calls, whereas Flatpak creates a container separate from the system and operates with large runtime sets, providing not packages as dependencies but standard system environments (for example, all libraries needed for GNOME or KDE applications).
In addition to the standard runtime environment, which is installed through a special repository, additional dependencies required for the application's operation are supplied as a bundle. Together, the runtime and bundle form the contents of the container, with the runtime being installed separately and linked to multiple containers. This approach avoids duplicating shared system files across containers. Multiple different runtimes (GNOME, KDE) or several versions of the same runtime (GNOME 3.40, GNOME 3.42) can be installed on a single system. A container with the application as a dependency uses a link only to a specific runtime, disregarding the individual packages that make up the runtime. All missing components are bundled directly with the application. When creating the container, the contents of the runtime are mounted as the /usr partition, while the bundle is mounted in the /app directory.
The runtime and application container contents are formed using OSTree technology, in which 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 through a special layer called rpm-ostree. Separate installation and update of packages within the working environment is not supported; the system updates as a whole, atomically changing its state. Tools are provided for incrementally applying updates, eliminating the need for a complete image replacement with each update.
The formed isolated environment is completely independent of the distribution in use and, with the proper package configurations, has no access to user files or processes of the main system. It cannot directly access hardware, except for output through DRI and requests to the network subsystem. Graphics output and input organization are implemented using the Wayland protocol or through X11 socket forwarding. Interaction with the external environment is based on the DBus messaging system and a special API called Portals.
Bubblewrap is used for isolation along with traditional Linux container virtualization technologies based on cgroups, namespaces, Seccomp, and SELinux. For audio output, PulseAudio is utilized. Isolation can be disabled, which many developers of popular packages use to gain full access to the filesystem and all devices in the system. For example, packages like GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, and VLC come with a restricted isolation mode that leaves full access to the home directory. In the event of compromised packages with access to the home directory, despite the package description showing a 'sandboxed' label, an attacker can execute their code simply by modifying the file ~/.bashrc. A separate concern is the control over modifications made to packages and the trust in package maintainers, who are often not affiliated with the main project or distributions.
Source: opennet.ru
