seccomp argument filtering not working on trusty amd64
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
libseccomp (Ubuntu) |
Fix Released
|
High
|
Unassigned | ||
Trusty |
Fix Released
|
High
|
Jamie Strandboge |
Bug Description
[Impact]
A latent bug in libseccomp 2.1.0 and the proposed 2.1.1-1ubuntu1~
[Test Case]
A test case is included in the build in debian/
You can also run the snapd testsuite:
0. apt-get install dpkg-dev build-essential linux-libc-dev libseccomp-dev seccomp
1. enable deb-src trusty-proposed to get snapd 2.20
2. apt-get source snapd
3. cd ./snapd-2.20*
4. apt-get build-dep snapd
5. install libseccomp2 libseccomp-dev from trusty release (to demonstrate the problem)
6. debian/rules build # this should fail on amd64
...
FAIL: test_restrictio
...
7. install libseccomp2 libseccomp-dev from trusty-proposed
8. debian/rules clean ; debian/rules build # this should pass
In addition, follow the testing procedures as outlined in bug #1450642
[Regression Potential]
The patch to fix this issue required several other supporting patches. This patches applied cleanly to trusty and the patches themselves are well tested under upstream and 16.04+. The regression potential should be relatively low since the testsuite during the build shows no errors or failures and snapd has a big testsuite. Manually testing with snaps and lxc (the biggest consumers of libseccomp) and running the libseccomp autopkgtests also shows no issues.
= Original description =
The snapd build on trusty for amd64 fails with the following error:
"""
make[2]: Entering directory `/tmp/snapd-
...
PASS: test_restrictio
FAIL: test_restrictio
"""
(see https:/
The same build works for i386 and armhf.
I can reproduce this in a trusty chroot, upon further investigation it looks
like the version of libseccomp (2.1.1) in trusty-proposed is the culprit.
When I upgrade:
"""
Upgrade: libseccomp2:amd64 (2.1.1-
""""
all tests run fine. It looks like an issue with seccomp argument filtering (bpf) on 64 bit systems.
This https:/
however I have not looked in detail what patch exactly we may need.
Fwiw, we don't see this in spread because we build the package in the spread tests with `DEB_BUILD_
description: | updated |
summary: |
- seccomp argument filtering not working on trusty + seccomp argument filtering not working on trusty(?) |
description: | updated |
description: | updated |
description: | updated |
Changed in snap-confine (Ubuntu): | |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in snap-confine (Ubuntu): | |
status: | New → In Progress |
importance: | Undecided → High |
description: | updated |
description: | updated |
summary: |
- seccomp argument filtering not working on trusty(?) + seccomp argument filtering not working on trusty |
summary: |
- seccomp argument filtering not working on trusty + seccomp argument filtering not working on trusty amd64 |
description: | updated |
Changed in libseccomp (Ubuntu Trusty): | |
status: | New → In Progress |
importance: | Undecided → High |
assignee: | nobody → Jamie Strandboge (jdstrand) |
Changed in libseccomp (Ubuntu): | |
assignee: | Jamie Strandboge (jdstrand) → nobody |
status: | In Progress → Fix Released |
I'm not done looking at this, but I have confirmed this is a bug in libseccomp so retargeting there. What is happening is that snap-confine is getting a denial on geteuid (syscall 107) even though this syscall is included in the filter. This indicates a problem in the filter setup in libseccomp and not snap-confine itself and this patch appears to fix the issue: fe6bb20e5f635eb 02fd8d6eee
eece06525d58d08
However, that patch needs the following to be applied: a972823d0e101cc 71a8063547 9efb963569bb89f e82ed2d1ba 739eb6104f13d53 bddfa389ac
9ca83f455562fe8
206da04b8b2366d
61fee77783fd458
While with the above 4 patches applied the snap-confine testsuite passes, the libseccomp internal testsuite has many failures. I'm now investigating if it is better to continue cherrypicking patches or to pull back 2.2.3 from xenial.