This bug was fixed in the package linux - 4.10.0-38.42
---------------
linux (4.10.0-38.42) zesty; urgency=low
* linux: 4.10.0-38.42 -proposed tracker (LP: #1722330)
* Controller lockup detected on ProLiant DL380 Gen9 with P440 Controller
(LP: #1720359)
- scsi: hpsa: limit transfer length to 1MB
* [Dell Docking IE][0bda:8153] Realtek USB Ethernet leads to system hang
(LP: #1720977)
- r8152: fix the list rx_done may be used without initialization
* Touchpad not detected in Lenovo X1 Yoga / Yoga 720-15IKB (LP: #1700657)
- mfd: intel-lpss: Add missing PCI ID for Intel Sunrise Point LPSS devices
* Add installer support for Broadcom BCM573xx network drivers. (LP: #1720466)
- d-i: Add bnxt_en to nic-modules.
* CVE-2017-1000252
- KVM: VMX: Do not BUG() on out-of-bounds guest IRQ
* CVE-2017-10663
- f2fs: sanity check checkpoint segno and blkoff
* xfstest sanity checks on seek operations fails (LP: #1696049)
- xfs: fix off-by-one on max nr_pages in xfs_find_get_desired_pgoff()
* [P9, Power NV][ WSP][Ubuntu 16.04.03] : perf hw breakpoint command results
in call traces and system goes for reboot. (LP: #1706033)
- powerpc/64s: Handle data breakpoints in Radix mode
* 5U84 - ses driver isn't binding right - cannot blink lights on 1 of the 2
5u84 (LP: #1693369)
- scsi: ses: do not add a device to an enclosure if enclosure_add_links()
fails.
* Vlun resize request could fail with cxlflash driver (LP: #1713575)
- scsi: cxlflash: Fix vlun resize failure in the shrink path
* More migrations with constant load (LP: #1713576)
- sched/fair: Prefer sibiling only if local group is under-utilized
* New PMU fixes for marked events. (LP: #1716491)
- powerpc/perf: POWER9 PMU stops after idle workaround
* CVE-2017-14340
- xfs: XFS_IS_REALTIME_INODE() should be false if no rt device present
* [Zesty][Yakkety] rtl8192e bug fixes (LP: #1698470)
- staging: rtl8192e: rtl92e_fill_tx_desc fix write to mapped out memory.
- staging: rtl8192e: fix 2 byte alignment of register BSSIDR.
- staging: rtl8192e: rtl92e_get_eeprom_size Fix read size of EPROM_CMD.
- staging: rtl8192e: GetTs Fix invalid TID 7 warning.
* Stranded with ENODEV after mdadm --readonly (LP: #1706243)
- md: MD_CLOSING needs to be cleared after called md_set_readonly or
do_md_stop
* multipath -ll is not showing the disks which are actually multipath
(LP: #1718397)
- fs: aio: fix the increment of aio-nr and counting against aio-max-nr
* ETPS/2 Elantech Touchpad inconsistently detected (Gigabyte P57W laptop)
(LP: #1594214)
- Input: i8042 - add Gigabyte P57 to the keyboard reset table
* CVE-2017-10911
- xen-blkback: don't leak stack data via response ring
* CVE-2017-11176
- mqueue: fix a use-after-free in sys_mq_notify()
* implement 'complain mode' in seccomp for developer mode with snaps
(LP: #1567597)
- Revert "UBUNTU: SAUCE: seccomp: log actions even when audit is disabled"
- seccomp: Provide matching filter for introspection
- seccomp: Sysctl to display available actions
- seccomp: Operation for checking if an action is available
- seccomp: Sysctl to configure actions that are allowed to be logged
- seccomp: Selftest for detection of filter flag support
- seccomp: Action to log before allowing
* implement errno action logging in seccomp for strict mode with snaps
(LP: #1721676)
- Revert "UBUNTU: SAUCE: seccomp: log actions even when audit is disabled"
- seccomp: Provide matching filter for introspection
- seccomp: Sysctl to display available actions
- seccomp: Operation for checking if an action is available
- seccomp: Sysctl to configure actions that are allowed to be logged
- seccomp: Selftest for detection of filter flag support
- seccomp: Filter flag to log all actions except SECCOMP_RET_ALLOW
* Backport recent bbr bugfixes to 4.10 kernel (LP: #1708604)
- tcp_bbr: cut pacing rate only if filled pipe
- tcp_bbr: introduce bbr_bw_to_pacing_rate() helper
- tcp_bbr: introduce bbr_init_pacing_rate_from_rtt() helper
- tcp_bbr: remove sk_pacing_rate=0 transient during init
- tcp_bbr: init pacing rate on first RTT sample
* [SRU][Zesty] Fix lscpu segfault on ARM64 with SMBIOS v2.0 (LP: #1716483)
- arm64: kernel: restrict /dev/mem read() calls to linear region
-- Kleber Sacilotto de Souza <kleber.so...@canonical.com> Tue, 10 Oct
2017 13:49:34 +0200
** Changed in: linux (Ubuntu Zesty)
Status: Fix Committed => Fix Released
** CVE added: https://cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-1000252
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-10663
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-10911
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-11176
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14340
** Changed in: linux (Ubuntu Zesty)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1567597
Title:
implement 'complain mode' in seccomp for developer mode with snaps
Status in Snappy:
In Progress
Status in libseccomp package in Ubuntu:
Fix Released
Status in linux package in Ubuntu:
Fix Released
Status in libseccomp source package in Xenial:
In Progress
Status in linux source package in Xenial:
Fix Committed
Status in libseccomp source package in Zesty:
Fix Released
Status in linux source package in Zesty:
Fix Released
Bug description:
A requirement for snappy is that a snap may be placed in developer
mode which will put the security sandbox in complain mode such that
violations against policy are logged, but permitted. In this manner
learning tools can be written to parse the logs, etc and make
developing on snappy easier.
Unfortunately with seccomp only SCMP_ACT_KILL logs to dmesg and while
we can set complain mode to permit all calls, they are not logged at
this time. I've discussed this with upstream and we are working
together on the approach. This may require a kernel patch and an
update to libseccomp, to filing this bug for now as a placeholder and
we'll add other tasks as necessary.
UPDATE: ubuntu-core-launcher now supports the '@complain' directive
that is a synonym for '@unrestricted' so people can at least turn on
developer mode and not be blocked by seccomp. Proper complain mode for
seccomp needs to still be implemented (this bug).
[Impact]
Snapd needs a way to log seccomp actions without blocking any syscalls
in order to have a more useful complain mode. Such functionality has
been acked upstream and patches are on their way into the Linux 4.14
kernel (backported to 4.12.0-13.14 in artful).
The corresponding libseccomp changes are still undergoing review
(https://github.com/seccomp/libseccomp/pull/92). The pull request adds
a number of new symbols and probably isn't appropriate to backport
until upstream has acked the pull request. However, only a small part
of that larger pull request is needed by snapd and that change can be
safely backported since the only added symbol, the SCMP_ACT_LOG macro,
must match the SECCOMP_RET_LOG macro that has already been approved
and merged in the upstream Linux kernel.
[libseccomp Test Case]
A large number of tests are ran as part of the libseccomp build.
However, the "live" tests which test libseccomp with actual kernel
enforcement are not ran at that time. They can be manually exercised
to help catch any regressions. Note that on Artful, there's an
existing test failure (20-live-basic_die%%002-00001):
$ sudo apt build-dep -y libseccomp
$ sudo apt install -y cython
$ apt source libseccomp
$ cd libseccomp-*
$ autoreconf -ivf && ./configure --enable-python && make check-build
$ (cd tests && ./regression -T live)
All tests should pass on zesty (12 tests) and xenial (10 tests). On artful,
you'll see one pre-existing failure:
...
Test 20-live-basic_die%%002-00001 result: FAILURE 20-live-basic_die TRAP
rc=159
...
Regression Test Summary
tests run: 12
tests skipped: 0
tests passed: 11
tests failed: 1
tests errored: 0
============================================================
----------------------------
Now we can build and run a small test program to test the SCMP_ACT_LOG
action in the way that snapd wants to use it for developer mode:
$ sudo apt install -y libseccomp-dev
$ gcc -o lp1567597-test lp1567597-test.c -lseccomp
$ ./lp1567597-test
With a kernel that contains the logging patches and an updated
libseccomp, the exit code should be 0 and you should have an entry in
the system log that looks like this:
audit: type=1326 audit(1505859630.994:69): auid=1000 uid=1000 gid=1000
ses=2 pid=18451 comm="lp1567597-test"
exe="/home/tyhicks/lp1567597-test" sig=0 arch=c000003e syscall=2
compat=0 ip=0x7f547352c5c0 code=0x7ffc0000
If you have an updated libseccomp with an old kernel, you'll see that
seccomp_init() fails due to the added compatibility check inside of
libseccomp determines that the kernel doesn't have proper support for
the new log action:
$ ./lp1567597-test
ERROR: seccomp_init: Invalid argument
[Linux Kernel Test Case]
All of the libseccomp test cases apply here.
----------------------------
Running the seccomp kernel selftests is also a great to exercise
seccomp and the kernel patch set proposed for the SRU includes
additional seccomp selftests. To build, enter into the root of the
kernel source tree and build the seccomp test binary:
$ make -C tools/testing/selftests TARGETS=seccomp
Now you can execute tools/testing/selftests/seccomp/seccomp_bpf or
even copy it to a test machine and run it there. On Xenial, 54/54
tests should pass and 58/58 should pass on Zesty.
----------------------------
Now we can run a single test to verify that SECCOMP_RET_LOG is logged
when the seccomp BPF evaluates to that action. First, verify that
"log" is listed in the actions_logged sysctl:
$ cat /proc/sys/kernel/seccomp/actions_logged
kill trap errno trace log
Now, build and run the test program:
$ gcc -o lp1567597-kernel-test lp1567597-kernel-test.c
$ ./1567597-kernel-test
SUCCESS!
It should have generated a message like this in /var/log/syslog:
audit: type=1326 audit(1507263417.752:60): auid=1000 uid=1000 gid=1000
ses=2 pid=3117 comm="lp1567597-kerne" exe="/home/tyhicks/lp1567597
-kernel-test" sig=0 arch=c000003e syscall=39 compat=0
ip=0x7f1d2d8409f9 code=0x7ffc0000
Disable "log" logging in the sysctl:
$ echo kill trap errno trace | sudo tee
/proc/sys/kernel/seccomp/actions_logged
kill trap errno trace
Rerun the test program and ensure that nothing was logged this time.
[Regression Potential]
Relatively small for libseccomp since the core logic is in the kernel
and we're only exposing the new action through libseccomp. The changes
include smarts to query the kernel to see if the action is available
in the kernel. Calling applications will not be able to use the action
on older kernels that don't support it.
The kernel patches received a lot of review between Kees and some
others interested in improved seccomp logging. I authored the patches
and feel comfortable/confident with my backported versions. They do
not change the behavior of seccomp logging by default but offer ways
applications to opt into more logging and, on the flipside, ways for
the administrator to quiet any additional logging.
To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1567597/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
