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

2019-05-21 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.0.0-15.16

---
linux (5.0.0-15.16) disco; urgency=medium

  * CVE-2019-11683
- udp: fix GRO reception in case of length mismatch
- udp: fix GRO packet of death

  * CVE-2018-12126 // CVE-2018-12127 // CVE-2018-12130
- x86/msr-index: Cleanup bit defines
- x86/speculation: Consolidate CPU whitelists
- x86/speculation/mds: Add basic bug infrastructure for MDS
- x86/speculation/mds: Add BUG_MSBDS_ONLY
- x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
- x86/speculation/mds: Add mds_clear_cpu_buffers()
- x86/speculation/mds: Clear CPU buffers on exit to user
- x86/kvm/vmx: Add MDS protection when L1D Flush is not active
- x86/speculation/mds: Conditionally clear CPU buffers on idle entry
- x86/speculation/mds: Add mitigation control for MDS
- x86/speculation/mds: Add sysfs reporting for MDS
- x86/speculation/mds: Add mitigation mode VMWERV
- Documentation: Move L1TF to separate directory
- Documentation: Add MDS vulnerability documentation
- x86/speculation/mds: Add mds=full,nosmt cmdline option
- x86/speculation: Move arch_smt_update() call to after mitigation decisions
- x86/speculation/mds: Add SMT warning message
- x86/speculation/mds: Fix comment
- x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
- x86/speculation/mds: Add 'mitigations=' support for MDS

  * CVE-2017-5715 // CVE-2017-5753
- s390/speculation: Support 'mitigations=' cmdline option

  * CVE-2017-5715 // CVE-2017-5753 // CVE-2017-5754 // CVE-2018-3639
- powerpc/speculation: Support 'mitigations=' cmdline option

  * CVE-2017-5715 // CVE-2017-5754 // CVE-2018-3620 // CVE-2018-3639 //
