Is the Flatpak sandbox actually weak?

Questions
1

While browsing this forum and other similar communities, I have often come across claims that the Flatpak sandbox is weak. However, this is usually not followed up with an explanation of how or why it is weak.

I am speaking only about the sandbox between the host and the application, not about the application’s ability to provide its own sandboxes (e.g. site isolation). Also, I am only referring to the sandbox in its default state (no added permissions) or the state of some applications that I will provide as examples. The reason that I am clarifying this is because the only decently detailed explanation of potential sandbox weakness that I have seen relies on the poor default permissions of popular applications (https://hanako.codeberg.page).

I am wondering if there are other resources that outline actual sandbox weaknesses in Flatpak’s architecture or with any of the permissions enabled in the following applications:

flatpak info --show-permissions org.mozilla.firefox
[Context]
shared=network;
sockets=wayland;pulseaudio;
filesystems=
persistent=.mozilla;

[Environment]
DICPATH=/usr/share/hunspell

flatpak info --show-permissions org.kde.haruna
[Context]
sockets=wayland;pulseaudio;
devices=dri;
filesystems=xdg-config/kdeglobals:ro;

flatpak info --show-permissions com.github.wwmm.easyeffects 
[Context]
sockets=wayland;
devices=dri;
filesystems=xdg-run/pipewire-0:ro;

[Environment]
LADSPA_PATH=/app/lib/ladspa
LV2_PATH=/app/lib/lv2:/app/extensions/Plugins/lv2

All of these applications work exactly as intended (as far as I can tell in daily use) with the permissions outlined above.

This is on Fedora 42 KDE if that is useful information.

2

Its likely best to ask this on the Fedora forum for clarification in the details.

3

I do not think so. I only added that extra information in case it was relevant to some niche effect my distro has on those specific permissions. But Flatpak is not a Fedora project, and those permissions are not specific to Fedora (both in that they are from my overrides on the flathub.org packages, and that these permissions are ubiquitously needed across distros).

The main premise of the post is whether there are resources outlining and explaining Flatpak sandbox weaknesses.

I have also looked at the Sandboxing Applications on Desktop Linux community wiki. It also just lists things without explaining how they could lead to sandbox escape:

We generally recommend revoking access to:

  • the Network (share=network) socket (internet access)
  • the PulseAudio socket (for both audio in and out), device=all (access to all devices including the camera)
  • org.freedesktop.secrets dbus (access to secrets stored on your keychain) for applications which do not need it

It also links to a resource that is blatantly inaccurate both when it was written and even more so now: Linux | Madaidan's Insecurities. Focusing on the last paragraph:

Further examples include Flatpak giving complete access to directories such as /sys or /proc (kernel interfaces known for information leaks), rather than allowing fine-grained access to only the required files, and the highly permissive seccomp filter which only blacklists ~20 syscalls and still exposes significant kernel attack surface.

It links to an old version of flatpak-run.c. But looking at the code highlighted:

  if ((flags & FLATPAK_RUN_FLAG_NO_PROC) == 0)
    flatpak_bwrap_add_args (bwrap,
                            "--proc", "/proc",
                            NULL);

  if (!(flags & FLATPAK_RUN_FLAG_PARENT_SHARE_PIDS))
    flatpak_bwrap_add_arg (bwrap, "--unshare-pid");

  flatpak_bwrap_add_args (bwrap,
                          "--dir", "/tmp",
                          "--dir", "/var/tmp",
                          "--dir", "/run/host",
                          "--dir", run_dir,
                          "--setenv", "XDG_RUNTIME_DIR", run_dir,
                          "--symlink", "../run", "/var/run",
                          "--ro-bind", "/sys/block", "/sys/block",
                          "--ro-bind", "/sys/bus", "/sys/bus",
                          "--ro-bind", "/sys/class", "/sys/class",
                          "--ro-bind", "/sys/dev", "/sys/dev",
                          "--ro-bind", "/sys/devices", "/sys/devices",
                          "--ro-bind-try", "/proc/self/ns/user", "/run/.userns",
                          /* glib uses this like /etc/timezone */
                          "--symlink", "/etc/timezone", "/var/db/zoneinfo",
                          NULL);

and man bwrap:

       --proc DEST
           Mount procfs on DEST

show that its not access to /proc, but simply mounting the sandbox’s procfs at /proc in the sandbox.

And the read-only binds to /sys are no longer in the main branch: current binds.

The criticism of the seccomp filters was also unspecific, and provides no example syscall that should be blocked to prevent escape. They have also been updated to include more filters since then: current seccomp filters.

Sorry if that should have been a separate post, but I figured I should address it before someone links it as a solution.

4

I’m really looking forward to this discussion.

I was wondering why ppl say that flatpaks aren’t supposed to be used because of its weak sandboxing but it’s required to be used on secureblue/silverblue, that is supposed to be asecured Linux distro.

For me it doesn’t make much sense but I’ll confess that I didn’t make much research on the topic. I only can quote what RKNF404 said in his repo Chromium Hardening Guide

As mentioned in the Brave section, AVOID! Flatpak’s security is… questionable for a number of reasons, but what’s worse is chromium’s security in Flatpak. Because Flatpak restricts the usage of Linux namespaces and prevents the use of SUID (for good reason), chromium’s sandbox will literally not work. The solution is zypak or a direct patch, the problem is these methods are very poorly configured to the point they essentially break the typically very strong sandboxing chromium provides. These solutions are closer to compatibility layers than they are genuine security solutions. Upstream (chromium devs) have expressed they do no intend to support Flatpak anytime soon for reasons alike to this. Flatpak significantly inhibits chromium’s sandboxing, and there is no faithful implementation currently.

5

AFAIK Flatpak only weakens the sandboxing of (Chromium and Firefox based) web browsers. I haven’t seen anyone argue that Flatpak shouldn’t be used for other applications due to security reasons.

4 Likes
6

Fair enough. Like I said, I didn’t make much research on it.

Edit:

I found a warning on the Arch Wiki about this too

Arch Wiki Source

Warning:
Many Flatpak applications available on flathub are not effectively sandboxed by default [1]. Do not rely on the provided process isolation without first reviewing the related flatpak permission manifest for common sandbox escape issues.
Running untrusted code is never safe; sandboxing cannot change this.

And Flatpak is not a sandbox

The myth that flatpak apps provide a sandboxed environment is an illusion. Flatpaks are containerized applications that provide limited isolation by default and should be described as such.

7

Most of the concerns are due to applications being able to declare their own constraints and defaulting to bad presets, and not the actual separation between the host and the application. You can use flatseal to improve flatpak isolation.

2 Likes
8

When I used linux I found a few apps that wouldn’t work without outrageous permisions (home directory), I guess since so much of it is optional some developers just don’t take flatpak sandboxing into account when creating their apps, something you can’t do when making android apps for example.

9

Network access allows access to abstract sockets. For example to X11/Xwayland and dbus abstract sockets. Haven’t checked, if Xwayland in Gnome/KDE currently uses abstract sockets for Xwayland or if you would need to completely remove Xwayland. Don’t know if there is a specific solution to dbus abstract sockets. A general solution to remove access to abstract sockets could be to use a separate network namespace.

DRI used to be a problem for sandboxes. Don’t know, if this is still the case. Chromium considers RCE in the GPU process available through a renderer process a sandbox escape.

Gives unrestricted access to microphone and sound, even outside the sandbox.