<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">On 21/8/20 1:16 μ.μ., intrigeri wrote:<br>
</div>
<blockquote type="cite" cite="mid:87lfi8qp6f.fsf@manticora">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<p>Hi everyone, some quick feedback:</p>
<p>TL;DR: I think you should include the patch to the upcoming
Debian 10.6. Because otherwise, <u>if the current AppArmor
package is installed on a Debian 10 container running under
LXC/LXD, it will eventually cause inconsistencies and
unpredictable problems</u>.</p>
<p>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.</p>
<p>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).<br>
</p>
<p>Thank you for your work, KP.</p>
<p><br>
</p>
<p>PS: Below I'm attaching some more detailed info on the situation
I described above:</p>
<p>A few days ago I noticed that two Debian 10.5 CTs failed to
complete the upgrade of:<br>
<br>
<tt>bind9 bind9-host bind9utils dnsutils libbind9-161
libdns-export1104 libdns1104 libirs161 libisc-export1100
libisc1100 libisccc161 libisccfg163 liblwres161</tt><br>
<br>
breaking DNS. Oddly, bind9 started successfully after a reboot,
but failed again the next day, upon the next “apt upgrade” …<br>
<br>
Logs showed that the last automatic update of bind9 didn’t fully
complete:<br>
<br>
<tt># tail /var/log/dpkg.log</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status half-configured
bind9-host:amd64 1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status installed bind9-host:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 configure dnsutils:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status unpacked dnsutils:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status half-configured dnsutils:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status installed dnsutils:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status unpacked bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:30 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 05:44:32 trigproc systemd:amd64 241-7~deb10u4
<none></tt><tt><br>
</tt><tt>2020-08-28 05:44:32 status half-configured systemd:amd64
241-7~deb10u4</tt><tt><br>
</tt><tt>2020-08-28 05:44:32 status installed systemd:amd64
241-7~deb10u4</tt><tt><br>
</tt><tt>2020-08-28 05:44:32 trigproc libc-bin:amd64 2.28-10
<none></tt><tt><br>
</tt><tt>2020-08-28 05:44:32 status half-configured libc-bin:amd64
2.28-10</tt><tt><br>
</tt><tt>2020-08-28 05:44:32 status installed libc-bin:amd64
2.28-10</tt><tt><br>
</tt><tt>2020-08-28 07:43:04 startup packages configure</tt><tt><br>
</tt><tt>2020-08-28 07:43:04 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-28 07:43:04 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 07:43:08 startup packages configure</tt><tt><br>
</tt><tt>2020-08-28 07:43:08 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-28 07:43:08 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-28 07:43:13 startup packages configure</tt><tt><br>
</tt><tt>2020-08-28 07:43:13 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-28 07:43:13 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-29 07:43:04 startup packages configure</tt><tt><br>
</tt><tt>2020-08-29 07:43:04 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-29 07:43:04 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt><tt><br>
</tt><tt>2020-08-29 07:43:08 startup packages configure</tt><tt><br>
</tt><tt>2020-08-29 07:43:08 configure bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2 <none></tt><tt><br>
</tt><tt>2020-08-29 07:43:08 status half-configured bind9:amd64
1:9.11.5.P4+dfsg-5.1+deb10u2</tt></p>
<p>The error after manually running <tt>apt-get update &&
apt-get upgrade</tt><br>
</p>
<p><tt>Setting up bind9 (1:9.11.5.P4+dfsg-5.1+deb10u2) ...</tt><tt><br>
</tt><tt>bind9-pkcs11.service is a disabled or a static unit not
running, not starting it.</tt><tt><br>
</tt><tt>bind9-resolvconf.service is a disabled or a static unit
not running, not starting it.</tt><tt><br>
</tt><tt>Job for bind9.service failed because the control process
exited with error code.</tt><tt><br>
</tt><tt>See "systemctl status bind9.service" and "journalctl -xe"
for details.</tt><tt><br>
</tt><tt>invoke-rc.d: initscript bind9, action "restart" failed.</tt><tt><br>
</tt><tt>● bind9.service - BIND Domain Name Server</tt><tt><br>
</tt><tt> Loaded: loaded
(<a class="moz-txt-link-freetext" href="file://vm05.mydomain.tld/lib/systemd/system/bind9.service/lib/systemd/system/bind9.service">file://vm05.mydomain.tld/lib/systemd/system/bind9.service/lib/systemd/system/bind9.service</a>;;
enabled; vendor preset: enabled)</tt><tt><br>
</tt><tt> Active: failed (Result: exit-code) since Mon
2020-08-31 00:07:05 EEST; 7ms ago</tt><tt><br>
</tt><tt> Process: 17095 ExecStart=/usr/sbin/named $OPTIONS
(code=exited, status=1/FAILURE)</tt><tt><br>
</tt><tt><br>
</tt><tt>Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: Starting
BIND Domain Name Server...</tt><tt><br>
</tt><tt>Aug 31 00:07:05 vm05.mydomain.tld systemd[1]:
bind9.service: Control process exited, code=exited,
status=1/FAILURE</tt><tt><br>
</tt><tt>Aug 31 00:07:05 vm05.mydomain.tld systemd[1]:
bind9.service: Failed with result 'exit-code'.</tt><tt><br>
</tt><tt>Aug 31 00:07:05 vm05.mydomain.tld systemd[1]: Failed to
start BIND Domain Name Server.</tt><tt><br>
</tt><tt>dpkg: error processing package bind9 (--configure):</tt><tt><br>
</tt><tt> installed bind9 package post-installation script
subprocess returned error exit status 1</tt><tt><br>
</tt><tt>Setting up python3-apparmor (2.13.2-10) ...</tt><tt><br>
</tt><tt>Setting up apparmor-utils (2.13.2-10) ...</tt><tt><br>
</tt><tt>Errors were encountered while processing:</tt><tt><br>
</tt><tt> bind9</tt><tt><br>
</tt><tt>E: Sub-process /usr/bin/dpkg returned an error code (1)</tt><tt><br>
</tt><tt>root@vm05:~# aa-status</tt><tt><br>
</tt><tt>apparmor module is loaded.</tt><tt><br>
</tt><tt>1 profiles are loaded.</tt><tt><br>
</tt><tt>1 profiles are in enforce mode.</tt><tt><br>
</tt><tt> /usr/sbin/named</tt><tt><br>
</tt><tt>0 profiles are in complain mode.</tt><tt><br>
</tt><tt>0 processes have profiles defined.</tt><tt><br>
</tt><tt>0 processes are in enforce mode.</tt><tt><br>
</tt><tt>0 processes are in complain mode.</tt><tt><br>
</tt><tt>0 processes are unconfined but have a profile defined.</tt><tt><br>
</tt><tt>root@vm05:~#</tt><br>
</p>
<p>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):</p>
<p><tt>root@vm05:~# apparmor_status </tt><tt><br>
</tt><tt>apparmor module is loaded.</tt><tt><br>
</tt><tt>0 profiles are loaded.</tt><tt><br>
</tt><tt>0 profiles are in enforce mode.</tt><tt><br>
</tt><tt>0 profiles are in complain mode.</tt><tt><br>
</tt><tt>0 processes have profiles defined.</tt><tt><br>
</tt><tt>0 processes are in enforce mode.</tt><tt><br>
</tt><tt>0 processes are in complain mode.</tt><tt><br>
</tt><tt>0 processes are unconfined but have a profile defined.</tt><tt><br>
</tt><tt>root@vm05:~# dpkg -l|fgrep apparm</tt><tt><br>
</tt><tt>ii apparmor
2.13.2-10
amd64 user-space parser utility for AppArmor</tt><tt><br>
</tt><tt>ii apparmor-profiles
2.13.2-10
all experimental profiles for AppArmor security
policies</tt><tt><br>
</tt><tt>ii apparmor-utils
2.13.2-10
amd64 utilities for controlling AppArmor</tt><tt><br>
</tt><tt>ii libapparmor1:amd64
2.13.2-10
amd64 changehat AppArmor library</tt><tt><br>
</tt><tt>ii python3-apparmor
2.13.2-10
amd64 AppArmor Python3 utility library</tt><tt><br>
</tt><tt>ii python3-libapparmor
2.13.2-10
amd64 AppArmor library Python3 bindings</tt><tt><br>
</tt><tt>root@vm05:~# </tt><br>
<tt>root@vm05:~# cat /etc/debian_version </tt><tt><br>
</tt><tt>10.5</tt><tt><br>
</tt><tt>root@vm05:~# </tt><br>
<tt>root@vm05:~# systemd-detect-virt --container</tt><tt><br>
</tt><tt>lxc</tt><tt><br>
</tt><tt>root@vm05:~# </tt><br>
</p>
<p>Bottom line, <u>if AppArmor is already installed on a Debian10.5
container (LXC/LXD), you won't break anything by including the
patch</u>. 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".<br>
</p>
</body>
</html>