seccomp argument filtering not working on trusty amd64

Bug #1653487 reported by Michael Vogt
12
This bug affects 1 person
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~trusty1 was exposed in the snapd build testsuite when run on amd64. It has to do with libseccomp's state machine not always working correctly when using argument filtering and there were no tests for this particular failure in 2.1. Once 19e6c4aeca9818c4b288b09911dfa4be9a831236 (the upstream test for this issue) is applied to 2.1, you see the failures. Simple seccomp filters that just use the syscall name are not affected by the bug and we (currently) only use seccomp arg filtering in one interface which is why Tyler's testing of 2.1.1-1ubuntu1~trusty1 didn't show it either. The snap-confine tests do exercise it, but seccomp argument filtering wasn't added until series 16 and seccomp 2.2.3 had all the fixes already. Porting series 16 snapd/snap-confine and all of snap-confine's arg filtering tests to trusty revealed the bug in seccomp 2.1.

[Test Case]
A test case is included in the build in debian/patches/bpf-accumulator-check.patch (19e6c4aeca9818c4b288b09911dfa4be9a831236). You can check the amd64 build log to verify no failures.

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_restrictions_working_args
...
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-2.20.1~14.04/cmd/snap-confine/tests'
...
PASS: test_restrictions_working
FAIL: test_restrictions_working_args
"""
(see https://launchpad.net/ubuntu/+source/snapd/2.20.1~14.04/+build/11759913)

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-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1), libseccomp-dev:amd64 (2.1.1-1ubuntu1~trusty1, 2.2.3-2ubuntu1~ubuntu14.04.1)
""""
all tests run fine. It looks like an issue with seccomp argument filtering (bpf) on 64 bit systems.
This https://github.com/seccomp/libseccomp/releases/tag/v2.2.1 might include the missing fix,
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_OPTIONS='nocheck testkeys' dpkg-buildpackage` and we do not run the integration tests of snap-confine in anything else beside the package build (until https://github.com/snapcore/snapd/pull/2433/files is merged).

Michael Vogt (mvo)
description: updated
Michael Vogt (mvo)
summary: - seccomp argument filtering not working on trusty
+ seccomp argument filtering not working on trusty(?)
description: updated
Michael Vogt (mvo)
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
Revision history for this message
Jamie Strandboge (jdstrand) wrote : Re: seccomp argument filtering not working on trusty(?)

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:
eece06525d58d08fe6bb20e5f635eb02fd8d6eee

However, that patch needs the following to be applied:
9ca83f455562fe8a972823d0e101cc71a8063547
206da04b8b2366d9efb963569bb89fe82ed2d1ba
61fee77783fd458739eb6104f13d53bddfa389ac

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.

affects: snap-confine (Ubuntu) → libseccomp (Ubuntu)
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I've identified the additional patches to make the testsuite happy and will be testing the cherrypicked patches approach and upload to trusty-proposed once testing is completed.

description: updated
description: updated
Michael Vogt (mvo)
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
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I uploaded 2.1.1-1ubuntu1~trusty3 to fix this issue to trusty-proposed.

description: updated
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
Revision history for this message
Brian Murray (brian-murray) wrote : Please test proposed package

Hello Michael, or anyone else affected,

Accepted libseccomp into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libseccomp/2.1.1-1ubuntu1~trusty3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in libseccomp (Ubuntu Trusty):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Jamie Strandboge (jdstrand) wrote :

I've completed my verification of 2.1.1-1ubuntu1~trusty3 SRU for amd64 and i386.

I followed the test plan for this and bug #1653487 with additional manual testing for lxc and docker debs along with various snaps (ufw, lxd, docker (amd64 only since docker upstream doesn't provide 32 bit images; also see unrelated bug #1654590), etc and found no regressions.

Build logs:

armhf:
Regression Test Summary
 tests run: 4115
 tests skipped: 79
 tests passed: 4115
 tests failed: 0
 tests errored: 0

i386:
Regression Test Summary
 tests run: 6573
 tests skipped: 51
 tests passed: 6573
 tests failed: 0
 tests errored: 0

amd64:
Regression Test Summary
 tests run: 6577
 tests skipped: 53
 tests passed: 6577
 tests failed: 0
 tests errored: 0

On amd64 and i386, the snapd testsuite passes with the updated seccomp packages:
$ debian/rules build
...
# TOTAL: 21
# PASS: 21
# SKIP: 0
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
...

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

Furthermore, I triggered a rebuild for snapd/amd64, it succeeded and is in trusty-proposed now.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (3.7 KiB)

This bug was fixed in the package libseccomp - 2.1.1-1ubuntu1~trusty3

---------------
libseccomp (2.1.1-1ubuntu1~trusty3) trusty-proposed; urgency=medium

  * Cherrypick various bpf fixes to support argument filtering on 64-bit
    (LP: #1653487)
    - debian/patches/bpf-use-state-arch.patch: use state->arch instead of
      db->arch in _gen_bpf_arch()
    - debian/patches/db-require-filters-to-share-endianess.patch: require all
      filters in a collection to share the same endianess
    - debian/patches/resolve-issues-caused-by-be.patch: resolve issues caused
      by big endian systems
    - debian/patches/bpf-accumulator-check.patch: test the bpf accumulator
      checking logic
    - debian/patches/bpf-track-accumulator-state.patch: track accumulator
      state and reload it when necessary. This is the fix for LP: #1653487. The
      previous patches are required by this patch.
    - debian/patches/ensure-simulator-has-valid-arch.patch: ensure the
      simulator always has a valid architecture value. This fixes a regression
      in the testsuite introduced by resolve-issues-caused-by-be.patch
    - debian/patches/bpf-accumulator-check-indep.patch: fix a regression in the
      testsuite introduced by bpf-accumulator-check.patch
    - debian/patches/fix-audit-arch-i386.patch: fix arch token for 32-bit x86
      not being defined correctly for the tools

libseccomp (2.1.1-1ubuntu1~trusty1) trusty-proposed; urgency=medium

  * Bring libseccomp 2.1.1-1ubuntu1~vivid2, from Ubuntu 14.10, to Ubuntu
    14.04 and add a couple patches to account for new syscalls found in the
    4.4 based hardware enablement kernel. This allows for proper snap seccomp
    confinement on Ubuntu 14.04 when using the hardware enablement kernel
    (LP: #1450642)
    - debian/patches/add-membarrier-and-userfaultfd.patch: Add membarrier and
      userfaultfd syscalls
    - debian/patches/add-mlock2.patch: Add mlock2 syscall
    - debian/tests/data/all-except-s390-4.4.filter: Add autopkgtest that
      verifies all syscalls found in the 4.4 kernel, except for the s390
      specific syscalls, are supported by libseccomp. The s390 specific
      syscalls are not needed since this version of libseccomp does not
      support the s390 architecture.
    - debian/tests/test-filter: Skip the getrandom filter tests since
      SYS_getrandom is not defined in 14.04 environment and the getrandom(2)
      syscall is not even available in the 14.04 release kernel.

libseccomp (2.1.1-1ubuntu1~vivid2) vivid-proposed; urgency=medium

  * add-finit-module.patch: add finit_module syscalls to x86 and x86-64
    syscall tables
  * update syscalls for modern kernels (skipping MIPS)
    - update syscalls for 3.16:
      + update-x86-syscall-table.patch
      + update-x86_64-syscall-table.patch
      + update-arm-syscall-table.patch
      + update-x32-syscall-table.patch
      + sync-syscall-table-entries.patch
      + sync-syscall-table-entries-fixtypo.patch
    - update syscalls for 3.17:
      + sync-syscall-table-entries-3.17.patch
    - update syscalls for 3.19:
      + sync-syscall-table-entries-3.19.patch
    - LP: #1450642
  * fix-segfault-with-unknown.patch: fix segfault when...

Read more...

Changed in libseccomp (Ubuntu Trusty):
status: Fix Committed → Fix Released
Revision history for this message
Robie Basak (racb) wrote : Update Released

The verification of the Stable Release Update for libseccomp has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers