A new stable branch of the Flatpak 1.12 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.12 branch:
- Improved management of nested sandbox environments used in the flatpak package with the client for the Steam game delivery service. In nested sandboxes, the creation of separate hierarchies of the /usr and /app directories is allowed, which is used in Steam to launch games in a separate container with its own /usr partition, isolated from the environment with the Steam client.
- All package instances with the same application identifier (app-ID) share the /tmp and $XDG_RUNTIME_DIR directories. Optionally, using the β--allow=per-app-dev-shmβ flag, you can enable the use of the /dev/shm shared directory.
- Improved support for Text User Interface (TUI) applications such as gdb.
- A faster implementation of the βostree pruneβ command has been added to the build-update-repo utility, optimized for working with repositories in archive mode.
- The vulnerability CVE-2021-41133 in the implementation of the portal mechanism, associated with the lack of blocking of new system calls related to mounting partitions in the seccomp rules, has been fixed. The vulnerability allowed the application to create a nested sandbox to bypass the βportalβ verification mechanisms that are used to organize access to resources outside the container.
As a result, an attacker, by performing mounting-related system calls, could bypass the sandbox isolation mechanism and gain full access to the contents of the host environment. The vulnerability can only be exploited in packages that provide applications with direct access to AF_UNIX sockets, such as those used by Wayland, Pipewire, and pipewire-pulse. In release 1.12.0, the vulnerability was not completely eliminated, so update 1.12.1 was released hot on its heels.
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 are used, based on the use of cgroups, namespaces, Seccomp and SELinux. 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 file system and all devices in the system. For example, GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, and VLC 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 of changes to packages and trust in package builders, who are often not associated with the main project or distributions.
Source: opennet.ru