Package: bubblewrap Version: 0.4.1-1 Severity: important Tags: security X-Debbugs-Cc: debian-kernel@lists.debian.org, t...@security.debian.org
bubblewrap can operate in two modes: - User namespace (Ubuntu, Fedora, RHEL >= 8): /usr/bin/bwrap is not setuid, and relies on having a kernel that allows unprivileged users without special capabilities in the initns to create new user namespaces, with the initial process in the new namespace having all capabilities. - setuid root (Debian <= 10, RHEL <= 7): /usr/bin/bwrap is setuid root (or setcap CAP_SYS_ADMIN, which is almost the same thing) and therefore does not rely on a kernel with that feature. According to https://bugs.debian.org/898446 the kernel team's plan is for Debian 11 defaults to behave like Ubuntu, Fedora and RHEL 8, so that bwrap does not need to be setuid any more. If this plan goes ahead, to reduce attack surface and prevent attacks similar to CVE-2020-5291, we should ensure that bwrap is not normally setuid in Debian 11 systems. Making bwrap unnecessarily setuid will also disable some of flatpak's features, which already breaks certain apps when installed via flatpak, notably Chromium (see #977758). However, some of the packages that rely on bwrap (such as flatpak and gnome-desktop3) have a non-technical user-base that should not be expected to understand which mode their kernel is in or manage sysctl values themselves. If bwrap doesn't work "out of the box", then we will get confused or angry bug reports against packages like flatpak; I don't really have the time or patience to provide detailed technical support for Debian 11's release lifetime, and I'm effectively the sole maintainer of flatpak and bubblewrap in Debian (co-maintainers welcome, by the way). So we will need to have some sort of transition plan in which flatpak continues to work. Because the transition freeze is soon, we should have a plan soon. Ideally, our transition plan should work even for users who have held back a buster kernel, at least in the short term. Here are some possibilities: sysctl configuration ==================== The simplest and most robust thing would be for bubblewrap to depend on procps, and ship a file /usr/lib/sysctl.d/50-bubblewrap.conf containing: kernel.unprivileged_userns_clone=1 together with a brief note about how you can copy that file into /etc/sysctl.d and edit the copy if this setting is undesired on a hardened system, and a reference to longer-form documentation in /usr/share/doc/bubblewrap, on the Debian wiki or on Salsa. This would mean that installing bullseye's bubblewrap.deb causes older kernel packages to get the more lax behaviour of newer kernel packages. Would the kernel and security teams consider this to be acceptable? If they would, then I think this is my preferred route. We should also patch bwrap so that when upstream bwrap would print an error message suggesting toggling kernel.unprivileged_userns_clone=1, Debian's bwrap instead prints a reference to our documentation. Split the package ================= Arch Linux has two bubblewrap packages: 'bubblewrap' is intended to be used with their default kernel, which has the Ubuntu/Fedora-style behaviour; 'bubblewrap-suid' is intended to be used with their non-default linux-hardened kernel, which has the Debian 10 behaviour (via the same patch, even). Each has a bwrap binary (functionally equivalent, I think) with appropriate 0755 or 04755 permissions. This relies on users installing the right bubblewrap package for their kernel, which seems to be a regular source of confusion even on Arch, which explicitly does not aim to support users who don't read the (extensive) documentation. I think we should aim higher than this in Debian. It might be possible to set up some sort of transitional package with something like this: bubblewrap Depends: bubblewrap-userns | bubblewrap-setuid, Recommends: linux-image (>= 5.10) | bubblewrap-setuid, but I don't see how to make that work without some versioned Provides in kernel packages, and it still won't do the right thing if users boot into an older kernel to work around a driver regression or similar. chmod at boot time ================== I hesitate to say this because I think writing to /usr would be horrible, but we could have an init script/systemd unit that chmods /usr/bin/bwrap 04755 or 0755 during boot, depending whether the running kernel appears to allow unprivileged creation of user namespaces. Presumably we'd want to skip this if there was a dpkg-statoverride configured for bwrap, to avoid trampling over sysadmin configuration. We probably shouldn't just move the bwrap binary into /var/lib, leaving a symlink behind, because that would cause any existing dpkg-statoverride on the bwrap binary to get applied to the symlink rather than the binary. A wrapper ========= I briefly looked into writing a /usr/bin/bwrap wrapper that would be setuid, detect whether its privileges were actually needed or not, drop privileges if they weren't needed, and exec the real bubblewrap (presumably moved to /usr/libexec/bwrap or similar). However, this still leaves a setuid binary in our overall system, which is attack surface that I'd rather not be responsible for. We'd also have to patch flatpak, which currently looks at whether /usr/bin/bwrap is setuid to decide whether it can advertise support for features that only work in the non-setuid bwrap (as required by the Flatpak version of Chromium). (your idea here) ================ Any other ideas? Thanks, smcv
