** Description changed:
+ [Impact]
+
+ * Just as of yesterday we have a new libseccomp in all releases.
+ This brings some new code and features which might impact packages.
+ For qemu being one of the few that is not so much a problem in many
+ cases. Prior to Disco we didn't have code in qemu using the new
+ libseccomp bits. In Eoan we can assume that libseccomp 2.4 (being
+ release level) will be installed.
+ But in Disco people might have installed and not updated libseccomp
+ but install/upgrade to a qemu that was built against that new
+ libseccomp. Due to that qemu will get a runtime dependency that is
+ not picked up automatically - this would break all qemu execution
+ being blocked by a failure to install seccomp filters.
+
+ * To fix that we will add an explicit versioned dependency to qemu to
+ make sure the rebuild will ensure that the right library version is
+ available.
+
+ * This is needed for qemu-system* which all depend on qemu-system-
+ common so to avoid too much noise changing all qemu-system* packages
+ the dependency it added there.
+
+
+ [Test Case]
+
+ * ensure that the qemu install will ensure that libseccomp2 (>= 2.4.1)
+ is also installed (not staying on 2.3)
+
+ * Then install qemu and run
+ $ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
+
+ which should not trigger this (when fixed)
+ error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
+
+
+ [Regression Potential]
+
+ * Well, the regressions might be triggered by pushing the new
+ libseccomp, not by this dependency fixup. The security Team has
+ checked and this seems to be the only affected code in the archive.
+ So libseccomp was pushed to fix CVEs. I have thought if it is a
+ regression that users of qemu will now be forced to use the newer
+ libseccomp, but since it would be unusable without that is no
+ important argument. And it is strongly recommended to upgrade for
+ security reasons as well.
+
+ [Other Info]
+
+ * n/a
+
+ ---
+
It started with some of my usual KVM checks and found them failing on Disco
with:
error: internal error: process exited while connecting to monitor:
2019-05-28T17:10:17.121934Z qemu-system-x86_64: -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny: failed
to install seccomp syscall filter in the kernel
I realized it works on X/B/C/E but not in a D container
It worked ~4 weeks ago.
This test can be simplified to one command:
$ qemu-system-x86_64 -enable-kvm -nographic -nodefaults -sandbox
on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny
With strace I found different behavior:
Good:
[pid 3487] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000011>
[pid 3487] 0.003136 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.000044>
[pid 3487] 0.000250 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x55f2b7a5e2d0}) = 0 <0.000251>
Bad:
[pid 484] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000017>
[pid 484] 0.002680 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.000014>
[pid 484] 0.000088 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.000013>
The difference seems to come from being built against seccomp as in
Disco (2.3.3-3ubuntu2 = good) or Disco-proposed ( = bad).
The dependency on the built package stayed
libseccomp2 (>= 2.3.0)
It did not pick up 2.4 via e.g. shlibs.
If I install libseccomp2 2.4 from -proposed the issue is gone.
Strace now looks like:
[pid 1788] 0.000000 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000015>
[pid 1788] 0.004167 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.000013>
[pid 1788] 0.000098 seccomp(SECCOMP_SET_MODE_STRICT, 1, NULL) = -1
EINVAL (Invalid argument) <0.000013>
[pid 1788] 0.000054 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, NULL) = -1 EFAULT (Bad address) <0.000022>
[pid 1788] 0.000061 seccomp(SECCOMP_GET_ACTION_AVAIL, 0,
[SECCOMP_RET_KILL_PROCESS]) = 0 <0.000017>
[pid 1788] 0.001477 seccomp(SECCOMP_SET_MODE_FILTER,
SECCOMP_FILTER_FLAG_TSYNC, {len=68, filter=0x564de3852560}) = 0 <0.000288>
This is in all releases proposed to fix CVE-2019-9893
I was just ?lucky? to pick it up with my qemu build in the PPA that has
proposed enabled.
Now there might be some toolchain detail to this as well.
As I built qemu for B/C as well and they built against the proposed 2.4
versions as well.
But in B/C things work with new qemu builds and old libseccomp2 installed.
Eoan on the other hand works by having libseccomp2 2.4.1-0ubuntu0.19.10.3
already migrated.
But that "luck" of B/C working might be specific to Qemus code, other
rebuilds against the new libseccomp2 might fail as well in B/C and
further. Shlibs detection is based on these symbols but my new qemu
build is not calling these so it dependency stays at 2.3.
Until a simpler testcase is found, I have set up two new PPAs:
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-with-proposed-seccomp
https://launchpad.net/~paelzer/+archive/ubuntu/bug-1830859-without-proposed-seccomp
-
In comment #5 I debugged the case and found the new "dependency"
As a summary:
- the libseccomp-dev 2.4 headers being installed at build time
- code can detect now the availability of SCMP_ACT_KILL_PROCESS
- code might decide to use SCMP_ACT_KILL_PROCESS
- if code runs without libseccomp2 2.4 installed it breaks
-
### some related Build logs ###
Cosmic rebuild against 2.4, not affected by the issue
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3729/+build/16858331/+files/buildlog_ubuntu-cosmic-amd64.qemu_1%3A2.12+dfsg-3ubuntu8.9~ppa1_BUILDING.txt.gz
Disco rebuild against 2.4, affected by the issue
https://launchpadlibrarian.net/425689546/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.2~ppa1_BUILDING.txt.gz
Disco build against 2.3 (working)
https://launchpadlibrarian.net/422884897/buildlog_ubuntu-disco-amd64.qemu_1%3A3.1+dfsg-2ubuntu3.1_BUILDING.txt.gz
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1830859
Title:
new libseccomp 2.4 (in proposed) makes rebuilds need but not generate
a dependency to 2.4
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
