Since I started seeing this in libvirt There might be reasons that is done that 
way but this affects me and probably other use cases e.g. if I install libvirt:
  $ apt install libvirt-daemon-system
  $ aa-status | grep libvirt

On my test systems the containers do not get any profile loaded:
$ 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.

When testing a new disco container on my laptop they at least have only
less profiles, but some profiles work. Odd at least.

** Description changed:

- In LXD apparmor now skips starting:
- Formerly:
- root@testkvm-bionic-from:~# systemctl status apparmor
- ● apparmor.service - AppArmor initialization
-    Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
-    Active: active (exited) since Mon 2019-04-15 13:09:07 UTC; 1h 8min ago
-      Docs: man:apparmor(7)
-            http://wiki.apparmor.net/
-   Process: 90 ExecStart=/etc/init.d/apparmor start (code=exited, 
status=0/SUCCESS)
-  Main PID: 90 (code=exited, status=0/SUCCESS)
+ In LXD apparmor now skips starting.
  
- Apr 15 13:09:07 testkvm-bionic-from systemd[1]: apparmor.service: Failed to 
reset devices.list: Operation not permitted
- Apr 15 13:09:07 testkvm-bionic-from systemd[1]: Starting AppArmor 
initialization...
- Apr 15 13:09:07 testkvm-bionic-from apparmor[90]:  * Starting AppArmor 
profiles
- Apr 15 13:09:07 testkvm-bionic-from apparmor[90]: Skipping profile in 
/etc/apparmor.d/disable: usr.sbin.rsyslogd
- Apr 15 13:09:07 testkvm-bionic-from apparmor[90]:    ...done.
- Apr 15 13:09:07 testkvm-bionic-from systemd[1]: Started AppArmor 
initialization.
+ 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.
  
- Now:
- root@testkvm-disco-to:~# systemctl status apparmor
- ● apparmor.service - Load AppArmor profiles
-    Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor 
preset: enabled)
-    Active: active (exited) since Mon 2019-04-15 13:56:12 UTC; 21min ago
-      Docs: man:apparmor(7)
-            https://gitlab.com/apparmor/apparmor/wikis/home/
-   Process: 101 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, 
status=0/SUCCESS)
-  Main PID: 101 (code=exited, status=0/SUCCESS)
+ All those 15 remaining are from snaps.
+ The service of apparmor.service actually states that it refuses to start.
  
- Apr 15 13:56:12 testkvm-disco-to systemd[1]: Starting Load AppArmor 
profiles...
+ $ systemctl status apparmor
+ ...
  Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor 
in container
- Apr 15 13:56:12 testkvm-disco-to systemd[1]: Started Load AppArmor profiles.
  
+ Since some apparmor seems to work I need to debug it further why so many
+ are missing initially and why it affects me in libvirt.
  
- ---
+ --- --- ---
  
  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

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

Title:
  apparmor no more starting in Disco LXD containers

Status in apparmor package in Ubuntu:
  New
Status in libvirt package in Ubuntu:
  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 <container>
    $ lxc start <container>
    $ 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/ubuntu/+source/apparmor/+bug/1824812/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

Reply via email to