Ubuntu
libseccomp package

libseccomp should support GA and HWE kernels

Bug #1682102 reported by Dimitri John Ledkov
18
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libseccomp (Ubuntu)
Invalid
Undecided
Unassigned
Xenial
Fix Released
High
Dimitri John Ledkov

Bug Description

[Impact]

out of date libseccomp w.r.t. custom and hwe kernels provides sub-par userspace protection, which is otherwise available on the running kernel and hardware combination.
This results in subpar security of systems running new architectures (s390x & ppc64el) and newer hwe/custom kernels.

* Version 2.3.1 - April 20, 2016
- Fixed a problem with 32-bit x86 socket syscalls on some systems
- Fixed problems with ipc syscalls on 32-bit x86
- Fixed problems with socket and ipc syscalls on s390 and s390x

* Version 2.3.0 - February 29, 2016
- Added support for the s390 and s390x architectures
- Added support for the ppc, ppc64, and ppc64le architectures
- Update the internal syscall tables to match the Linux 4.5-rcX releases
- Filter generation for both multiplexed and direct socket syscalls on x86
- Support for the musl libc implementation
- Additions to the API to enable runtime version checking of the library
- Enable the use of seccomp() instead of prctl() on supported systems
- Added additional tests to the regression test suite

There is no ABI/API break

There are no packaging changes, apart from dropping patches included in this upstream release and updating new symbols.

Doing wholesome update is safer and carries less risk, than individually cherrypicking effectively all of the above.

This is a backport to an LTS release under the banner of safe introduction of new features and new hardware support.

It is expected that container technologies will take advantage of the newly available libseccomp.

This may need to be uploaded as a security update.

Currently, s390x support in xenial libssecomp is incomplete. And there are v4.5+ syscall tables missing as used by hwe kernels and some custom kernels.

[Testcase]
Validate that all main contianer technologies are operational and do not regress, e.g.:
 - lxc
 - lxd
 - docker
 - snapd

[Regression Potential]
Userspace components may detect at runtime newly available libseccomp, and thus restrict user-space processes more than previously done. This may lead to a change of restrictions applied on the user sapce processes, and result in previously unexpected denials / errors returned.

[Proposed Update available in bileto PPA]
https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2981

See original description
Dimitri John Ledkov (xnox)
Changed in libseccomp (Ubuntu Xenial):
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Dimitri John Ledkov (xnox)
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libseccomp (Ubuntu):
status: New → Confirmed
Revision history for this message
Tyler Hicks (tyhicks) wrote :

@xnox bringing zesty's libseccomp back to xenial may be needed for some kernel/snapd/libseccomp changes that I'm working on. Have you spent any time investigating such a change?

Dimitri John Ledkov (xnox)
description: updated
Dimitri John Ledkov (xnox)
description: updated
Revision history for this message
Christian Ehrhardt  (paelzer) wrote :

A 2.3.x in Xenial would also allow to drop some Delta that the Cloud Archive is adding to "drop" newer seccomp support we add for latter releases - so seconding Tyhicks question being interested as well.

Revision history for this message
Adam Conrad (adconrad) wrote :

I built this package in the ubuntu-security-proposed PPA so it can be released to both -updates and -security (which seems like probably a sane thing to do) once it's passed the SRU process.

Changed in libseccomp (Ubuntu Xenial):
status: Confirmed → Fix Committed
tags: added: verification-needed verification-needed-xenial
Revision history for this message
Adam Conrad (adconrad) wrote : Please test proposed package

Hello Dimitri, or anyone else affected,

Accepted libseccomp into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/libseccomp/2.3.1-2.1ubuntu2~16.04.1 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-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. 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):
status: Confirmed → Invalid
Revision history for this message
Tyler Hicks (tyhicks) wrote :

I've successfully performed the testing described in the [libseccomp Test Case] section of the bug 1567597 description using libseccomp 2.3.1-2.1ubuntu2~16.04.1 from xenial-proposed. It includes the libseccomp live tests (which aren't used during the build) and a specific test of the new seccomp logging functionality. (I'm mentioning my testing here because bug 1567597 isn't mentioned in the changelog of the SRU upload.)

Revision history for this message
Tyler Hicks (tyhicks) wrote :

As for the failing Xenial snapd autopkgtests...

- amd64: The autopkgtest:ubuntu-16.04-amd64:tests/main/completion fails with and without the libseccomp in xenial-proposed
- s390x: No tests are ever ran due to the tests requiring "machine-level isolation" but that not being available on s390x. However, snapd s390x test runs have been hitting an error for about the last month.

Both are false positives and should not be something that keeps libseccomp from migrating.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

snapd failure on s390x. We now do have machine isolation available, but the tests do not have anything to run:

+ /tmp/go/bin/spread -v autopkgtest:ubuntu-16.04-s390x
2017-12-11 23:35:01 Found /tmp/autopkgtest.ics8dn/build.mFy/src/spread.yaml.
error: nothing matches provider filter

This is a false negative; previous state was untested.

snapd failure on amd64:
2017-12-12 16:40:40 Failed tasks: 1
    - autopkgtest:ubuntu-16.04-amd64:tests/main/completion
error: unsuccessful run

Appears to be unrelated to libseccomp.

Revision history for this message
Dan Watkins (oddbloke) wrote :

snapd has migrated to xenial-updates without this change landing; unfortunately, that makes snapd uninstallable on powerpc (as that's the only architecture where it isn't statically compiled). snapd is installed during image builds, so this migration is currently blocking powerpc cloud images from building.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libseccomp - 2.3.1-2.1ubuntu2~16.04.1

---------------
libseccomp (2.3.1-2.1ubuntu2~16.04.1) xenial; urgency=medium

  * Backport libseccomp 2.3.1 to xenial LP: #1682102
    - Improved s390x support
    - Improved support for v4.5+ kernels

 -- Dimitri John Ledkov <email address hidden> Fri, 06 Oct 2017 14:47:39 +0100

Changed in libseccomp (Ubuntu Xenial):
status: Fix Committed → Fix Released
Revision history for this message
Steve Langasek (vorlon) wrote :

It would have expedited the release of this SRU if someone had retried the systemd/armhf autopkgtest failure, or provided some concrete analysis of why this test is expected to fail and does not need to be retried.

I've now retriggered that test, and it has passed. All of the failing autopkgtests are now accounted for.

tags: added: verification-done verification-done-xenial
removed: verification-needed verification-needed-xenial
Revision history for this message
Steve Langasek (vorlon) wrote :

And I have set the verification-done tag based on comment #6.

Francis Ginther (fginther)
tags: added: id-5a3bd5fa5445fb1d95040a5b
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.