Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #68955 > unrolled thread

Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x

Back to article view | Back to linux.debian.kernel

Contents

  Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x Simon McVittie <smcv@debian.org> - 2020-12-21 20:00 +0100
    Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x Moritz Mühlenhoff <jmm@inutil.org> - 2020-12-26 19:50 +0100
      Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x Simon McVittie <smcv@debian.org> - 2020-12-26 21:50 +0100

#68955 — Bug#977841: bubblewrap: needs transition to non-setuid to accompany linux/5.10.x

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

[toc] | [next] | [standalone]

#68985

Am Mon, Dec 21, 2020 at 06:55:36PM +0000 schrieb Simon McVittie:
> Package: bubblewrap
> Version: 0.4.1-1
> Severity: important
> Tags: security
> X-Debbugs-Cc: debian-kernel@lists.debian.org, team@security.debian.org
> 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

Why is this needed, given that anyone running a default bullseye kernel will have
that setting by default? Is this for the upgrade case before someone has rebooted
into the new kernel?

I would keep it simple: Make bubblewrap unconditionally depend on
unprivileged_userns_clone=1 and bail out with an error message if that's not the case.
There's a fair number of non-server use cases where it makes sense to disable
unprivileged user namespaces, but it seems like a fair tradeoff for bubblewrap
to simply depend on them being available.

Cheers,
        Moritz

[toc] | [prev] | [next] | [standalone]

#68987

On Sat, 26 Dec 2020 at 19:43:22 +0100, Moritz Mühlenhoff wrote:
> Am Mon, Dec 21, 2020 at 06:55:36PM +0000 schrieb Simon McVittie:
> > 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
> 
> Why is this needed, given that anyone running a default bullseye kernel will have
> that setting by default? Is this for the upgrade case before someone has rebooted
> into the new kernel?

For users of testing/unstable who haven't rebooted yet, and for users
of the future stable who boot into the buster kernel as a recovery step
because the bullseye kernel has some regression on their hardware.

> I would keep it simple: Make bubblewrap unconditionally depend on
> unprivileged_userns_clone=1 and bail out with an error message if that's not the case.

A non-setuid bubblewrap will do that anyway (although I should patch it to
make the message point to Debian-specific information), but I'm concerned
that non-technical users of Flatpak via a GUI won't see that message,
because flatpak's stderr will end up in the systemd Journal or /dev/null,
leading the user to complain that Flatpak apps don't run and requiring
some round-trips before we discover that they're in this situation.

Other uses of bubblewrap, like libgnome-desktop (sandboxed thumbnailing
for nautilus/eog) could be worse for this than Flatpak, because users
won't necessarily expect basic functionality like that to have anything
to do with namespaces.

I'm keen for this to "just work" because if it doesn't, I don't want
to spend 3 years responding to repeats of the same Flatpak and GNOME
bug report.

    smcv

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.kernel

csiph-web