** Description changed: - The version of libseccomp2 in bionic does not know about the openat2 - syscall. + [Impact] - In my particular usecase, I was trying to run podman/buildah in an - nspawn container, using fuse-overlayfs. This leads to peculiar failure - modes as described in this issue: + The version of libseccomp2 in X/B/F/G does not know about the openat2 + syscall. As such applications that use libseccomp cannot specify a + system-call filter against this system-call and so it cannot be + mediated. - https://github.com/containers/fuse-overlayfs/issues/220 - This could well cause other problems, previously issues like that have - affected snapd, etc. + [Test Plan] - Backporting the master branch of libseccomp fixed this for me, but for - an SRU a cherrypick of - https://github.com/seccomp/libseccomp/commit/b3206ad5645dceda89538ea8acc984078ab697ab - might be sufficient... + This can be tested by simply running scmp_sys_resolver from the seccomp + binary package and specifying this system-call: - ProblemType: Bug - DistroRelease: Ubuntu 18.04 - Package: libseccomp2 2.4.3-1ubuntu3.18.04.3 - ProcVersionSignature: Ubuntu 5.4.0-42.46~18.04.1-generic 5.4.44 - Uname: Linux 5.4.0-42-generic x86_64 - ApportVersion: 2.20.9-0ubuntu7.16 - Architecture: amd64 - Date: Sun Aug 16 17:35:09 2020 - Dependencies: - gcc-8-base 8.4.0-1ubuntu1~18.04 - libc6 2.27-3ubuntu1.2 - libgcc1 1:8.4.0-1ubuntu1~18.04 - ProcEnviron: - TERM=screen.xterm-256color - PATH=(custom, no user) - LANG=en_GB.UTF-8 - SHELL=/bin/bash - SourcePackage: libseccomp - UpgradeStatus: No upgrade log present (probably fresh install) + Existing behaviour: + + $ scmp_sys_resolver openat2 + -1 + + Expected behaviour: + + $ scmp_sys_resolver openat2 + 437 + + (Note this value will be different on other architectures) + + + [Where problems could occur] + + In version 2.5.1 of libseccomp which adds this new system-call, changes + were also made in the way the socket system-call is handled by + libseccomp on PPC platforms - this resulted in a change in the expected + behaviour and so this has already been noticed and a fix is required for + the systemd unit tests as a result + https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1918696 + + There was also a similar change for s390x but so far no regressions have + been observed as a result as systemd already expected that behaviour + from libseccomp, it was only PPC that was missing. + + In the event that a regression is observed however, we can easily either + patch the affected package to cope with the new behaviour of this + updated libseccomp since in each case the change in behaviour only + affects a few system calls on particular architectures, or we can revert + this update. + + + [Other Info] + + * As usual thorough testing of this update has been performed both manually via the QA Regression Testing scripts, and via the autopkgtest infrastructure against packages in the Ubuntu Security Proposed PPA https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/ with results seen https://people.canonical.com/~platform/security-britney/current/
** Description changed: [Impact] The version of libseccomp2 in X/B/F/G does not know about the openat2 syscall. As such applications that use libseccomp cannot specify a system-call filter against this system-call and so it cannot be mediated. - [Test Plan] This can be tested by simply running scmp_sys_resolver from the seccomp binary package and specifying this system-call: Existing behaviour: $ scmp_sys_resolver openat2 -1 Expected behaviour: $ scmp_sys_resolver openat2 437 (Note this value will be different on other architectures) - [Where problems could occur] In version 2.5.1 of libseccomp which adds this new system-call, changes were also made in the way the socket system-call is handled by libseccomp on PPC platforms - this resulted in a change in the expected behaviour and so this has already been noticed and a fix is required for the systemd unit tests as a result https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1918696 There was also a similar change for s390x but so far no regressions have been observed as a result as systemd already expected that behaviour from libseccomp, it was only PPC that was missing. In the event that a regression is observed however, we can easily either patch the affected package to cope with the new behaviour of this updated libseccomp since in each case the change in behaviour only affects a few system calls on particular architectures, or we can revert this update. + [Other Info] - [Other Info] - - * As usual thorough testing of this update has been performed both manually via the QA Regression Testing scripts, and via the autopkgtest infrastructure against packages in the Ubuntu Security Proposed PPA https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/ with results seen https://people.canonical.com/~platform/security-britney/current/ + * As usual thorough testing of this update has been performed both + manually via the QA Regression Testing scripts, and via the autopkgtest + infrastructure against packages in the Ubuntu Security Proposed PPA + https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/ + with results seen https://people.canonical.com/~platform/security- + britney/current/ + + I have attached debdiffs of the prepared updates which are also sitting + in the Ubuntu Security Proposed PPA. ** Patch added: "libseccomp_2.5.1-1ubuntu1~16.04.1.debdiff" https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+attachment/5476576/+files/libseccomp_2.5.1-1ubuntu1~16.04.1.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1891810 Title: Missing openat2 syscall, causes problems for fuse-overlayfs in nspawn containers To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1891810/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
