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

[Alex Murray]

The systemd update for eoan is not in -proposed but the libseccomp
updates (for all releases) are - the systemd update for eoan needs to be
released in conjunction with the libseccomp update as it fixes a
regression in systemd/eoan/i386 when used in conjunction with the
libseccomp updates.

The systemd/eoan update is on only in the security-proposed PPA as I
don't have upload rights and so needs to be sponsored.

I believe the packages are ready to be released - all autopkgtests are
passing now for all releases of libseccomp - except systemd/eoan/i386
(hence the additional update for it).

The autopkgtests from the security-proposed PPA for systemd
https://people.canonical.com/~platform/security-
britney/current/security_eoan_excuses.html#systemd look pretty good.

openssh is failing - but this version 1:8.0p1-6build1 is failing already
- see http://autopkgtest.ubuntu.com/packages/o/openssh/eoan/amd64 for
instance where this version also failed in the same manner recently a
number of times.

pds, prometheus and stunnel4 are also failing but again these same
versions are already failing for the regular autopkgtests -
http://autopkgtest.ubuntu.com/packages/p/pdns/eoan/amd64
http://autopkgtest.ubuntu.com/packages/p/prometheus/eoan/amd64
http://autopkgtest.ubuntu.com/packages/s/stunnel4/eoan/amd64

snapd is failing for i386 but again is already failing for the same
version at http://autopkgtest.ubuntu.com/packages/s/snapd/eoan/i386

And similarly ubuntu-drivers-common is also failing for i386 but is
already failing for this same version -
http://autopkgtest.ubuntu.com/packages/u/ubuntu-drivers-common/eoan/i386

So I am confident this is ready to be released.

First, systemd 242-7ubuntu3.11  needs to be sponsored from the ubuntu-
security-proposed PPA to -proposed and then we can look at promoting all
the libseccomp updates and this systemd update for eoan to -updates (and
the security team can publish to -security and issue a USN once all are
in -updates).

-- 
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-1ubuntu3 from groovy to focal/eoan/bionic/xenial
  for newer syscalls for core20 base and test suite robustness

Status in libseccomp package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  New
Status in libseccomp source package in Xenial:
  Fix Committed
Status in libseccomp source package in Bionic:
  Fix Committed
Status in libseccomp source package in Eoan:
  Fix Committed
Status in systemd source package in Eoan:
  New
Status in libseccomp source package in Focal:
  Fix Committed
Status in libseccomp source package in Groovy:
  Fix Released

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