[Kernel-packages] [Bug 1824812] Re: apparmor does not start in Disco LXD containers
This was fixed upstream in 61c27d8808f0589beb6a319cc04073e8bb32d860 ** Changed in: apparmor Status: Triaged => 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: Fix Released 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 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
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
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
** 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
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
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
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
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
** 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
** 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
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
** 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
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
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
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
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
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
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
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
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
