Is the Flatpak sandbox actually weak?

Questions
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.