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

Tue Sep 1 22:57:11 BST 2020

On 21/8/20 1:16 μ.μ., intrigeri wrote:
> I'd like to know which one it is before I think more about the "patch
> AppArmor in a Buster point release" option: if enabling AppArmor
> inside Debian Buster LXC containers breaks services, then this does
> not look like a reasonable change to apply in a stable point-release.

Hi everyone, some quick feedback:

TL;DR: I think you should include the patch to the upcoming Debian 10.6. 
Because otherwise, _if the current AppArmor package is installed on a 
Debian 10 container running under LXC/LXD, it will eventually cause 
inconsistencies and unpredictable problems_.

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).

Thank you for your work, KP.

PS: Below I'm attaching some more detailed info on the situation I 
described above:

A few days ago I noticed that two Debian 10.5 CTs failed to complete the 
upgrade of:

bind9 bind9-host bind9utils dnsutils libbind9-161 libdns-export1104 
libdns1104 libirs161 libisc-export1100 libisc1100 libisccc161 
libisccfg163 liblwres161

breaking DNS. Oddly, bind9 started successfully after a reboot, but 
failed again the next day, upon the next “apt upgrade” …

Logs showed that the last automatic update of bind9 didn’t fully complete:

# tail /var/log/dpkg.log
2020-08-28 05:44:30 status half-configured bind9-host:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 status installed bind9-host:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 configure dnsutils:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2 <none>
2020-08-28 05:44:30 status unpacked dnsutils:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 status half-configured dnsutils:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 status installed dnsutils:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-28 05:44:30 status unpacked bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:30 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 05:44:32 trigproc systemd:amd64 241-7~deb10u4 <none>
2020-08-28 05:44:32 status half-configured systemd:amd64 241-7~deb10u4
2020-08-28 05:44:32 status installed systemd:amd64 241-7~deb10u4
2020-08-28 05:44:32 trigproc libc-bin:amd64 2.28-10 <none>
2020-08-28 05:44:32 status half-configured libc-bin:amd64 2.28-10
2020-08-28 05:44:32 status installed libc-bin:amd64 2.28-10
2020-08-28 07:43:04 startup packages configure
2020-08-28 07:43:04 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-28 07:43:04 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 07:43:08 startup packages configure
2020-08-28 07:43:08 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-28 07:43:08 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-28 07:43:13 startup packages configure
2020-08-28 07:43:13 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-28 07:43:13 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-29 07:43:04 startup packages configure
2020-08-29 07:43:04 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-29 07:43:04 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2
2020-08-29 07:43:08 startup packages configure
2020-08-29 07:43:08 configure bind9:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2 
<none>
2020-08-29 07:43:08 status half-configured bind9:amd64 
1:9.11.5.P4+dfsg-5.1+deb10u2

The error after manually running apt-get update && apt-get upgrade

Setting up bind9 (1:9.11.5.P4+dfsg-5.1+deb10u2) ...
bind9-pkcs11.service is a disabled or a static unit not running, not 
starting it.
bind9-resolvconf.service is a disabled or a static unit not running, not 
starting it.
Job for bind9.service failed because the control process exited with 
error code.
See "systemctl status bind9.service" and "journalctl -xe" for details.
invoke-rc.d: initscript bind9, action "restart" failed.
● bind9.service - BIND Domain Name Server
    Loaded: loaded 
(file://vm05.mydomain.tld/lib/systemd/system/bind9.service/lib/systemd/system/bind9.service;; 
enabled; vendor preset: enabled)
    Active: failed (Result: exit-code) since Mon 2020-08-31 00:07:05 
EEST; 7ms ago
   Process: 17095 ExecStart=/usr/sbin/named $OPTIONS (code=exited, 
status=1/FAILURE)

Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: Starting BIND Domain Name 
Server...
Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: bind9.service: Control 
process exited, code=exited, status=1/FAILURE
Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: bind9.service: Failed with 
result 'exit-code'.
Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: Failed to start BIND 
Domain Name Server.
dpkg: error processing package bind9 (--configure):
  installed bind9 package post-installation script subprocess returned 
error exit status 1
Setting up python3-apparmor (2.13.2-10) ...
Setting up apparmor-utils (2.13.2-10) ...
Errors were encountered while processing:
  bind9
E: Sub-process /usr/bin/dpkg returned an error code (1)
root at vm05:~# aa-status
apparmor module is loaded.
1 profiles are loaded.
1 profiles are in enforce mode.
    /usr/sbin/named
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.
root at vm05:~#

Notice that after a boot/reboot, no AppArmor profiles are loaded on a 
Debian 10 CT running under LXC. But the CT will have the same problem 
again, upon the next bind9 pkg update (unless I completely uninstall 
apparmor):

root at vm05:~# apparmor_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.
root at vm05:~# dpkg -l|fgrep apparm
ii  apparmor 2.13.2-10 amd64        user-space parser utility for AppArmor
ii  apparmor-profiles 2.13.2-10 all          experimental profiles for 
AppArmor security policies
ii  apparmor-utils 2.13.2-10 amd64        utilities for controlling AppArmor
ii  libapparmor1:amd64 2.13.2-10 amd64        changehat AppArmor library
ii  python3-apparmor 2.13.2-10 amd64        AppArmor Python3 utility library
ii  python3-libapparmor 2.13.2-10 amd64        AppArmor library Python3 
bindings
root at vm05:~#
root at vm05:~# cat /etc/debian_version
10.5
root at vm05:~#
root at vm05:~# systemd-detect-virt --container
lxc
root at vm05:~#

Bottom line, _if AppArmor is already installed on a Debian10.5 container 
(LXC/LXD), you won't break anything by including the patch_. On the 
contrary, you will prevent unpredictable behaviour when packages with AA 
profiles (like bind9) are updated on a container where AA has been 
installed, but is seemingly "inactive".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20200902/49943c15/attachment.html>