[pkg-apparmor] AppArmor regression between Debian 9 and 10 when running inside LXC/LXD container

[intrigeri]

Hi,

… and sorry for the delay!

Kostas Papadopoulos (2020-09-02):
> On 21/8/20 1:16 μ.μ., intrigeri wrote:
> Actual example: a few days ago Debian 10 released new packages for 
> bind9. I noticed that a couple of test Debian 10 containers failed to 
> restart bind9 after the automatic apt-get upgrade (dpkg log showed the 
> bind package half-configured). Oddly, rebooting the container allowed 
> bind9 to start, but it failed again upon automatic apt update/upgrade 
> the next day.
>
> After troubleshooting the bind9 issue, I realised that the reason why 
> the Debian 10 bind9 package failed to update/restart was due to 
> AppArmor. AppArmor had been installed on those two Debian 10 CTs running 
> under LXC, but was considered "inactive" since (due to the 
> bug/regression it doesn't load any profiles when a Debian10 CT is booted 
> under LXC), however AppArmor will load a profile when the application is 
> upgraded/restarted (as was the case with bind9).

Thanks, I understand better now. This is similar to, but different
from, https://bugs.debian.org/893398. I suggest you file a bug report
against dh-apparmor, titled "dh_apparmor should use the same logic as
apparmor.service to decide whether it shall load policy" or similar.

> Bottom line, _if AppArmor is already installed on a Debian10.5 container 
> (LXC/LXD), you won't break anything by including the patch_.

Earlier you reported that applying the patch made apparmor.service
load policy on boot inside the container, while without the patch we
don't load policy on boot. This is a significant change in behavior,
which can definitely break stuff, and I don't feel comfortable pushing
this in a stable point-release. (For example, static Buster containers
that are modified/updated by being rebuilt, instead of via APT,
currently work fine and have no AppArmor policy; if we apply this
patch, then suddenly they have AppArmor policy enforced, which can
break stuff.)

I understand the status quo is problematic for the use case you're
describing, and frankly, it sucks and if there was no risk involved,
I would be happy to fix it. But I think it's too late now to decide
that we're going to fix this use case in Buster, at the detriment of
other use cases that have been working fine in Buster since it was
released 1.5 years ago.

Note that the behavior *will* change when folks upgrade to Bullseye,
in a way that should fix your use case. But then that's a situation in
which system administrators would expect changes, and be prepared to
test & adjust stuff before rolling it to production.

Cheers!