[flatpak-1.6.x] Backport CVE-2021-21261, CVE-2021-21381 and CVE-2021-41133 fixes

[debarshiray]

We are carrying these in RHEL 8.2. Given that these are security fixes, I thought that I might as well put them on the upstream flatpak-1.6.x branch, and let everybody benefit.

(We do backport fixes for CVEs rated as important to older RHEL point-releases.)

Based on #4456

---

• Fix build with GCC 11
  (cherry picked from commit ff0ca9a)

• CI: Do one build out-of-tree
  (cherry picked from commit 0d58999)

• tests: Add and use "ok" helper
  (cherry picked from commit b1fdf6c)

• Add --enable-asan option
  (cherry picked from commit 0a16938)

• CI: Use the new --enable-asan
  (cherry picked from commit be70cd5)

• CI: Add mono apt repo to fix build
  (cherry picked from commit c647062)

• Drop old-glib ci test as ubuntu 16.04 is no longer available
  (backported from commit 481e5c8)

• common: Add a backport of G_DBUS_METHOD_INVOCATION_HANDLED
  (cherry picked from commit d1d05a7)

• system-helper: Return G_DBUS_METHOD_INVOCATION_HANDLED where appropriate
  (cherry picked from commit fb6f1ea)

• system-helper: Fix deploys of local remotes
  (cherry picked from commit 16290b5)

• tests: Work around summary mtime cache issue (for 1.6 branch)
  (cherry picked from commit 07e6a2c)

• run: Convert all environment variables into bwrap arguments
  (cherry picked from commit dcd2494)

• tests: Expand coverage for environment variable overrides
  (cherry picked from commit 6a11007)

• context: Add --env-fd option
  (cherry picked from commit 57416f3)

• portal: Convert --env in extra-args into --env-fd
  (backported from commit fb1eaef)

• tests: Exercise --env-fd
  (cherry picked from commit 7bb78f8)

• portal: Do not use caller-supplied variables in environment
  (cherry picked from commit 26f09bf)

• tests: Assert that --env= does not go in flatpak run or bwrap environ
  (cherry picked from commit 5019b30)

• Fix tests when installed tests are not enabled
  (cherry picked from commit e3d06dd)

• build: Convert environment into a sequence of bwrap arguments
  (cherry picked from commit 93ecea3)

• dir: Pass environment via bwrap --setenv when running apply_extra
  (cherry picked from commit f91857c)

• Disallow @@ and @@U usage in desktop files
  (cherry picked from commit c54e7c3)

• dir: Reserve the whole @@ prefix
  (cherry picked from commit cc7526b)

• dir: Refuse to export .desktop files with suspicious uses of @@ tokens
  (cherry picked from commit 754450e)

• tree-wide: Replace usages of whitelist/blacklist
  (cherry picked from commit a994cdb)

• Fix argument order of clone() for s390x in seccomp filter
  (cherry picked from commit f4c3ea5)

• run: Add an errno value to seccomp filters
  (cherry picked from commit 89f9bb7)

• run: Add cross-references for some other seccomp syscall filters
  (cherry picked from commit 13d34f9)

• common: Add a list of recently-added Linux syscalls
  (cherry picked from commit cf9cdd9)

• run: Block clone3() in sandbox
  (cherry picked from commit 08c65cd)

• run: Disallow recently-added mount-manipulation syscalls
  (cherry picked from commit db4ccf7)

• run: Block setns()
  (cherry picked from commit a01fc5f)

• run: Don't allow unmounting filesystems
  (cherry picked from commit 758b8ca)

• run: Don't allow chroot()
  (cherry picked from commit 8f87696)

• run: Handle unknown syscalls as intended
  (cherry picked from commit a0055e4)

• Fix handling of syscalls only allowed by --devel
  (cherry picked from commit da503e0)

• run: Improve error handling/diagnostics for calls into libseccomp
  (cherry picked from commit adaa025)

[smcv]

You'll probably also want to backport the equivalent of #4474, to fix the things that regressed when we fixed CVE-2021-21261.

