'Flatpak' Is The Universal Linux Packaging Format That Puts 'Security First'

Flatpak ArchitectureFlatpak ArchitectureRecently, Canonical announced its own universal app format called “snaps”. However, due to various issues with this format, it’s “flatpaks,” a community-designed format (led by a Red Hat developer) that may become the more popular standard thanks to its “security first” approach and significantly smaller app sizes.

Making Linux Apps Universal

The core technology behind “snaps” and "flatpaks" is roughly based on what’s known as “containers” in the Linux world, although their developers argue the formats are significantly different than "Docker-style" containers. The two formats bundle apps and their dependencies in a single package, so users could get the updates directly from developers rather than from the distro vendors, as is usually the case with Linux programs. The aim is to make Linux apps more universal across distros, but also to make them more secure.

“Application developers on Linux have always been prevented from having a direct relationship with their users. With Flatpak we're aiming to change that, so developers know exactly what their users are getting. With this launch we are making that goal a reality,” said Alexander Larsson, the lead developer behind the flatpak project.

The Limits Of “Snaps”

Snaps are currently tied to Canonical’s servers, the company's controversial CLA licensing, and its proprietary Mir display server, which will be used to display graphical applications on Ubuntu in the future. For a format that’s supposed to be universal, those are some rather significant limitations that may inhibit the spread of snaps to Ubuntu systems only.

Even if snaps start spreading to other Linux distros, unless they support the Mir display server, or unless Canonical decides to support Wayland, then snaps on other distros won’t benefit from strong security in the same way Mir-based snaps or Wayland-based flatpaks will. Wayland is a competing display server solution that’s being adopted by the vast majority of non-Ubuntu distros.

If Canonical does end up supporting Wayland for snaps, then it would have to support two competing display server standards. This would be highly redundant and a development cost Canonical may not be able to sustain. It would also send a mixed message to the Linux community about whether the company intends to keep Mir or not.

The Insecurity Of X11

Linux has a well known security issue due to the legacy X11 display server, because it allows apps (and attackers) to interact with other apps in a non-secure way. If Canonical doesn’t support Wayland for snaps, then all the snaps used on other non-Ubuntu systems will suffer from this X11 security issue. Flatpaks, on the other hand, will never have this issue, because they will support only Wayland-enabled systems.

Although the stable specification for a flatpak hasn’t been available for long, a group of popular Linux projects already support it, including LibreOffice, GIMP, InkScape, MyPaint, Darktable and a “large number of stock GNOME applications,” according to the developers behind the flatpak format. The GNOME runtime, as well as KDE, will support flatpaks wherever they are installed, and some distros will even offer built-in support.

“Until now, building a LibreOffice that works for every Linux user has involved some horrible compromises caused by the need to build our binaries on an ancient Linux version to get good forward compatibility. Flatpak will enable us (as a Linux ISV) to distribute a better LibreOffice, with up-to-date dependencies and a platform that can run on many systems. I'm excited to see that happen,” said Michael Meeks, Director of The Document Foundation.

Security Sandboxing

Unlike other “universal packaging formats,” including snaps, flatpaks make security an absolute priority. The apps inside flatpaks are isolated from the system, and they are given access only to a limited number of libraries and system interfaces.

Flatpaks will use Linux sandboxing technologies that already exist in most Linux distributions, so those dependencies won’t have to be bundled with the apps. Until the recent rise of containers, these sandboxing techniques hadn't been put to good use by the vast majority of Linux applications (with a few exceptions, such as Chrome).

Snaps could potentially achieve similar security benefits on Mir-enabled Ubuntu systems. However, because Canonical is currently promoting building snaps on X11, chances are that in practice, most snaps will keep using the insecure X11 display server for a long time, even after Mir arrives.

The One “Major” Disadvantage Of Flatpaks

One disadvantage of flatpaks could be that it needs the GNOME or KDE runtime, and potentially a few other components, so they can work on a given Linux distro. In essence, they are not as “universal” (as in working on as many Linux platforms by default) as snaps are.

However, in practice this may not turn out to be too much of a disadvantage, given that most distros already use those runtimes and the needed components, and others could be building support for flatpaks by default in the future. Worst case scenario, the user has to install these extra components once, and then all flatpaks will work.

This seems to have been a design decision, because by sharing certain main components, flatpaks file sizes can be significantly smaller than if they included all the needed dependencies in every package (the “snap” strategy).

Putting all dependencies in a package can lead to things such as including the Java virtual machine in every package that needs it. This can also lead to a security and update nightmare, if you have 20 different packages, each with a different version of Java.

An attacker would need only to exploit the package with the oldest Java version. That’s why the flatpak strategy seems like a more reasonable compromise, even if at first glance flatpaks seems “less universal” than snaps are (although likely won’t be in practice).

Making Linux Distros As Secure As Mobile Platforms

Flatpaks seem reasonably universal, much more than any other packaging format before it (that’s not based on containers); have small file sizes; support industry standards for containers; and seem to be designed from the ground up with security in mind. Therefore, if flatpaks become “the” universal standard for apps on Linux, they could significantly improve the platform’s security, leading to the level of security we typically see only on the heavily-sandboxed mobile platforms.

Lucian Armasu is a Contributing Writer for Tom's Hardware. You can follow him at @lucian_armasu. 

Follow us on FacebookGoogle+RSSTwitter and YouTube.

This thread is closed for comments
6 comments
    Your comment
  • cwayne18
    You're way off base about Snaps here. First of all, Snaps are in no way tied to Mir (in fact we've already seen Krita running on Wayland on Arch). Secondly, Mir is not proprietary, it's free and open source, and lastly, snaps aren't really tied to the Ubuntu store, users can sideload apps without ever touching the store, the store just adds some convenience.
  • mhall119
    None of these new packaging formats (Snap, Flatpak, AppImage, etc) have any dependency on the display server. Snaps will run on Wayland. Flatpaks will run on Mir. Both will and already do run on X11.

    Flatpaks are not limited to Wayland, and they will suffer the same security concerns when run on X11 as you mentioned. Nor is it's runtime confinement in place yet.
  • mhall119
    A few more corrections (sorry, I should have finished reading before commenting):

    Flatpaks can use a Gnome or KDE platform, but they don't have to. If an app wants to include all of it's dependencies, rather than say it needs one of those platforms installed, it can do that. Platforms are also provided via Flatpak, not by the distros themselves.

    However, I don't think that a flatpak can depend on more than one Platform at a time, so if your app needs Java *and* Gnome, you'll have to include one or the other in your app package.

    In any case, the attack surface for both Flatpak and Snap is limited by the runtime confinement, which largely negates the added risk that bundling dependencies cause.