[Pkg-utopia-maintainers] Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x

[Simon McVittie]

Package: bubblewrap
Version: 0.4.1-1
Severity: important
Tags: security
X-Debbugs-Cc: debian-kernel at lists.debian.org, team at 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