[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Brad Figg]

** Tags added: cscc

-- 
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 snapd:
  Fix Released
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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Zygmunt Krynicki]

This has been fixed now. Marking it as such.

** Project changed: snappy => snapd

** Changed in: snapd
   Status: In Progress => 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 snapd:
  Fix Released
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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Jamie Strandboge]

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 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:
  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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

I've successfully performed the testing described in the [libseccomp
Test Case] section of this bug description using libseccomp
2.3.1-2.1ubuntu2~16.04.1 from xenial-proposed.

-- 
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 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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-98.121

---
linux (4.4.0-98.121) xenial; urgency=low

  * linux: 4.4.0-98.121 -proposed tracker (LP: #1722299)

  * 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

  * Add installer support for Broadcom BCM573xx network drivers. (LP: #1720466)
- d-i: Add bnxt_en to nic-modules.

  * snapcraft.yaml: add dpkg-dev to the build deps (LP: #1718886)
- snapcraft.yaml: add dpkg-dev to the build deps

  * Support setting I2C_TIMEOUT via ioctl for i2c-designware (LP: #1718578)
- i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT

  * 5U84 - ses driver isn't binding right - cannot blink lights on 1 of the 2
5u84 (LP: #1693369)
- scsi_transport_sas: add function to get SAS endpoint address
- ses: fix discovery of SATA devices in SAS enclosures
- scsi: sas: provide stub implementation for scsi_is_sas_rphy
- scsi: ses: Fix SAS device detection in enclosure

  * 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

  * Support Dell Wireless DW5819/5818 WWAN devices (LP: #1721455)
- SAUCE: USB: serial: qcserial: add Dell DW5818, DW5819

  * CVE-2017-10911
- xen-blkback: don't leak stack data via response ring

  * implement 'complain mode' in seccomp for developer mode with snaps
(LP: #1567597)
- 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)
- 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

  * [Xenial] update OpenNSL kernel modules to 6.5.10 (LP: #1721511)
- SAUCE: update OpenNSL kernel modules to 6.5.10

  * Xenial update to 4.4.90 stable release (LP: #1721550)
- cifs: release auth_key.response for reconnect.
- mac80211: flush hw_roc_start work before cancelling the ROC
- KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
- tracing: Fix trace_pipe behavior for instance traces
- tracing: Erase irqsoff trace with empty write
- md/raid5: fix a race condition in stripe batch
- md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list
- scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse
  nlmsg properly
- crypto: talitos - Don't provide setkey for non hmac hashing algs.
- crypto: talitos - fix sha224
- KEYS: fix writing past end of user-supplied buffer in keyring_read()
- KEYS: prevent creating a different user's keyrings
- KEYS: prevent KEYCTL_READ on negative key
- powerpc/pseries: Fix parent_dn reference leak in add_dt_node()
- Fix SMB3.1.1 guest authentication to Samba
- SMB: Validate negotiate (to protect against downgrade) even if signing off
- SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags
- vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
- nl80211: check for the required netlink attributes presence
- bsg-lib: don't free job in bsg_prepare_job
- seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()
- arm64: Make sure SPsel is always set
- arm64: fault: Route pte translation faults via do_translation_fault
- KVM: VMX: Do not BUG() on out-of-bounds guest IRQ
- kvm: nVMX: Don't allow L2 to access the hardware CR8
- PCI: Fix race condition with driver_override
- btrfs: fix NULL pointer dereference from free_reloc_roots()
- btrfs: propagate error to btrfs_cmp_data_prepare caller
- btrfs: prevent to set invalid default subvolid
- x86/fpu: Don't let userspace set bogus xcomp_bv
- gfs2: Fix debugfs glocks dump
- timer/sysclt: Restrict timer migration sysctl values to 0 and 1
- KVM: VMX: do not change SN bit in vmx_update_pi_irte()
- KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt
- cxl: Fix driver use count
- dmaengine: mmp-pdma: add number of requestors
- ARM: pxa: add the number of DMA requestor lines
- ARM: pxa: fix the number of DMA requestor lines
- KVM: VMX: use 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.4.0-98.121

---
linux (4.4.0-98.121) xenial; urgency=low

  * linux: 4.4.0-98.121 -proposed tracker (LP: #1722299)

  * 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

  * Add installer support for Broadcom BCM573xx network drivers. (LP: #1720466)
- d-i: Add bnxt_en to nic-modules.

  * snapcraft.yaml: add dpkg-dev to the build deps (LP: #1718886)
- snapcraft.yaml: add dpkg-dev to the build deps

  * Support setting I2C_TIMEOUT via ioctl for i2c-designware (LP: #1718578)
- i2c: designware: Use transfer timeout from ioctl I2C_TIMEOUT

  * 5U84 - ses driver isn't binding right - cannot blink lights on 1 of the 2
5u84 (LP: #1693369)
- scsi_transport_sas: add function to get SAS endpoint address
- ses: fix discovery of SATA devices in SAS enclosures
- scsi: sas: provide stub implementation for scsi_is_sas_rphy
- scsi: ses: Fix SAS device detection in enclosure

  * 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

  * Support Dell Wireless DW5819/5818 WWAN devices (LP: #1721455)
- SAUCE: USB: serial: qcserial: add Dell DW5818, DW5819

  * CVE-2017-10911
- xen-blkback: don't leak stack data via response ring

  * implement 'complain mode' in seccomp for developer mode with snaps
(LP: #1567597)
- 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)
- 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

  * [Xenial] update OpenNSL kernel modules to 6.5.10 (LP: #1721511)
- SAUCE: update OpenNSL kernel modules to 6.5.10

  * Xenial update to 4.4.90 stable release (LP: #1721550)
- cifs: release auth_key.response for reconnect.
- mac80211: flush hw_roc_start work before cancelling the ROC
- KVM: PPC: Book3S: Fix race and leak in kvm_vm_ioctl_create_spapr_tce()
- tracing: Fix trace_pipe behavior for instance traces
- tracing: Erase irqsoff trace with empty write
- md/raid5: fix a race condition in stripe batch
- md/raid5: preserve STRIPE_ON_UNPLUG_LIST in break_stripe_batch_list
- scsi: scsi_transport_iscsi: fix the issue that iscsi_if_rx doesn't parse
  nlmsg properly
- crypto: talitos - Don't provide setkey for non hmac hashing algs.
- crypto: talitos - fix sha224
- KEYS: fix writing past end of user-supplied buffer in keyring_read()
- KEYS: prevent creating a different user's keyrings
- KEYS: prevent KEYCTL_READ on negative key
- powerpc/pseries: Fix parent_dn reference leak in add_dt_node()
- Fix SMB3.1.1 guest authentication to Samba
- SMB: Validate negotiate (to protect against downgrade) even if signing off
- SMB3: Don't ignore O_SYNC/O_DSYNC and O_DIRECT flags
- vfs: Return -ENXIO for negative SEEK_HOLE / SEEK_DATA offsets
- nl80211: check for the required netlink attributes presence
- bsg-lib: don't free job in bsg_prepare_job
- seccomp: fix the usage of get/put_seccomp_filter() in seccomp_get_filter()
- arm64: Make sure SPsel is always set
- arm64: fault: Route pte translation faults via do_translation_fault
- KVM: VMX: Do not BUG() on out-of-bounds guest IRQ
- kvm: nVMX: Don't allow L2 to access the hardware CR8
- PCI: Fix race condition with driver_override
- btrfs: fix NULL pointer dereference from free_reloc_roots()
- btrfs: propagate error to btrfs_cmp_data_prepare caller
- btrfs: prevent to set invalid default subvolid
- x86/fpu: Don't let userspace set bogus xcomp_bv
- gfs2: Fix debugfs glocks dump
- timer/sysclt: Restrict timer migration sysctl values to 0 and 1
- KVM: VMX: do not change SN bit in vmx_update_pi_irte()
- KVM: VMX: remove WARN_ON_ONCE in kvm_vcpu_trigger_posted_interrupt
- cxl: Fix driver use count
- dmaengine: mmp-pdma: add number of requestors
- ARM: pxa: add the number of DMA requestor lines
- ARM: pxa: fix the number of DMA requestor lines
- KVM: VMX: use 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

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   Tue, 10 Oct
2017 13:49:34 +0200

-- 
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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

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   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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

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

---
libseccomp (2.3.1-2.1ubuntu2~17.04.1) zesty; urgency=medium

  * Backport artful's libseccomp to zesty (LP: #1567597)
- Add support for the SECCOMP_RET_LOG action

libseccomp (2.3.1-2.1ubuntu2) artful; urgency=medium

  * add-log-action.patch: Minimal backport to support the SECCOMP_RET_LOG
action that will be released in Linux kernel version 4.14. (LP: #1567597)

 -- Tyler Hicks   Fri, 06 Oct 2017 18:43:11 +

** Changed in: libseccomp (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 Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

I tested the linux kernel SRU in Xenial and Zesty using the following
linux package versions:

 - xenial: linux-image-4.4.0-98-generic 4.4.0-98.121
 - zesty: linux-image-4.10.0-38-generic 4.10.0-38.42

The linux kernel SRU testing was successful and followed what's
documented in the [Linux Kernel Test Case] section of this bug
description. The accompanying libseccomp SRU has not been accepted into
xenial-proposed yet so I was unable to test lp1567597-test.c (although I
could test with lp1567597-kernel-test.c), as documented in the
[libseccomp Test Case] section but that's not a problem as the lp1567597
-kernel-test.c program and kernel selftests are sufficient.


** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

** Tags removed: verification-needed

-- 
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 Committed
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  If you have an updated libseccomp with an old kernel, you'll see that
  seccomp_init() fails due to the added 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Kleber Sacilotto de Souza]

This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
xenial' to 'verification-done-xenial'. If the problem still exists,
change the tag 'verification-needed-xenial' to 'verification-failed-
xenial'.

If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!


** Tags added: verification-needed-xenial

-- 
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 Committed
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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: 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

Hi - I tested the libseccomp SRU in Zesty using the following libseccomp
package version:

 - libseccomp2 2.3.1-2.1ubuntu2~17.04.1

I tested it with the following kernels:

 - linux-image-4.10.0-37-generic 4.10.0-37.41
   + does not contain seccomp logging patches
 - linux-image-4.10.0-38-generic 4.10.0-38.42
   + contains seccomp logging patches
   + installed from zesty-proposed

The libseccomp SRU testing was successful and followed what's documented
in the [libseccomp Test Case] section of this bug description.

** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty

-- 
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 Committed
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Brian Murray]

Hello Jamie, or anyone else affected,

Accepted libseccomp into zesty-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/libseccomp/2.3.1-2.1ubuntu2~17.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-zesty to verification-done-zesty. If it does not fix
the bug for you, please add a comment stating that, and change the tag
to verification-failed-zesty. 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 Zesty)
   Status: In Progress => Fix Committed

** Tags added: verification-needed verification-needed-zesty

-- 
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 Committed
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

Here's the kernel test case that I mentioned in the bug description.

** Attachment added: "lp1567597-kernel-test.c"
   
https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4967858/+files/lp1567597-kernel-test.c

-- 
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:
  In Progress
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Thadeu Lima de Souza Cascardo]

** Changed in: linux (Ubuntu Zesty)
   Status: In Progress => Fix Committed

-- 
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:
  In Progress
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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. 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Thadeu Lima de Souza Cascardo]

** Changed in: linux (Ubuntu Xenial)
   Status: In Progress => Fix Committed

-- 
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:
  In Progress
Status in linux source package in Zesty:
  Fix Committed

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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. 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

The Xenial and Zesty kernel patch sets have been sent to the kernel
team:

https://lists.ubuntu.com/archives/kernel-team/2017-October/087448.html
https://lists.ubuntu.com/archives/kernel-team/2017-October/087456.html

I've uploaded a libseccomp SRU to zesty-proposed. The Xenial SRU is
going to be trickier. It may require bring Zesty's libseccomp back to
Xenial due to the current version of libseccomp in Xenial not fully
supporting the seccomp(2) system call. That system call is needed to
verify kernel support of the SECCOMP_RET_LOG action that's needed for
devmode.

-- 
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:
  In Progress
Status in libseccomp source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  In Progress

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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

** Description changed:

  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-1):
  
  $ 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-1 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=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc
  
  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

** Description changed:

  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.
  
- [Test Case]
+ [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-1):
  
  $ 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-1 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=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc
  
  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.
+ 
  [Regression Potential]
  
  Relatively small 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.

-- 
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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

** Changed in: snappy
   Status: Confirmed => In Progress

-- 
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:
  In Progress
Status in libseccomp source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  In Progress

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.

  [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-1):

  $ 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-1 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=c03e syscall=2
  compat=0 ip=0x7f547352c5c0 code=0x7ffc

  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

  [Regression Potential]

  Relatively small 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.

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 : 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

** Description changed:

  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.
  
  [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-1):
  
  $ 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-1 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
  
- The exit code should be 0 and you should have an entry in the system log
- that looks like this:
+ 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=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc
+ 
+ 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
  
  [Regression Potential]
  
  Relatively small 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.

-- 
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:
  Confirmed
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:
  In Progress
Status in libseccomp source package in Zesty:
  In Progress
Status in linux source package in Zesty:
  In Progress

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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

SCMP_ACT_LOG test for libseccomp.

** Description changed:

  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.
+ 
+ [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-1):
+ 
+ $ sudo apt build-dep -y libseccomp
+ $ sudo apt install -y cython
+ $ apt source libseccomp
+ $ autoreconf -ivf && ./configure --enable-python && make check-build
+ $ (cd tests && ./regression -T live)
+ ...
+ Test 20-live-basic_die%%002-1 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
+ 
+ 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=c03e syscall=2 compat=0 ip=0x7f547352c5c0 code=0x7ffc
+ 
+ [Regression Potential]
+ 
+ Relatively small 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.

** Summary changed:

- implement 'complain mode' in seccomp for developer mode with snaps
+ [FFe] implement 'complain mode' in seccomp for developer mode with snaps

** Attachment added: "lp1567597-test.c"
   
https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953120/+files/lp1567597-test.c

** Description changed:

  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 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Launchpad Bug Tracker]

This bug was fixed in the package linux - 4.12.0-13.14

---
linux (4.12.0-13.14) artful; urgency=low

  * linux: 4.12.0-13.14 -proposed tracker (LP: #1714687)

  * vhost guest network randomly drops under stress (kvm) (LP: #1711251)
- Revert "vhost: cache used event for better performance"

  * EDAC sbridge: Failed to register device with error -22. (LP: #1714112)
- [Config] CONFIG_EDAC_GHES=n

  * Artful update to v4.12.10 stable release (LP: #1714525)
- sparc64: remove unnecessary log message
- bonding: require speed/duplex only for 802.3ad, alb and tlb
- bonding: ratelimit failed speed/duplex update warning
- af_key: do not use GFP_KERNEL in atomic contexts
- dccp: purge write queue in dccp_destroy_sock()
- dccp: defer ccid_hc_tx_delete() at dismantle time
- ipv4: fix NULL dereference in free_fib_info_rcu()
- net_sched/sfq: update hierarchical backlog when drop packet
- net_sched: remove warning from qdisc_hash_add
- bpf: fix bpf_trace_printk on 32 bit archs
- net: igmp: Use ingress interface rather than vrf device
- openvswitch: fix skb_panic due to the incorrect actions attrlen
- ptr_ring: use kmalloc_array()
- ipv4: better IP_MAX_MTU enforcement
- nfp: fix infinite loop on umapping cleanup
- tun: handle register_netdevice() failures properly
- sctp: fully initialize the IPv6 address in sctp_v6_to_addr()
- tipc: fix use-after-free
- ipv6: reset fn->rr_ptr when replacing route
- ipv6: repair fib6 tree in failure case
- tcp: when rearming RTO, if RTO time is in past then fire RTO ASAP
- net/mlx4_core: Enable 4K UAR if SRIOV module parameter is not enabled
- irda: do not leak initialized list.dev to userspace
- net: sched: fix NULL pointer dereference when action calls some targets
- net_sched: fix order of queue length updates in qdisc_replace()
- bpf, verifier: add additional patterns to evaluate_reg_imm_alu
- bpf: fix mixed signed/unsigned derived min/max value bounds
- bpf/verifier: fix min/max handling in BPF_SUB
- Input: trackpoint - add new trackpoint firmware ID
- Input: elan_i2c - add ELAN0602 ACPI ID to support Lenovo Yoga310
- Input: ALPS - fix two-finger scroll breakage in right side on ALPS 
touchpad
- KVM: s390: sthyi: fix sthyi inline assembly
- KVM: s390: sthyi: fix specification exception detection
- KVM: x86: simplify handling of PKRU
- KVM, pkeys: do not use PKRU value in vcpu->arch.guest_fpu.state
- KVM: x86: block guest protection keys unless the host has them enabled
- ALSA: usb-audio: Add delay quirk for H650e/Jabra 550a USB headsets
- ALSA: core: Fix unexpected error at replacing user TLV
- ALSA: hda - Add stereo mic quirk for Lenovo G50-70 (17aa:3978)
- ALSA: firewire: fix NULL pointer dereference when releasing uninitialized
  data of iso-resource
- ALSA: firewire-motu: destroy stream data surely at failure of card
  initialization
- ARCv2: SLC: Make sure busy bit is set properly for region ops
- ARCv2: PAE40: Explicitly set MSB counterpart of SLC region ops addresses
- ARCv2: PAE40: set MSB even if !CONFIG_ARC_HAS_PAE40 but PAE exists in SoC
- PM/hibernate: touch NMI watchdog when creating snapshot
- mm, shmem: fix handling /sys/kernel/mm/transparent_hugepage/shmem_enabled
- dax: fix deadlock due to misaligned PMD faults
- i2c: designware: Fix system suspend
- mm/madvise.c: fix freeing of locked page with MADV_FREE
- fork: fix incorrect fput of ->exe_file causing use-after-free
- mm/memblock.c: reversed logic in memblock_discard()
- arm64: fpsimd: Prevent registers leaking across exec
- drm: Fix framebuffer leak
- drm: Release driver tracking before making the object available again
- drm/sun4i: Implement drm_driver lastclose to restore fbdev console
- drm/atomic: Handle -EDEADLK with out-fences correctly
- drm/atomic: If the atomic check fails, return its value first
- drm/i915/vbt: ignore extraneous child devices for a port
- drm/i915/gvt: Fix the kernel null pointer error
- Revert "drm/amdgpu: fix vblank_time when displays are off"
- ACPI: device property: Fix node lookup in 
acpi_graph_get_child_prop_value()
- tracing: Call clear_boot_tracer() at lateinit_sync
- tracing: Missing error code in tracer_alloc_buffers()
- tracing: Fix kmemleak in tracing_map_array_free()
- tracing: Fix freeing of filter in create_filter() when set_str is false
- RDMA/uverbs: Initialize cq_context appropriately
- kbuild: linker script do not match C names unless
  LD_DEAD_CODE_DATA_ELIMINATION is configured
- cifs: Fix df output for users with quota limits
- cifs: return ENAMETOOLONG for overlong names in cifs_open()/cifs_lookup()
- nfsd: Limit end of page list when decoding NFSv4 WRITE
- ring-buffer: Have ring_buffer_alloc_read_page() return error on offline 
CPU
- virtio_pci: fix 

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

@zyga those are both good questions.

- Detection functionality is included in kernel patches. There's a new
seccomp(2) operation to check if the log action is available and an
added test to ensure that there's a certain combination of valid/invalid
seccomp(2) arguments that can be used to detect if the log filter flag
is available. Both of these checks will be embedded into libseccomp and
the checks will be carried out when the calling code specifies actions
and filter flags.

- Making the necessary libseccomp-golang changes is something that I
plan to do. I need to hear back from the libseccomp PR first and then
will proceed to make the libseccomp-golang changes that match the
libseccomp changes.

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  Fix Committed

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).

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

Re: [Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Zygmunt Krynicki]

Hey Tyler, thank you for the update, this looks very promising indeed.

I'd like to ask about two aspects:

- detection, how can we detect that this feature is available? Shall
we just compile a program and see if it loads on snapd startup?
- golang, we use golang bindings to libseccomp and we will need to
adjust them to expose the new APIs (presumably). Is this something you
plan to handle as well?

Thanks
ZK

On Mon, Aug 28, 2017 at 3:15 PM, Tyler Hicks  wrote:
> The kernel patches were committed to the Ubuntu Artful kernel git repo:
> https://lists.ubuntu.com/archives/kernel-team/2017-August/086714.html
>
> ** Changed in: linux (Ubuntu)
>Status: In Progress => Fix Committed
>
> --
> You received this bug notification because you are a member of Snappy
> Developers, which is subscribed to Snappy.
> Matching subscriptions: xxx-bugs-on-snapd
> https://bugs.launchpad.net/bugs/1567597
>
> Title:
>   implement 'complain mode' in seccomp for developer mode with snaps
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1567597/+subscriptions

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  Fix Committed

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).

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

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

The kernel patches were committed to the Ubuntu Artful kernel git repo:
https://lists.ubuntu.com/archives/kernel-team/2017-August/086714.html

** Changed in: linux (Ubuntu)
   Status: In Progress => Fix Committed

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  Fix Committed

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).

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

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Kyle Fazzari]

Thanks for the update, Tyler. I know this has been a long road, but the
cumulative effect of everyone's hard work on this particular front will
be huge. I'm very much looking forward to this.

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

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).

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

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

A status update is in order. We settled on a design that meets
everyone's kernel needs. Those patches have been accepted into linux-
next and they're on their way into 4.14.

  https://lkml.kernel.org/r/%3C20170815220319.GA63342@beast%3E

I've submitted Artful backports to the kernel team:

  https://lists.ubuntu.com/archives/kernel-team/2017-August/086691.html

I've reached out to the libseccomp maintainer to discuss some design
aspects that needed to be sorted out and now I've proposed a PR for
libseccomp:

  https://github.com/seccomp/libseccomp/pull/92

I'll have a little more work to do on libseccomp-golang once the
libseccomp PR is reviewed. Then I can start the SRUs. The snap-seccomp
/snap-confine changes are straightforward and small so they shouldn't be
a problem.

Everything is finally coming together but there have been a lot of
moving pieces (and people) involved in landing all the changes.

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

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).

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

[Kernel-packages] [Bug 1567597] Re: implement 'complain mode' in seccomp for developer mode with snaps

[Tyler Hicks]

** Also affects: linux (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu)
   Status: New => In Progress

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

** Changed in: libseccomp (Ubuntu)
 Assignee: (unassigned) => Tyler Hicks (tyhicks)

-- 
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:
  Confirmed
Status in linux package in Ubuntu:
  In Progress

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).

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