A new stable branch of the Flatpak 1.14 toolkit has been published, which provides a system for building self-contained packages that are not tied to 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 provided for Arch Linux, CentOS, Debian, Fedora, Gentoo, Mageia, Linux Mint, Alt Linux and Ubuntu. The Flatpak packages are included in the Fedora repository and are maintained in the native GNOME Application Manager.
Key innovations in the Flatpak 1.14 branch:
- Created a directory for files in the state (.local/state) and set the XDG_STATE_HOME environment variable pointing to this directory.
- Added conditional checks of the form "have-kernel-module-name" to determine the presence of kernel modules (a universal analogue of the previously proposed check have-intel-gpu, instead of which the expression "have-kernel-module-i915" can now be used).
- Implemented "flatpak document-unexport --doc-id=..." command.
- Provided export of Appstream metadata for use in the main environment.
- Added flatpak command completion rules for the Fish shell
- Allowed network access to X11 and PulseAudio services (if appropriate settings are added).
- The main branch in the Git repository has been renamed from "master" to "main", as the word "master" has been considered politically incorrect lately.
- Provided rewriting of startup scripts in case of application renaming.
- Added "--include-sdk" and "--include-debug" options to install command to install SDK and debuginfo files.
- Support for the "DeploySideloadCollectionID" parameter has been added to the flatpakref and flatpakrepo files, when set, the collection ID will be set during the addition of the remote repository, and not after the metadata is loaded.
- It is allowed to create nested sandbox environments for handlers in sessions with separate names MPRIS (Media Player Remote Interfacing Specification).
- Command-line utilities display information about the use of obsolete runtime extensions.
- The uninstall command implements a confirmation request before removing runtime or runtime extensions that are still in use.
- Added support for "--socket=gpg-agent" option to commands like "flatpak run".
- A vulnerability has been fixed in libostree that could potentially allow a user to delete arbitrary files on the system through manipulation of the flatpak-system-helper handler (sending a delete request with a specially formatted branch name). The issue only occurs in older versions of Flatpak and libostree released prior to 2018 (< 0.10.2) and does not affect current releases.
Recall that Flatpak makes it possible for application developers to simplify the distribution of their programs that are not included in the regular distribution repositories by preparing one universal container without creating separate assemblies for each distribution. For security conscious users, Flatpak allows a questionable application to run in a container, giving access only to the network functions and user files associated with the application. For users who are interested in what's new, Flatpak allows you to install the latest test and stable releases of applications without having to make changes to the system. For example, Flatpak packages are built for LibreOffice, Midori, GIMP, Inkscape, Kdenlive, Steam, 0 AD, Visual Studio Code, VLC, Slack, Skype, Telegram Desktop, Android Studio, etc.
To reduce the size of the package, it includes only application-specific dependencies, and the basic system and graphic libraries (GTK, Qt, GNOME and KDE libraries, etc.) are designed as pluggable typical runtime environments. The key difference between Flatpak and Snap is that Snap uses the components of the main system environment and isolation based on system call filtering, while Flatpak creates a container separate from the system and operates with large runtime sets, providing typical packages rather than packages as dependencies. system environments (for example, all libraries required for running GNOME or KDE programs).
In addition to the typical system environment (runtime) installed through a special repository, additional dependencies (bundle) required for the application to work are supplied. In total, runtime and bundle form the stuffing of the container, while runtime is installed separately and tied to several containers at once, which makes it possible to avoid duplicating system files common to containers. One system can have several different runtimes installed (GNOME, KDE) or several versions of the same runtime (GNOME 3.40, GNOME 3.42). A container with an application as a dependency uses binding only to a specific runtime, without taking into account the individual packages that make up the runtime. All missing items are packaged directly with the application. When the container is formed, the contents of the runtime are mounted as the /usr partition, and the bundle is mounted in the /app directory.
The filling of the runtime and application containers is formed using OSTree technology, in which the image is atomically updated from a Git-like storage, which allows you to apply version control methods to distribution components (for example, you can quickly roll back the system to the previous state). RPM packages are translated into the OSTree repository using a special rpm-ostree layer. Separate installation and updating of packages inside 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 to apply updates incrementally, eliminating the need to completely replace the image with each update.
The generated isolated environment is completely independent of the distribution kit used and, with proper package settings, does not have access to files and processes of the user or the main system, cannot directly access the equipment, except for output via DRI, and accesses 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 built on the basis of the DBus messaging system and the special Portals API.
For isolation, the Bubblewrap layer and traditional Linux container virtualization technologies based on the use of cgroups, namespaces (namespaces), Seccomp and SELinux are used. PulseAudio is used to output sound. In this case, isolation can be disabled, which is used by the developers of many popular packages to gain full access to the FS and all devices in the system. For example, the GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, and VLC packages come with a limited isolation mode that leaves full access to the home directory. If packages with access to the home directory are compromised, despite the presence of the βsandboxedβ label in the package description, the attacker only needs to change the ~/.bashrc file to execute his code. A separate issue is the control over changes to packages and the trust in package builders, who are often not associated with the main project or distributions.
Source: opennet.ru