libseccomp-2.4.0

[Douglas R. Reno]

New minor version

[Bruce Dubbs]

Version 2.4.0 - March 14, 2019

• Update the syscall table for Linux v5.0-rc5
• Added support for the SCMP_ACT_KILL_PROCESS action
• Added support for the SCMP_ACT_LOG action and SCMP_FLTATR_CTL_LOG attribute
• Added explicit 32-bit (SCMP_AX_32(...)) and 64-bit (SCMP_AX_64(...)) argument comparison macros to help protect against unexpected sign extension
• Added support for the parisc and parisc64 architectures
• Added the ability to query and set the libseccomp API level via seccomp_api_get(3) and seccomp_api_set(3)
• Return -EDOM on an endian mismatch when adding an architecture to a filter
• Renumber the pseudo syscall number for subpage_prot() so it no longer conflicts with spu_run()
• Fix PFC generation when a syscall is prioritized, but no rule exists
• Numerous fixes to the seccomp-bpf filter generation code
• Switch our internal hashing function to jhash/Lookup3 to MurmurHash3
• Numerous tests added to the included test suite, coverage now at ~92%
• Update our Travis CI configuration to use Ubuntu 16.04
• Numerous documentation fixes and updates

[Bruce Dubbs]

Fixed at revision 21335.

[Douglas R. Reno]

Jann Horn (CC'd) identified a problem in current versions of
libseccomp where the library did not correctly generate 64-bit syscall
argument comparisons using the arithmetic operators (LT, GT, LE, GE).
Jann has done a search using codesearch.debian.net and it would appear
that only systemd and Tor are using libseccomp in such a way as to
trigger the bad code.  In the case of systemd this appears to affect
the socket address family and scheduling class filters.  In the case
of Tor it appears that the bad filters could impact the memory
addresses passed to mprotect(2).

The libseccomp v2.4.0 release fixes this problem, and should be a
direct drop-in replacement for previous v2.x releases.  Due the
complexity, and associated risk, of backporting the fix to the v2.3.x
release stream, I've made the difficult decision not to backport the
fix.  Further, I'm not aware of any workarounds for this issue.
Adminstrators and distros are strongly encouraged to upgrade to
libseccomp v2.4.0 as soon as possible.

The related GitHub issue, complete with a brief discussion of the
problem and a list of the assocated patches can be found at the link
below:

* https://github.com/seccomp/libseccomp/issues/139

The libseccomp v2.4.0 release can be found at the link below:

* https://github.com/seccomp/libseccomp/releases/tag/v2.4.0

-- 
paul moore
www.paul-moore.com

[Bruce Dubbs]

Milestone renamed