Activity log for bug #1721676

Date Who What changed Old value New value Message
2017-10-06 02:15:34 Tyler Hicks bug added bug
2017-10-06 02:16:01 Tyler Hicks bug task added linux (Ubuntu)
2017-10-06 02:16:16 Tyler Hicks nominated for series Ubuntu Artful
2017-10-06 02:16:16 Tyler Hicks bug task added linux (Ubuntu Artful)
2017-10-06 02:16:16 Tyler Hicks nominated for series Ubuntu Zesty
2017-10-06 02:16:16 Tyler Hicks bug task added linux (Ubuntu Zesty)
2017-10-06 02:16:16 Tyler Hicks nominated for series Ubuntu Xenial
2017-10-06 02:16:16 Tyler Hicks bug task added linux (Ubuntu Xenial)
2017-10-06 02:16:23 Tyler Hicks linux (Ubuntu Xenial): status New In Progress
2017-10-06 02:16:26 Tyler Hicks linux (Ubuntu Xenial): assignee Tyler Hicks (tyhicks)
2017-10-06 02:16:29 Tyler Hicks linux (Ubuntu Zesty): status New In Progress
2017-10-06 02:16:31 Tyler Hicks linux (Ubuntu Zesty): assignee Tyler Hicks (tyhicks)
2017-10-06 02:16:39 Tyler Hicks linux (Ubuntu Artful): status New Fix Released
2017-10-06 02:16:41 Tyler Hicks linux (Ubuntu Artful): assignee Tyler Hicks (tyhicks)
2017-10-06 02:24:14 Tyler Hicks description A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help 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 ============================================================ [Regression Potential] 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 quite any additional logging.
2017-10-06 03:09:15 Tyler Hicks description A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help 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 ============================================================ [Regression Potential] 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 quite any additional logging. A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help 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 run a single test to verify that SECCOMP_RET_ERRNO is logged when the application opts into it. First, verify that "errno" 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 lp1721676-kernel-test lp1721676-kernel-test.c $ ./lp1721676-kernel-test SUCCESS: getpid() failed as expected: Operation not permitted It should have generated a message like this in /var/log/syslog: kernel: [79338.804966] audit: type=1326 audit(1507259221.875:27): auid=1000 uid=1000 gid=1000 ses=5 pid=3091 comm="lp1721676-kerne" exe="/home/tyhicks/lp1721676-kernel-test" sig=0 arch=c000003e syscall=39 compat=0 ip=0x7fb91829c499 code=0x50000 Disable errno logging in the sysctl: $ echo kill trap trace log | sudo tee /proc/sys/kernel/seccomp/actions_logged kill trap trace log Rerun the test program and ensure that nothing was logged this time. [Regression Potential] 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 quite any additional logging.
2017-10-06 03:59:28 Tyler Hicks description A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help 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 run a single test to verify that SECCOMP_RET_ERRNO is logged when the application opts into it. First, verify that "errno" 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 lp1721676-kernel-test lp1721676-kernel-test.c $ ./lp1721676-kernel-test SUCCESS: getpid() failed as expected: Operation not permitted It should have generated a message like this in /var/log/syslog: kernel: [79338.804966] audit: type=1326 audit(1507259221.875:27): auid=1000 uid=1000 gid=1000 ses=5 pid=3091 comm="lp1721676-kerne" exe="/home/tyhicks/lp1721676-kernel-test" sig=0 arch=c000003e syscall=39 compat=0 ip=0x7fb91829c499 code=0x50000 Disable errno logging in the sysctl: $ echo kill trap trace log | sudo tee /proc/sys/kernel/seccomp/actions_logged kill trap trace log Rerun the test program and ensure that nothing was logged this time. [Regression Potential] 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 quite any additional logging. A requirement for snappy is that security sandbox violations against policy are logged. In this manner learning tools can be written to parse the logs, etc and make developing on snappy easier. The current default seccomp action, in strict mode. is to kill the snap's thread that violated the policy but this is unfriendly to the developer and to the user. The desired action is to block the illegal system call and return an error with errno set to EPERM. However, seccomp does not emit log events when it takes that action. Seccomp should be updated to emit log events when taking the SECCOMP_RET_ERRNO action and then snappy can switch to the using that action when blocking illegal system calls. [Impact] Snapd needs a way to log SECCOMP_RET_ERRNO seccomp actions in order to have a more friendly strict mode. Such functionality has been merged upstream into 4.14-rc2. No libseccomp changes are needed at this time since snap-confine loads the BPF filter directly into the kernel without using libseccomp. [Test Case] Running the libseccomp "live" tests will exercise the kernel's seccomp enforcement and help 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 ============================================================ ---------------------------- 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_ERRNO is logged when the application opts into it. First, verify that "errno" 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 lp1721676-kernel-test lp1721676-kernel-test.c $ ./lp1721676-kernel-test SUCCESS: getpid() failed as expected: Operation not permitted It should have generated a message like this in /var/log/syslog: kernel: [79338.804966] audit: type=1326 audit(1507259221.875:27): auid=1000 uid=1000 gid=1000 ses=5 pid=3091 comm="lp1721676-kerne" exe="/home/tyhicks/lp1721676-kernel-test" sig=0 arch=c000003e syscall=39 compat=0 ip=0x7fb91829c499 code=0x50000 Disable errno logging in the sysctl: $ echo kill trap trace log | sudo tee /proc/sys/kernel/seccomp/actions_logged kill trap trace log Rerun the test program and ensure that nothing was logged this time. [Regression Potential] 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 quite any additional logging.
2017-10-06 18:21:49 Thadeu Lima de Souza Cascardo linux (Ubuntu Xenial): status In Progress Fix Committed
2017-10-06 18:27:22 Thadeu Lima de Souza Cascardo linux (Ubuntu Zesty): status In Progress Fix Committed
2017-10-11 18:44:05 Tyler Hicks attachment added lp1721676-kernel-test.c https://bugs.launchpad.net/snappy/+bug/1721676/+attachment/4967859/+files/lp1721676-kernel-test.c
2017-10-18 08:56:50 Kleber Sacilotto de Souza tags verification-needed-xenial
2017-10-18 08:59:14 Kleber Sacilotto de Souza tags verification-needed-xenial verification-needed-xenial verification-needed-zesty
2017-10-18 23:09:09 Tyler Hicks tags verification-needed-xenial verification-needed-zesty verification-done-xenial verification-done-zesty
2017-10-30 19:26:53 Launchpad Janitor linux (Ubuntu Zesty): status Fix Committed Fix Released
2017-10-30 19:26:53 Launchpad Janitor cve linked 2017-1000252
2017-10-30 19:26:53 Launchpad Janitor cve linked 2017-10663
2017-10-30 19:26:53 Launchpad Janitor cve linked 2017-10911
2017-10-30 19:26:53 Launchpad Janitor cve linked 2017-11176
2017-10-30 19:26:53 Launchpad Janitor cve linked 2017-14340
2017-10-30 19:43:07 Launchpad Janitor linux (Ubuntu Xenial): status Fix Committed Fix Released
2019-10-29 18:16:10 Zygmunt Krynicki snappy: status In Progress Fix Released
2019-10-29 18:16:17 Zygmunt Krynicki affects snappy snapd