Introduction to Flatpak

A sandboxed app framework for Linux (formerly xdg-app)

Apps and runtimes

Fig.1. A stable flat-pack-based platform

Linux desktops: a moving target

• ISVs can't target “generic Linux” like they can target Windows, or OS X, or iOS, or Android

• Traditional answer: pick a baseline version from the distant past
  • Assume the most common libraries are installed
  • Bundle the rest (static linking or -rpath or LD_LIBRARY_PATH)

Bad for ISVs, and bad for us

• When we add a feature, ISVs don't get to use it for several years
  • Ensures they have “the platform problem”

Backports are a pain, too

• Some software moves (much) faster than Debian's release cycle

• -backports works, to a point, but…
  • backports have be in testing (suitable for the next release)
  • dependencies have to be in stable (old GTK)
  • or, dependencies have to be backported, and destabilise the platform layer (backport GTK and all of GNOME gets it)

Flatpak runtimes

• Basically a small /usr (with the /usr merge)
  • Anyone can publish a runtime
  • Set of libraries chosen by the runtime maintainer
  • Versions chosen by the runtime maintainer
  • Flatpak app doesn't see the real /usr
  • No development tools
  • No package manager
  • No init/boot/sysadmin layer

Flatpak runtimes

• Demo 1: Minetest

Flatpak SDKs

• A larger /usr, with developer tools
  • compiler
  • header files
  • static libraries
  • strace
• com.example.Sdk conventionally goes with com.example.Platform

Flatpak runtime versioning

• Each runtime has branches

• An app depends on a specific branch
  • org.gnome.gedit//stable depends on org.gnome.Platform//3.24

The long tail

• Not everything can be available in a runtime
  • unless we really want that?

App appears in /app

• Canonically, you recompile with --prefix=/app

• Do the same for bundled libraries

• The app does not need to be fully relocatable
  • Hard-coding /app in binaries is completely fine
  • Never relocated to /home/jsmith/local or similar

How apps and runtimes work

• libostree: like git, but for /usr

  ./config
  ./refs/heads/master
  ./refs/heads/stable
  ./refs/remotes/origin/master
  ./objects/3b/6f018809252480b740a48ea3cb746a434dd688
  ./objects/c0/837b81795498042a3570b792cb2f41da0a0551

How apps and runtimes work

• libostree: like git, but for /usr

  ./config
  ./refs/heads/app/org.debian.packages.openarena/x86_64/master
  ./refs/remotes/flatdeb/runtime/net.debian.flatpak.Games.Platform/x86_64/stretch
  ./objects/a1/443a265b155be7d190c5a0a5e99427716a0a1432f6994fbde40aafb23fb11e.file
  ./objects/e9/67eda76106efa124b736af20c14b3fea2a254b71927534bd869217e105c532.file

How apps and runtimes work

• Mount namespace
  • Mounts get isolated from the host system
  • The new root directory is a tmpfs
• Mount ${runtime}/files on /usr
  • that's why we need to do the /usr merge here
• Mount ${app}/files on /app

Sandboxing with bubblewrap

Fig.2. Protecting an important subject with bubble wrap

Why sandbox

• I trust this app's author enough to run it

Namespaces

• Recent Linux kernels offer lots of namespaces
  • user (uid)
  • process (pid)
  • mount table
  • network
  • IPC (SysV, etc.)
  • UTS (uname)
• Best case: we can just use them
  • unprivileged user namespaces

Namespaces

• User namespaces are scary
  • Unprivileged user gets capabilities in the userns
  • New improved Linux, now with extra attack surface!
  • e.g. CVE-2016-3135

Bubblewrap (bwrap)

• Small setuid helper
  • formerly Flatpak's xdg-app-helper
  • descended from linux-user-chroot
• Small subset of userns

Sandboxing

• Declarative capabilities
  • “uses X11”
  • “reads and writes ~/Downloads”
• Same general idea as Android permissions

Thinking with portals

Fig.3. Portals have safety implications if used carelessly

Thinking with portals

• Better than handing out permissions: get user consent when needed

Document portal

• Demo 2: GNOME Recipes

Document portal

• Looks like a normal dialog box

• Implicitly gets permission

• Selected file magically appears in a FUSE filesystem in the sandbox

How portals work

• Filtered access to host system's D-Bus session bus
  • Currently through a proxy
  • smcv is working on enhancing dbus-daemon to do this itself

Achieving world domination

Fig.4. IKEA would put the entire world in their warehouse if they could

Not everything is an “app”

… and that's OK

Not everything is an “app”

• CLIs and development tools

Curation and QA

Every package has a maintainer who is often an expert in the field of the package

— Raphaël Hertzog, State of the Debian-Ubuntu relationship

• At our best, we're domain experts on leaf packages (apps)

• Debian is a ready-made source of things that ought to be ready to be high-quality Flatpak apps

• We fix their bugs even if upstreams don't

Building runtimes

• Distributions are good at providing libraries

• Debian takes libraries very seriously

• Debian takes stability very seriously

• Debian takes security very seriously

• These are just what you want in a runtime

Distributions aren't perfect

• At our worst, we're just getting in the way

This doesn't need to be either/or

• Apps with good upstream maintenance can come from upstream

• Apps where we are genuinely helping can come from Debian

• We get some of the advantages either way

Some assembly required

Fig.5. A flat-pack stack ready for compilation

Using Debian for runtimes

• Demo 3: OpenArena

Using Debian for runtimes

Flatdeb:

• A prototype of building Flatpak runtimes with apt/dpkg

• Also a prototype of building Flatpak apps with apt/dpkg

Alternatives

Fig.6. Flat-pack technology is not suitable for all use cases

apt

• System-wide, root-privileged, non-atomic

• No sandboxing unless you specifically add it

• Good for: system services, the platform layer of desktop environments

• Good for: when upgrades are a big deal anyway
  • Debian stable
  • Ubuntu LTS

• Bad for: third-party software

libostree-based deployment

• Same packages as apt, but different trade-offs

• Atomic, whole-tree deployment
  • … but it does need a reboot

• Good for: appliance-style systems with known functionality

• Bad for: third-party software

• Good for: combining with Flatpak
  • hi Endless!

System-level containers

• Docker, systemd-nspawn and friends

• Good for: servers without extensive host OS requirements
  • or no host OS at all — “application containers”

• Good for: development and debugging

• Bad for: stopping container-root becoming real root

• Bad for: desktop integration

Virtualization

• An entire other OS, including the kernel

• Good for: servers, “appliances”

• Good for: code you want to keep at arm's length

• Bad for: maximal efficiency

• Bad for: desktop integration

Snap

• Relocatable sandboxed apps
  • Not just desktop, not just unprivileged
  • Libraries bundled (can be shared) or assumed present

• Application code needs to be relocatable

• Sandboxed (sometimes)

• Good for: Ubuntu kernels

• Bad for: mainstream kernels

AppImage

• App is a wrapped filesystem image that can be made executable and run

• Dependencies must be either bundled or assumed

• Good for: Windows- and Mac-like UX - just download and run

• Bad for: getting updates

• Bad for: avoiding the moving target problem

• Bad for: deduplication

Firejail

• Setuid program to set up sandboxes, like bubblewrap

• Uses the same technologies as bubblewrap

• Much more general and configurable than bubblewrap
  • Much more attack surface than bubblewrap

• Good for: AppImage integration

• Good for: users who are already root-equivalent anyway

• Bad for: users who should not become root-equivalent

Questions?

Slides, source code and flatdeb: https://flatpak.debian.net/