[13:09] <mdeslaur> cpaelzer: oh, we knew about that one :(
[13:09] <cpaelzer> well
[13:09] <cpaelzer> then had you a plan how we should resolve that
[13:10] <cpaelzer> either in general (magic great code I haven't thought of) or
in particular (how I should resolve it for qemu) ?
[13:10] <cpaelzer> and good morning mdeslaur sorry to start with such issues :-/
[13:10] <mdeslaur> cpaelzer: good morning! :)
[13:11] <-- lborda-eod ([email protected]) has left this
server (Quit: Ex-Chat).
[13:11] <mdeslaur> cpaelzer: the plan is to publish the libseccomp update ;)
[13:11] --> lborda ([email protected]) has joined this
channel.
[13:11] <mdeslaur> cpaelzer: we searched the archive, and qemu was the only
problematic package that used those new apis
[13:12] <mdeslaur> jdstrand: are we ready to publish the seccomp updates?
[13:12] <cpaelzer> mdeslaur: ok then should I add an explicit dependency for
Disco
[13:12] <cpaelzer> only there the "transition" might occur
[13:13] <cpaelzer> that we rebuild with the new version around but the old
might be installed
[13:13] <jjohansen> hey mdeslaur
[13:13] <cpaelzer> I'm prepping an SRU anyway and that would avoid the "rebuilt
to 2.4 but not installed"
[13:13] <cpaelzer> if qemu really is the only one I'm ok to carry this
[13:13] <mdeslaur> cpaelzer: yeah, you can add an explicit dependency, or you
can wait until we publish seccomp...we may publish it today or monday
[13:13] <cpaelzer> and in Eoan things are fine as that will release with >=2.4
[13:14] <cpaelzer> mdeslaur: well, my point is even if you publish it there are
no guarantees
[13:14] <cpaelzer> people might update qemu but not libseccomp
[13:14] <cpaelzer> and they would be screwed
[13:14] <cpaelzer> so the first rebuild of qemu in disco (=now) will need to
add the dependency
[13:14] <cpaelzer> mdeslaur: ^^
[13:15] <mdeslaur> yes, selective installing of security updates is an untested
and probably broken configuration
[13:15] <mdeslaur> if you add the explicit dependency, you'll need to wait
until we do publish seccomp too
[13:15] <cpaelzer> yes, but I'll need a few days anyway
[13:15] <cpaelzer> and you seem close
[13:16] <mdeslaur> ok
[13:16] <cpaelzer> and for testing interim wise I can throw a no change rebuild
of libseccomp 2.4 in my ppa
[13:16] <mdeslaur> I'll try and remember to add the explicit dependency to the
next round of qemu updates
[13:16] <cpaelzer> Hmm, you have some in the pipe as well?
[13:16] <mdeslaur> I don't currently, no
[13:16] <cpaelzer> I have
[13:16] <cpaelzer> I'll add them right away
[13:17] <cpaelzer> if testing goes well those should hit -unapproved early next
week
[13:17] <mdeslaur> sorry our timezones don't overlap and you had to spend time
debugging this
[13:17] <mdeslaur> we spotted this issue when we prepared the emergency qemu
update last week
TL;DR
we will make is a qemu fix in Disco, by adding an explicit dependency.
All others don't need the change.
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: libseccomp (Ubuntu)
Status: New => Won't Fix
** Changed in: qemu (Ubuntu)
Status: New => Triaged
** Changed in: qemu (Ubuntu)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libseccomp (Ubuntu)
Assignee: Ubuntu Security Team (ubuntu-security) => (unassigned)
** Changed in: qemu (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in 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
Status in libseccomp package in Ubuntu:
Won't Fix
Status in qemu package in Ubuntu:
Triaged
Bug description:
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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1830859/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
