Local root vulnerability in snap-confine [LWN.net]

Local root vulnerability in snap-confine

Posted Feb 18, 2022 21:06 UTC (Fri) by Smon (guest, #104795)
Parent article: Local root vulnerability in snap-confine

I enjoyed reading the report. Thank you!

Flatpaks bwrap is able to run as non root and use user-namespacing. So this cannot happen there.
Why does snap need a suid binary?

to post comments

Local root vulnerability in snap-confine

Posted Feb 18, 2022 21:57 UTC (Fri) by walters (subscriber, #7396) [Link] (1 responses)

I only glanced at https://github.com/snapcore/snapd/tree/61b66aaa1beb861f30... and there's a lot going on there, but...I think the flatpak equivalent of part of this is https://github.com/flatpak/flatpak/blob/main/system-helpe... which runs as a DBus service, not a suid binary.

Local root vulnerability in snap-confine

Posted Feb 20, 2022 12:54 UTC (Sun) by smcv (subscriber, #53363) [Link]

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

Local root vulnerability in snap-confine

Posted Feb 20, 2022 12:38 UTC (Sun) by smcv (subscriber, #53363) [Link] (2 responses)

Flatpak is designed for a narrower use-case than Snap, so it's willing to accept more restrictions on what it can do, and doesn't need to be as "powerful" as Snap. On one hand, this makes Snap useful in situations where Flatpak isn't; on the other hand, this means Flatpak developers can focus on the situations that it supports, and ignore the situations it doesn't.

In particular, when Flatpak developers encounter something that would be hard to implement securely, we are often able to declare it to be out-of-scope and not implement it at all, resulting in fewer attack vectors.

Flatpak is designed to sandbox "apps", with a meaning that is not 100% well-defined, but "programs that behave like an Android/iOS app" or "GUI programs with a .desktop file" are reasonable approximations. Snap is designed to sandbox "apps", but also non-"app" things like system services: you can install lxd as a Snap, but it would not be possible to install lxd as a Flatpak app.

I personally think that's a strength of Flatpak rather than a weakness, but it would be reasonable for Snap users/developers to disagree on that: neither approach is trivially better than the other.

Local root vulnerability in snap-confine

Posted Feb 20, 2022 13:11 UTC (Sun) by smcv (subscriber, #53363) [Link] (1 responses)

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.

Local root vulnerability in snap-confine

Posted Feb 21, 2022 23:32 UTC (Mon) by Smon (guest, #104795) [Link]

@smcv: Thank you very much for your detailed insight. It was really interesting to me!