Opening a thread here to follow up on discussions at GUADEC with @matthiasc @alexl @jamesh @kenvandine @chergert @hadess Olivier Tilloy, myself and whoever else I was able to corner. For context, at present Flatpak totally blocks the syscalls necessary to set up your own filesystem/user namespace (see https://github.com/flatpak/flatpak/blob/master/common/flatpak-run.c#L2476-L2480) and necessarily blocks setuid binaries.
Chromium’s sandboxing relies on either being able to directly open a user namespace (ie the system has unprivileged user namespaces enabled) or relying on its setuid helper to do so. In the case both of these fail, Chromium errors out, which has precluded running Chromium inside a Flatpak for the time being, without patching out the sandbox code, which seems deeply irresponsible, or passing
--disable-sandbox which earns you a very scary warning.
It seems recently that Electron has either updated to a newer Chromium or changed their build defaults, which means that various third-party Electron apps are starting to fail to run inside Flatpak too. This is sad.
Although I have not read the code, speaking with @jamesh and @kenvandine it seems that snapd has a special consideration for browsers, based off a whitelist or a rarely-given privilege, that trusts them to create user namespaces. It wasn’t clear how Electron apps avoid the same fate, given they don’t possess this privilege, but (conjecture) Electron builder itself has a mode where it outputs snaps, so perhaps this also disables the sandboxing.
Similarly, we also have the oddly-inverted situation that certain operations (eg thumbnailing, see https://gitlab.gnome.org/GNOME/gnome-desktop/blob/master/libgnome-desktop/gnome-desktop-thumbnail-script.c#L766-770) which should/could be very heavily sandboxed are run with no additional confinement when they are executed in a Flatpak (and presumably snap?) context.
@refi64 has a proof-of-concept patch to Chromium which shells out to
flatpak-spawn at the time it would otherwise call the setuid sandbox helper, but it strikes me that this Flatpak-specific approach is the wrong way to do it and isn’t likely to be upstream-able, so it also wouldn’t make it very far through the Electron ecosystem either.
I think if we work on a shared sandboxing portal API which both Flatpak and snapd can implement, we can remove any special-casing for browsers and make a consistent/united case towards toolkit and app developers about how stricter sandboxing should be accessed for confined apps, improving security and our chances of getting one “golden” (ie works everywhere) patch upstream.
My plan would be something like:
- Discuss the Flatpak sandboxing API and how it could be made generic to work with snapd as well (see https://github.com/flatpak/flatpak/blob/master/data/org.freedesktop.portal.Flatpak.xml)
- Implement the agreed API all round
- Re-implement our Chromium patch in terms of calling the portal API over D-Bus and submit upstream
- Submit to Electron in parallel if that lets us stop breakage sooner
- Push towards using that API in Firefox as well
- Drop browser hacks all round
- Add a “sandbox spawn” API to Glib that could use this or fallback to eg bwrap/seccomp when run on a Linux system (other platforms may be available)
- Celebrate improved desktop security