Local root vulnerability in snap-confine

The flatpak-system-helper is part of the distribution/installation layer of Flatpak rather than part of the sandboxing layer: it's the part that lets semi-privileged (but non-root-equivalent) users install an app or runtime system-wide, into /var/lib/flatpak. It's only about getting files into the right directories, and gets invoked when you install or upgrade an app, not when you run it.

The sandboxing layer of Flatpak *usually* (on modern distros) runs with the privileges of its caller, and can't do anything its caller couldn't already do on their own.

The exception to that is when the distro doesn't allow unprivileged users to create new user namespaces, for example Debian 10 and RHEL 7, in which case the bubblewrap executable (typically /usr/bin/bwrap or /usr/libexec/flatpak-bwrap) needs to be setuid root. I don't think it's coincidence that two out of four CVEs reported against bubblewrap have only been applicable when it's setuid root, and those two were the really serious ones. Setuid is dangerous and it's good to avoid it whenever possible (see also the recent pkexec vulnerability).

(CVE-2016-8659 and CVE-2020-5291 were root privilege escalation when setuid root, but were not applicable when not setuid root; CVE-2017-5226 wasn't really a vulnerability in bubblewrap at all, but more like a vulnerability in Flatpak and other bubblewrap users; CVE-2019-12439 only applied in unusual system configurations, and as far as I'm aware it was only a denial-of-service.)

Another reason why Snap needs root, but Flatpak usually does not, is that Snap uses an LSM (AppArmor) as part of its sandboxing but Flatpak does not.

As with the different scopes I described in my previous comment, this is a trade-off, and neither is trivially better than the other.

The fact that Snap uses AppArmor means it can rely on the LSM mechanism in the kernel, which is quite powerful, particularly if you are willing to patch the kernel (I believe Ubuntu's kernel patches to add SO_PEERSEC support to AppArmor still haven't gone upstream). If the kernel gives you information about a peer's LSM labels, then you can trust that information to be correct and securely obtained; and if a process is restricted by LSM policies, the kernel will forbid anything that those policies forbid, without needing to rely on other mechanisms like userns and seccomp as heavily as Flatpak does.

On the other hand, you need CAP_MAC_ADMIN (i.e. root) to manipulate AppArmor profiles, and if running on a distribution like Fedora that uses a different "big" LSM, or a distribution that doesn't compile any of the "big" LSMs into its kernel at all, then you're not going to be able to benefit from AppArmor at all.

Flatpak has gone for the approach that makes it work equally well on "most" distros, and give it an equal level of sandboxing on "most" distros even if installed as non-root. Snap has gone for the approach that is maximally powerful on e.g. Ubuntu, at the cost of working less well on non-Ubuntu and requiring root.