[Bug 1876055] Re: SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial for newer syscalls for core20 base

[Alex Murray]

** Description changed:

  [Impact]
  
- snap-confine from snapd uses libseccomp to filter various system calls
- for confinement. The current version in eoan/bionic/xenial (2.4.1) is
- missing knowledge of various system calls for various architectures. As
- such this causes strange issues like python snaps segfaulting
+ The combination of snap-confine and snap-seccomp from snapd uses
+ libseccomp to filter various system calls for confinement. The current
+ version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
+ system calls for various architectures. As such this causes strange
+ issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent denial
  of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).
  
  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).
  
  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.
+ 
+ 
+ Included as part of this SRU are test-suite reliability improvements - currently the xenial libseccomp package overrides test-suite failures at build time to ignore failures. This masks the fact that on ppc64el and s390x there are currently test suite failures at build time for xenial - these failures occur since libseccomp now includes knowledge of system calls for these architectures but which the linux-libc-dev package for xenial does not actually define (since this is based of the 4.4 kernel in xenial whereas libseccomp 2.4.1 in xenial has knowledge of all system calls up to 5.4). 
+ 
+ In this SRU I have instead fixed the test suite failures for xenial by
+ including a local (test-suite specific) set of architecture specific
+ kernel headers from the linux-libc-dev in focal for all releases. These
+ are just the headers which define the system call numbers for each
+ architecture *and* these are added to tests/include/$ARCH in the source
+ package (and tests/Makefile.am is then updated to include these new
+ headers only).  As such this ensures the actual build of libseccomp or
+ any of the tools does not reference these headers. This allows the test
+ suite in libseccomp to then be aware of theses system calls and so all
+ unit tests for all architectures now pass.
+ 
+ In any future updates for libseccomp to add new system calls, we can
+ then similarly update these local headers to ensure the unit tests
+ continue to work as expected.
  
  
  [Test Case]
  
  libseccomp includes a significant unit test suite that is run during the
  build and as part of autopkgtests. To verify the new aarch64 system
  calls are resolved as expected the scmp_sys_resolver command can be used
  as well:
  
  $ scmp_sys_resolver -a aarch64 getrlimit
  163
  
  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).
  
  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the libseccomp
  test suite*. This allows all unit tests to pass on older releases as
  well and defaults the build to fail on unit test failures (whereas
  currently in xenial this has been overridden to ignore failures).
  
  
  [Regression Potential]
  
  This has a low regression potential due to significant testing with many
  packages that depend on libseccomp (lxc, qemu, snapd, apt, man etc) and
- none have shown any regression using this new version.
+ none have shown any regression using this new version. The re-enablement
+ of build failure on test failure at build time also ensures that we can
+ reliably detect FTBFS issues in the future.
+ 
+ No symbols have been removed (or added) with this update in version so
+ there is no chance of regression due to ABI change etc. In the past, the
+ security team has performed more significant version upgrades for
+ libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the case
+ of *this* SRU, we are only doing a micro-version upgrade from 2.4.1 to
+ 2.4.3 so this carries even less change of regressions.
  
  Any possible regressions may include applications now seeing correct
  system call resolution whereas previously this would have failed, and so
  perhaps previous failures (which were erroneous) will now be permitted.
  However, this was always permitted previously by the policy anyway but
  just denied due to this bug so it is not a true regression as such.
+ 
+ 
+ I have prepared these updates in the ubuntu-security-proposed PPA - could the SRU team could please review these in lieu of attached debdiffs?

-- 
You received this bug notification because you are a member of Ubuntu
Sponsors Team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1876055

Title:
  SRU: Backport 2.4.3-1ubuntu2 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base

Status in libseccomp package in Ubuntu:
  New

Bug description:
  [Impact]

  The combination of snap-confine and snap-seccomp from snapd uses
  libseccomp to filter various system calls for confinement. The current
  version in eoan/bionic/xenial (2.4.1) is missing knowledge of various
  system calls for various architectures. As such this causes strange
  issues like python snaps segfaulting
  (https://github.com/snapcore/core20/issues/48) or the inadvertent
  denial of system calls which should be permitted by the base policy
  (https://forum.snapcraft.io/t/getrlimit-blocked-by-seccomp-on-focal-
  arm64/17237).

  libseccomp in groovy is using the latest upstream base release (2.4.3)
  plus it includes a patch to add some missing aarch64 system calls
  (https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1877633).

  SRUing this version back to older stable releases allows libseccomp to
  operate correctly on all supported architectures.

  
  Included as part of this SRU are test-suite reliability improvements - currently the xenial libseccomp package overrides test-suite failures at build time to ignore failures. This masks the fact that on ppc64el and s390x there are currently test suite failures at build time for xenial - these failures occur since libseccomp now includes knowledge of system calls for these architectures but which the linux-libc-dev package for xenial does not actually define (since this is based of the 4.4 kernel in xenial whereas libseccomp 2.4.1 in xenial has knowledge of all system calls up to 5.4). 

  In this SRU I have instead fixed the test suite failures for xenial by
  including a local (test-suite specific) set of architecture specific
  kernel headers from the linux-libc-dev in focal for all releases.
  These are just the headers which define the system call numbers for
  each architecture *and* these are added to tests/include/$ARCH in the
  source package (and tests/Makefile.am is then updated to include these
  new headers only).  As such this ensures the actual build of
  libseccomp or any of the tools does not reference these headers. This
  allows the test suite in libseccomp to then be aware of theses system
  calls and so all unit tests for all architectures now pass.

  In any future updates for libseccomp to add new system calls, we can
  then similarly update these local headers to ensure the unit tests
  continue to work as expected.

  
  [Test Case]

  libseccomp includes a significant unit test suite that is run during
  the build and as part of autopkgtests. To verify the new aarch64
  system calls are resolved as expected the scmp_sys_resolver command
  can be used as well:

  $ scmp_sys_resolver -a aarch64 getrlimit
  163

  (whereas in the current version in focal this returns -10180 as
  libseccomp was not aware of this system-call at compile-time).

  As part of this SRU, the test suite in libseccomp has been patched to
  include a local copy of the architecture-specific kernel headers from
  the 5.4 kernel in focal *for all releases*, so that all system calls
  which are defined for the 5.4 kernel are known about *for the
  libseccomp test suite*. This allows all unit tests to pass on older
  releases as well and defaults the build to fail on unit test failures
  (whereas currently in xenial this has been overridden to ignore
  failures).

  
  [Regression Potential]

  This has a low regression potential due to significant testing with
  many packages that depend on libseccomp (lxc, qemu, snapd, apt, man
  etc) and none have shown any regression using this new version. The
  re-enablement of build failure on test failure at build time also
  ensures that we can reliably detect FTBFS issues in the future.

  No symbols have been removed (or added) with this update in version so
  there is no chance of regression due to ABI change etc. In the past,
  the security team has performed more significant version upgrades for
  libseccomp (2.2, 2.3, 2.4) -> 2.4.1 without major incident. In the
  case of *this* SRU, we are only doing a micro-version upgrade from
  2.4.1 to 2.4.3 so this carries even less change of regressions.

  Any possible regressions may include applications now seeing correct
  system call resolution whereas previously this would have failed, and
  so perhaps previous failures (which were erroneous) will now be
  permitted. However, this was always permitted previously by the policy
  anyway but just denied due to this bug so it is not a true regression
  as such.

  
  I have prepared these updates in the ubuntu-security-proposed PPA - could the SRU team could please review these in lieu of attached debdiffs?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1876055/+subscriptions