Bug#998676: RM: chromium/93.0.4577.82-1
On Sat, 06 Nov 2021 at 08:03:49 +0100, Salvatore Bonaccorso wrote:
> Within the security team we are considering to announce the end of
> security support for chromium for buster and bullseye. People can e.g.
> transition to using Chromium from Flathub.
Note that the version of Chromium on Flathub requires:
* Flatpak >= 1.8.2 (buster-backports or bullseye is suitable, buster is not)
* a kernel configured for unprivileged user namespaces (bullseye is
suitable by default, buster is not, and I'm not sure about buster-backports)
* a non-setuid bubblewrap executable (bullseye is suitable,
buster is not, buster-backports is currently not suitable but could
be made suitable if the security team are OK with that)
The same is true for various Chrome-, Chromium-, CEF- and Electron-based
Flatpak apps.
For Flatpak, I think the only way we are likely to get a suitable version
in buster would be to copy version 1.10.x from buster-backports into buster.
This currently also requires a backport of libseccomp in order to avoid
becoming vulnerable to CVE-2021-41133 via a backported bullseye kernel,
although it would presumably be possible to do a targeted backport
of knowledge of the clone3() syscall into buster's libseccomp as a
stable-update.
For bubblewrap and unprivileged user namespaces, if necessary the
bubblewrap package could drop in a sysctl.d snippet to open up access
to unprivileged user namespaces while it is installed (as the version
in bullseye does, in order to provide a migration path from buster).
This is a tradeoff between kernel attack surface and ability to do
user-space sandboxing, as discussed on #898446.
I think that if we are going to encourage use of Flatpak apps for
things like browsers, we will probably have to be prepared to do more
major-version backporting of things in the Flatpak ecosystem (Flatpak,
bubblewrap, libostree, libseccomp, and maybe also xdg-desktop-portal
and xdg-desktop-portal-*) into oldstable, and maybe also stable. All
of these components are designed to have conservative dependencies
outside their "bubble" (for example they go to considerable lengths to
be compatible with old GLib and libsoup), so it is possible to backport
them surprisingly far, and for example Flatpak upstream[1] are still
maintaining a PPA for Ubuntu 16.04 with the latest 1.12.x stable releases;
but if major applications require newer functionality, we can't magic
that into existence in older Flatpak and xdg-desktop-portal branches.
I'm doing my best to keep all this working and secure across multiple
Debian suites, but there's a limit to what I can do, particularly while
constrained to make minimal changes.
smcv
[1] in practice this is also me, with some help from Alexander Larsson
Reply to: