Apparmor: "ConditionSecurity=apparmor was not met" after upgrade to 18.04

I upgraded servers and container to 18.04 which was relatively smooth. Now I saw that all the lxd containers (privileged, lxd v3.0.1) can’t run apparmor any more

● apparmor.service - AppArmor initialization
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Thu 2018-08-30 15:26:27 CEST; 17s ago
           └─ ConditionSecurity=apparmor was not met

aa-status show:

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.

I don’t understand how these two outputs can go along. On the one hand aa failed to start (=inactive(dead)) and at the same time it can return what processes are (not) loaded.

If I install a snap ‘hello-world’ I get:

9 profiles are loaded.
9 profiles are in enforce mode.
   /snap/core/5328/usr/lib/snapd/snap-confine
   /snap/core/5328/usr/lib/snapd/snap-confine//mount-namespace-capture-helper
   snap-update-ns.core
   snap-update-ns.hello-world
   snap.core.hook.configure
   snap.hello-world.env
   snap.hello-world.evil
   snap.hello-world.hello-world
   snap.hello-world.sh
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.

So is it running if it loads those profiles?

As a test I added lxc.apparmor.profile=unconfined to the container config. The service still doesn’t load but aa-status is now full of loaded lxd profiles. This seems to be the profiles from the host system. ok…

One cantainer is still on lxd 2.0.11 (the lxd host is running 18.04) and apparmor is up and running.

I also started a fresh ubuntu 18.04 container where apparmor is running fine. Now trying to find the differences between the updated and the ‘fresh’ container.

I though about an incorrect apparmor config from the 16.04 system so I purged apparmor from the container and reinstalled but no difference.

When stopping/starting the upgraded container I get no data in the hosts kern.log. The ‘fresh’ 18.04 however generated these lines:

apparmor="STATUS" operation="profile_remove" profile="unconfined" name="lxd-test_</var/lib/lxd>" pid=5934 comm="apparmor_parser"
apparmor="STATUS" operation="profile_load" label="lxd-test_</var/lib/lxd>//&:lxd-test_<var-lib-lxd>:unconfined" name="/usr/sbin/tcpdump" pid=7511 comm="apparmor_parser"
apparmor="STATUS" operation="profile_load" label="lxd-test_</var/lib/lxd>//&:lxd-test_<var-lib-lxd>:unconfined" name="/sbin/dhclient" pid=7502 comm="apparmor_parser"

I compared the config.log of the two containers. One difference that could be relevant could be:
lxc.mount.entry = /var/lib/lxd/devices/ponos3/disk.aadisable.sys-module-apparmor-parameters-enabled sys/module/apparmor/parameters/enabled none bind,create=file
which exists only in the upgraded container.

Lots of work for nothing. False alert.

● apparmor.service - AppArmor initialization
   Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
   Active: inactive (dead)
Condition: start condition failed at Thu 2018-08-30 15:26:27 CEST; 17s ago
           └─ ConditionSecurity=apparmor was not met

Seems to be a result of the lxd docker profile.
The one container that I have not yet upgraded doesn’t have the docker profile assigned and the fresh 18.04 container neither until I found the differences in the config and the origin of it.

I still don’t know exactly what this status of apparmor is but I assume that the architects of LXD know about it and considered it as ok when using the docker profile…
But I’d be happy if someone want’s to explain the details.