CVE-2018-3646
- cpu/speculation: Add 'mitigations=' cmdline option
- x86/speculation: Support 'mitigations=' cmdline option

  * Packaging resync (LP: #1786013)
- [Packaging] resync git-ubuntu-log

linux (5.0.0-14.15) disco; urgency=medium

  * linux: 5.0.0-14.15 -proposed tracker (LP: #1826150)

  * [SRU] Please sync vbox modules from virtualbox 6.0.6 on next kernel update
(LP: #1825210)
- vbox-update: updates for renamed makefiles
- ubuntu: vbox -- update to 6.0.6-dfsg-1

  * Intel I210 Ethernet card not working after hotplug [8086:1533]
(LP: #1818490)
- igb: Fix WARN_ONCE on runtime suspend

  * [regression][snd_hda_codec_realtek] repeating crackling noise after 19.04
upgrade (LP: #1821663)
- ALSA: hda - Add two more machines to the power_save_blacklist

  * CVE-2019-9500
- brcmfmac: assure SSID length from firmware is limited

  * CVE-2019-9503
- brcmfmac: add subtype check for event handling in data path

  * CVE-2019-3882
- vfio/type1: Limit DMA mappings per container

  * autofs kernel module missing (LP: #1824333)
- [Config] Update autofs4 path in inclusion list

  * The Realtek card reader does not enter PCIe 1.1/1.2 (LP: #1825487)
- misc: rtsx: Enable OCP for rts522a rts524a rts525a rts5260
- SAUCE: misc: rtsx: Fixed rts5260 power saving parameter and sd glitch

  * headset-mic doesn't work on two Dell laptops. (LP: #1825272)
- ALSA: hda/realtek - add two more pin configuration sets to quirk table

  * CVE-2019-3887
- KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
- KVM: x86: nVMX: fix x2APIC VTPR read intercept

  * CVE-2019-3874
- sctp: implement memory accounting on tx path
- sctp: implement memory accounting on rx path

  * CVE-2019-1999
- binder: fix race between munmap() and direct reclaim

  * apparmor does not start in Disco LXD containers (LP: #1824812)
- SAUCE: shiftfs: use separate llseek method for directories

 -- Stefan Bader   Mon, 06 May 2019 17:33:15
+0200

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Disco:
  Fix Released

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 

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

2019-05-14 Thread Launchpad Bug Tracker
This bug was fixed in the package linux - 5.0.0-15.16

---
linux (5.0.0-15.16) disco; urgency=medium

  * CVE-2019-11683
- udp: fix GRO reception in case of length mismatch
- udp: fix GRO packet of death

  * CVE-2018-12126 // CVE-2018-12127 // CVE-2018-12130
- x86/msr-index: Cleanup bit defines
- x86/speculation: Consolidate CPU whitelists
- x86/speculation/mds: Add basic bug infrastructure for MDS
- x86/speculation/mds: Add BUG_MSBDS_ONLY
- x86/kvm: Expose X86_FEATURE_MD_CLEAR to guests
- x86/speculation/mds: Add mds_clear_cpu_buffers()
- x86/speculation/mds: Clear CPU buffers on exit to user
- x86/kvm/vmx: Add MDS protection when L1D Flush is not active
- x86/speculation/mds: Conditionally clear CPU buffers on idle entry
- x86/speculation/mds: Add mitigation control for MDS
- x86/speculation/mds: Add sysfs reporting for MDS
- x86/speculation/mds: Add mitigation mode VMWERV
- Documentation: Move L1TF to separate directory
- Documentation: Add MDS vulnerability documentation
- x86/speculation/mds: Add mds=full,nosmt cmdline option
- x86/speculation: Move arch_smt_update() call to after mitigation decisions
- x86/speculation/mds: Add SMT warning message
- x86/speculation/mds: Fix comment
- x86/speculation/mds: Print SMT vulnerable on MSBDS with mitigations off
- x86/speculation/mds: Add 'mitigations=' support for MDS

  * CVE-2017-5715 // CVE-2017-5753
- s390/speculation: Support 'mitigations=' cmdline option

  * CVE-2017-5715 // CVE-2017-5753 // CVE-2017-5754 // CVE-2018-3639
- powerpc/speculation: Support 'mitigations=' cmdline option

  * CVE-2017-5715 // CVE-2017-5754 // CVE-2018-3620 // CVE-2018-3639 //
CVE-2018-3646
- cpu/speculation: Add 'mitigations=' cmdline option
- x86/speculation: Support 'mitigations=' cmdline option

  * Packaging resync (LP: #1786013)
- [Packaging] resync git-ubuntu-log

linux (5.0.0-14.15) disco; urgency=medium

  * linux: 5.0.0-14.15 -proposed tracker (LP: #1826150)

  * [SRU] Please sync vbox modules from virtualbox 6.0.6 on next kernel update
(LP: #1825210)
- vbox-update: updates for renamed makefiles
- ubuntu: vbox -- update to 6.0.6-dfsg-1

  * Intel I210 Ethernet card not working after hotplug [8086:1533]
(LP: #1818490)
- igb: Fix WARN_ONCE on runtime suspend

  * [regression][snd_hda_codec_realtek] repeating crackling noise after 19.04
upgrade (LP: #1821663)
- ALSA: hda - Add two more machines to the power_save_blacklist

  * CVE-2019-9500
- brcmfmac: assure SSID length from firmware is limited

  * CVE-2019-9503
- brcmfmac: add subtype check for event handling in data path

  * CVE-2019-3882
- vfio/type1: Limit DMA mappings per container

  * autofs kernel module missing (LP: #1824333)
- [Config] Update autofs4 path in inclusion list

  * The Realtek card reader does not enter PCIe 1.1/1.2 (LP: #1825487)
- misc: rtsx: Enable OCP for rts522a rts524a rts525a rts5260
- SAUCE: misc: rtsx: Fixed rts5260 power saving parameter and sd glitch

  * headset-mic doesn't work on two Dell laptops. (LP: #1825272)
- ALSA: hda/realtek - add two more pin configuration sets to quirk table

  * CVE-2019-3887
- KVM: x86: nVMX: close leak of L0's x2APIC MSRs (CVE-2019-3887)
- KVM: x86: nVMX: fix x2APIC VTPR read intercept

  * CVE-2019-3874
- sctp: implement memory accounting on tx path
- sctp: implement memory accounting on rx path

  * CVE-2019-1999
- binder: fix race between munmap() and direct reclaim

  * apparmor does not start in Disco LXD containers (LP: #1824812)
- SAUCE: shiftfs: use separate llseek method for directories

 -- Stefan Bader   Mon, 06 May 2019 17:33:15
+0200

** Changed in: linux (Ubuntu Disco)
   Status: Fix Committed => Fix Released

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

** CVE added: 

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

2019-05-08 Thread Connor Kuehl
** Tags removed: verification-needed-bionic
** Tags added: verification-done-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  Fix Committed

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-05-07 Thread Christian Ehrhardt 
Ordering was important:

$ modprobe shiftfs
$ sudo snap set lxd shiftfs.enable=true
$ sudo systemctl restart snap.lxd.daemon
Now it is enabled:
$ lxc info | grep shiftfs   
  
shiftfs: "true"
$ lxc exec d-testapparmor -- mount | grep shift
/var/snap/lxd/common/lxd/storage-pools/default2/containers/d-testapparmor/rootfs
 on / type shiftfs (rw,relatime,passthrough=3)
/var/snap/lxd/common/lxd/storage-pools/default2/containers/d-testapparmor/rootfs
 on /snap type shiftfs (rw,relatime,passthrough=3)


And with that I can reproduce the bug:

$ 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.
$ lxc exec d-testapparmor -- apparmor_parser -r /etc/apparmor.d/sbin.dhclient
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'


Installing the host kernel from proposed.
=> 5.0.0.14.15

ubuntu@disco-test-aa-stack:~$ sudo apt install linux-generic 
linux-headers-generic linux-image-generic
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  linux-headers-5.0.0-14 linux-headers-5.0.0-14-generic 
linux-image-5.0.0-14-generic linux-modules-5.0.0-14-generic 
linux-modules-extra-5.0.0-14-generic
Suggested packages:
  fdutils linux-doc-5.0.0 | linux-source-5.0.0 linux-tools
The following NEW packages will be installed:
  linux-headers-5.0.0-14 linux-headers-5.0.0-14-generic 
linux-image-5.0.0-14-generic linux-modules-5.0.0-14-generic 
linux-modules-extra-5.0.0-14-generic
The following packages will be upgraded:
  linux-generic linux-headers-generic linux-image-generic
3 upgraded, 5 newly installed, 0 to remove and 8 not upgraded.
Need to get 67.1 MB of archives.
After this operation, 334 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
Get:1 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-modules-5.0.0-14-generic amd64 5.0.0-14.15 [13.7 MB]
6% [1 linux-modules-5.0.0-14-generic 4743 kB/13.7 MB 35%]
Get:2 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-image-5.0.0-14-generic amd64 5.0.0-14.15 [8350 kB]
Get:3 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-modules-extra-5.0.0-14-generic amd64 5.0.0-14.15 [33.2 MB]
Get:4 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 linux-generic 
amd64 5.0.0.14.15 [1860 B]  
  
Get:5 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-image-generic amd64 5.0.0.14.15 [2484 B]  

Get:6 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-headers-5.0.0-14 all 5.0.0-14.15 [10.7 MB]

Get:7 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-headers-5.0.0-14-generic amd64 5.0.0-14.15 [1170 kB]  

Get:8 http://archive.ubuntu.com/ubuntu disco-proposed/main amd64 
linux-headers-generic amd64 5.0.0.14.15 [2440 B]

Fetched 67.1 MB in 13s (5048 kB/s)  

 
Selecting previously unselected package linux-modules-5.0.0-14-generic.
(Reading database ... 67632 files and directories currently installed.)
Preparing to unpack .../0-linux-modules-5.0.0-14-generic_5.0.0-14.15_amd64.deb 
...
Unpacking linux-modules-5.0.0-14-generic (5.0.0-14.15) ...
Selecting previously unselected package linux-image-5.0.0-14-generic.
Preparing to unpack .../1-linux-image-5.0.0-14-generic_5.0.0-14.15_amd64.deb ...
Unpacking linux-image-5.0.0-14-generic (5.0.0-14.15) ...
Selecting previously unselected package linux-modules-extra-5.0.0-14-generic.
Preparing to unpack 
.../2-linux-modules-extra-5.0.0-14-generic_5.0.0-14.15_amd64.deb ...
Unpacking linux-modules-extra-5.0.0-14-generic (5.0.0-14.15) ...
Preparing to unpack .../3-linux-generic_5.0.0.14.15_amd64.deb ...
Unpacking linux-generic (5.0.0.14.15) over (5.0.0.13.14) ...
Preparing to unpack .../4-linux-image-generic_5.0.0.14.15_amd64.deb ...
Unpacking linux-image-generic (5.0.0.14.15) over (5.0.0.13.14) ...
Selecting previously unselected package linux-headers-5.0.0-14.
Preparing to unpack .../5-linux-headers-5.0.0-14_5.0.0-14.15_all.deb ...
Unpacking 

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

2019-05-07 Thread Christian Ehrhardt 
I have not seen/triggered the kernel issue mentioned in here (identified by 
jdstrand).
But on request I'll try it at least.

Testing on Disco with Host Having:
5.0.0-13-generic

# Create container and trigger the issue:
lxc launch ubuntu-daily:d d-testapparmor
# update the container to not have the bug in apparmor userspace
lxc exec d-testapparmor apt update
lxc exec d-testapparmor apt upgrade
# Check status of AA in the container

Harr, this is not using shiftfs - therefore I can't trigger the bug yet.

Trying to get shiftfs to be active, not loaded yet
sudo modprobe shiftfs
sudo systemctl restart snap.lxd.daemon
# but creating a container still is empty
lxc exec d-testapparmor -- grep shiftfs /proc/self/mountinfo


Yep the daemon think it is not available
$ lxc info | grep shiftfs
shiftfs: "false"


I tried on this for a while but even
 $ sudo snap set lxd shiftfs.enable=true
Won't set it to true.
I'm not sure I can verify this one as I don't know what blocks me from using 
shiftfs in the first place.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  Fix Committed

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-05-06 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
bionic' to 'verification-done-bionic'. If the problem still exists,
change the tag 'verification-needed-bionic' to 'verification-failed-
bionic'.

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

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


** Tags added: verification-needed-bionic

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  Fix Committed

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-26 Thread Ubuntu Kernel Bot
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
disco' to 'verification-done-disco'. If the problem still exists, change
the tag 'verification-needed-disco' to 'verification-failed-disco'.

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

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


** Tags added: verification-needed-disco

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  Fix Committed

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-23 Thread Kleber Sacilotto de Souza
** Changed in: linux (Ubuntu Disco)
   Status: New => Fix Committed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  Fix Committed

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-23 Thread Kleber Sacilotto de Souza
** Also affects: libvirt (Ubuntu Disco)
   Importance: Undecided
   Status: New

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

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

** No longer affects: libvirt (Ubuntu Disco)

** No longer affects: apparmor (Ubuntu Disco)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress
Status in linux source package in Disco:
  New

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-16 Thread Launchpad Bug Tracker
This bug was fixed in the package apparmor - 2.13.2-9ubuntu6

---
apparmor (2.13.2-9ubuntu6) disco; urgency=medium

  * lp1824812.patch: set SFS_MOUNTPOINT in is_container_with_internal_policy()
since it is sometimes called independently of is_apparmor_loaded()
- LP: #1824812

 -- Jamie Strandboge   Mon, 15 Apr 2019 15:59:54 +

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Fix Released
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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-16 Thread Stéphane Graber
** Tags added: shiftfs

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread Ubuntu Foundations Team Bug Bot
The attachment "UBUNTU: SAUCE: shiftfs: use correct llseek method for"
seems to be a patch.  If it isn't, please remove the "patch" flag from
the attachment, remove the "patch" tag, and if you are a member of the
~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by
~brian-murray, for any issues please contact him.]

** Tags added: patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread 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 Kernel
Packages, which is subscribed to linux 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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread 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 Kernel
Packages, which is subscribed to linux 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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread Christian Brauner
Okay, I have a fix for the shiftfs side I think. Attached here.

** Patch added: "UBUNTU: SAUCE: shiftfs: use correct llseek method for"
   
https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1824812/+attachment/5256074/+files/0001-UBUNTU-SAUCE-shiftfs-use-correct-llseek-method-for-d.patch

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread Jamie Strandboge
Uploaded 2.13.2-9ubuntu6 with the SFS_MOUNTPOINT change.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread 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 Kernel
Packages, which is subscribed to linux 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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : 

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

2019-04-15 Thread Jamie Strandboge
Since the apparmor SFS_MOUNTPOINT change is small, I'll prepare an
upload for that immediately. We may need another parser update for the
other issue.

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp


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

2019-04-15 Thread Jamie Strandboge
The following will reproduce the issue in a disco VM with disco LXD
container:

Initial setup:
1. have an up to date disco vm
$ cat /proc/version_signature 
Ubuntu 5.0.0-11.12-generic 5.0.6

2. sudo snap install lxd
3. sudo adduser `id -un` lxd
4. newgrp lxd
5. sudo lxd init # use defaults
6. . /etc/profile.d/apps-bin-path.sh

After this note the SFS_MOUNTPOINT bug:
1. lxc launch ubuntu-daily:d d-testapparmor
2. lxc exec d-testapparmor /lib/apparmor/apparmor.systemd reload
3. fix /lib/apparmor/rc.apparmor.functions to define 
SFS_MOUNTPOINT="${SECURITYFS}/${MODULE}" at the top of 
is_container_with_internal_policy(). Ie lxc exec d-testapparmor vi 
/lib/apparmor/rc.apparmor.functions 
4. lxc exec d-testapparmor -- sh -x /lib/apparmor/apparmor.systemd reload # 
notice apparmor_parser was called

At this point, these were called (as seen from the sh -x output, above):

/sbin/apparmor_parser --write-cache --replace -- /etc/apparmor.d
/sbin/apparmor_parser --write-cache --replace -- 
/var/lib/snapd/apparmor/profiles

but no profiles were loaded:
$ lxc exec d-testapparmor aa-status

Note weird parser error trying to load an individual profile:
$ lxc exec d-testapparmor -- apparmor_parser -r /etc/apparmor.d/sbin.dhclient 
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'

Stopping and starting the container doesn't help:
$ lxc stop d-testapparmor
$ lxc start d-testapparmor
$ 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.


Note, under 5.0.0-8.9 and with the SFS_MOUNTPOINT fix, the tunables error goes 
away:
$ lxc exec d-testapparmor -- apparmor_parser -r /etc/apparmor.d/sbin.dhclient
$

and the profiles load on container start:
$ lxc exec d-testapparmor 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.

However, 5.0.0-11.12 has fixes for lxd and apparmor. This 11.12 also
starts using shiftfs. Very interestingly, if I create a container under
5.0.0-8.9, do the SFS_MOUNTPOINT fix and start it under 5.0.0-11.12,
then policy loads and everything seems fine; there are no shiftfs mounts
for that container:

$ lxc exec d-testapparmor -- grep shiftfs /proc/self/mountinfo
$

*but* if I create the container under 11.12, I see the problems and there are 
shiftfs mounts:
$ lxc exec shiftfs-testapparmor -- grep shiftfs /proc/self/mountinfo
1042 443 0:78 / / rw,relatime - shiftfs 
/var/snap/lxd/common/lxd/storage-pools/default/containers/shiftfs-testapparmor/rootfs
 rw,passthrough=3
1067 1043 0:57 /shiftfs-testapparmor /dev/.lxd-mounts rw,relatime master:216 - 
tmpfs tmpfs rw,size=100k,mode=711
1514 1042 0:78 /snap /snap rw,relatime shared:626 - shiftfs 
/var/snap/lxd/common/lxd/storage-pools/default/containers/shiftfs-testapparmor/rootfs
 rw,passthrough=3

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

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

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => John Johansen (jjohansen)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1824812

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  Triaged
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