(I'd also appreciate testing and review of #4474.)

[smcv]

What libseccomp do you have in RHEL 8.2? If you want to block clone3() for CVE-2021-41133, you'll need at least 2.5.0, or some backported patches.

[debarshiray]

What libseccomp do you have in RHEL 8.2? If you want to
block clone3() for CVE-2021-41133, you'll need at least 2.5.0,
or some backported patches.

RHEL 8.2 only has 2.4.1. As far as I can make out, these flatpak-1.6.x backports do work - both in my quick smoke testing and in the hands of the QE team. Am I missing something?

[debarshiray]

You'll probably also want to backport the equivalent of #4474,
to fix the things that regressed when we fixed CVE-2021-21261.

I am a bit torn.

The build fix with GCC 11 definitely seems safe enough to use. However, for the rest, I can only do some superficial smoke testing. I wouldn't be able to get the RHEL QE team to give them any sort of rigorous scrutiny.

I am somewhat confident about the patches that are currently in this PR because they went through QE and are currently shipping.

What do you think?

(I'd also appreciate testing and review of #4474.)

I can certainly help with that. :)

[smcv]

RHEL 8.2 only has 2.4.1. As far as I can make out, these flatpak-1.6.x backports do work - both in my quick smoke testing and in the hands of the QE team. Am I missing something?

If your kernel knows about clone3() but your libseccomp does not, then Flatpak will not be able to prevent clone3() from being called by apps that have the "multiarch" feature enabled (those that need to be able to run i386 code on x86_64, like Steam), or by extra-data extractors.

[smcv]

You'll probably also want to backport the equivalent of #4474,
to fix the things that regressed when we fixed CVE-2021-21261.

The build fix with GCC 11 definitely seems safe enough to use. However, for the rest, I can only do some superficial smoke testing. I wouldn't be able to get the RHEL QE team to give them any sort of rigorous scrutiny.

To be clear, I'm not saying that backporting the equivalent of #4474 is a blocker for merging this. However, if we don't have the equivalent of #4474, then there will be known, unfixed regressions in the flatpak-1.6.x branch. Is that OK or not? I honestly don't know - if you're pushing to 1.6.x mainly for the benefit of Red Hat and Canonical, then it's really up to Red Hat and Canonical what their policies look like.

The only distribution whose security policies I'm familiar with is Debian, and if a security fix causes regressions, the Debian security team does try to release fixes for those regressions as a revised DSA (example), to avoid creating an incentive for users to not apply security updates.

I don't have access to a QA team, so you're already ahead of the amount of testing I can do - my Flatpak contributions are as an individual, with occasional help from one of my Collabora colleagues if the contribution is work-related. Of course in an ideal world I wouldn't have committed a security fix that caused regressions, but it's not always feasible to avoid mistakes, particularly when working under embargo with only a small number of possible reviewers. CVE-2021-21261 is something I noticed while doing feature development (I wasn't specifically looking for vulnerabilities), and I only found the regression when I went back to working on the new feature.

[debarshiray]

You'll probably also want to backport the equivalent of #4474,
to fix the things that regressed when we fixed CVE-2021-21261.

The build fix with GCC 11 definitely seems safe enough to use.

I have now included the build fix with GCC 11 in this pull request, since I need it to build the code on my Fedora 35 laptop which vastly simplifies my life. :)

However, for the rest, I can only do some superficial smoke testing.
I wouldn't be able to get the RHEL QE team to give them any sort of
rigorous scrutiny.

To be clear, I'm not saying that backporting the equivalent of #4474 is a
blocker for merging this. However, if we don't have the equivalent of #4474,
then there will be known, unfixed regressions in the flatpak-1.6.x branch.
Is that OK or not? I honestly don't know - if you're pushing to 1.6.x mainly
for the benefit of Red Hat and Canonical, then it's really up to Red Hat and
Canonical what their policies look like.

Red Hat's security team had flagged CVE-2021-21261, CVE-2021-21381 and CVE-2021-41133 as important. This meant that they had to be fixed in older RHEL point releases. eg., CVE-2021-21261 came out during the RHEL 8.4 development cycle, but it was still fixed for RHELs 8.2, 8.1 and 7.9.

For such fixes to older RHEL point releases, the patches need to be strictly targeted fixes. There's no way for me to include the regression fixes that happened later (such as the ones in #4474) unless I can convince various people that they are critical enough to roll out another series of updates going all the way back to 7.9. I suspect that I will be encouraged to let sleeping dogs lie. :)

However, it's a lot easier for me to pull in fixes from the upstream stable branches for future RHEL point releases. eg., the flatpak-1.8.6 release for RHEL 8.6.

My motivation behind this pull request is to simply publish all the backports for flatpak-1.6.x that we are already carrying downstream in a sane way. They went through the usual scrutiny from the RHEL QE team and are part of the public RHEL SRPMs anyway. If nothing else, having them as part of the upstream Git branch will make my life a lot saner when I have to do another round of backports for the next important CVE.

I won't be pushing for new releases from the flatpak-1.6.x branch, because I can't use them anywhere. However, if Ubuntu wants to include a new tarball in 20.04 LTS, then I'd be happy to see them use these backports.

So, in short, I am reluctant to backport more fixes at the moment because I can't ship them anywhere and can't thoroughly test them.

The only distribution whose security policies I'm familiar with is Debian, and
if a security fix causes regressions, the Debian security team does try to
release fixes for those regressions as a revised DSA
(example),
to avoid creating an incentive for users to not apply security updates.

I will try to find out what RHEL's policy is about regressions in security updates. All this happened while the Flatpak stack was owned by @alexlarsson and @amigadave in Fedora and RHEL, so I might be missing some context.

Of course in an ideal world I wouldn't have committed a security fix that caused
regressions, but it's not always feasible to avoid mistakes, particularly when
working under embargo with only a small number of possible reviewers.
CVE-2021-21261 is something I noticed while doing feature development (I
wasn't specifically looking for vulnerabilities), and I only found the regression
when I went back to working on the new feature.

No need to apologize. We are all human, and you are doing a lot more than most. :)

[debarshiray]

Ping.