group.of.nepali.translators team mailing list archive

[Jamie Strandboge <jamie@xxxxxxxxxx>]

This is fixed in xenial 2.3.1-2.1ubuntu2~16.04.1

** Changed in: libseccomp (Ubuntu Xenial)
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
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