This bug was fixed in the package libseccomp - 2.4.3-1ubuntu3.16.04.2
---------------
libseccomp (2.4.3-1ubuntu3.16.04.2) xenial; urgency=medium
* Updated to new upstream 2.4.3 version for updated syscalls support
and test-suite robustness
- d/p/add-5.4-local-syscall-headers.patch: Add local copy of the
architecture specific header files which specify system call numbers
from linux-libc-dev in focal to ensure unit tests pass on older
releases where the linux-libc-dev package does not have the required
system calls defined and use these during compilation of unit tests
- d/p/db-properly-reset-attribute-state.patch: Drop this patch since
is now upstream
- LP: #1876055
* Add missing aarch64 system calls
- d/p/fix-aarch64-syscalls.patch
- LP: #1877633
* Re-enable build failure on unit test failure
-- Alex Murray <alex.mur...@canonical.com> Tue, 02 Jun 2020 14:16:21
+0930
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
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 Released
Status in libseccomp source package in Bionic:
Fix Released
Status in libseccomp source package in Eoan:
Fix Released
Status in systemd source package in Eoan:
New
Status in libseccomp source package in Focal:
Fix Released
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
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
