A new stable branch of the Flatpak toolkit 1.12 has been released, providing a system for building self-contained packages that are not tied to specific Linux distributions and run in a special container, isolating 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. Flatpak packages are included in the Fedora repository and are supported in the default GNOME application management program. <\/p>\n
Key innovations in the Flatpak 1.12 branch: <\/p>\n
As a result, an attacker could bypass the sandbox isolation mechanism and gain full access to the host environment's contents by executing related mounting system calls. Exploitation of the vulnerability is only possible in packages that provide applications direct access to AF_UNIX sockets, which, for example, are used in Wayland, Pipewire, and pipewire-pulse. In release 1.12.0, the vulnerability was not completely fixed, so an update 1.12.1 was promptly released. <\/ul>\n
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. <\/p>\n
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). <\/p>\n
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. <\/p>\n
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. <\/p>\n
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. <\/p>\n
To ensure isolation, a Bubblewrap layer and traditional Linux container virtualization technologies are used, based on cgroups, namespaces, Seccomp, and SELinux. PulseAudio is utilized for sound output. However, isolation can be disabled, which developers of many popular packages exploit to gain full access to the filesystem and all devices in the system. For instance, packages like GIMP, VSCodium, PyCharm, Octave, Inkscape, Audacity, and VLC come with limited isolation mode that allows complete access to the home directory. <\/p>\n