I am trying to make AppArmor work inside a Debian 10 container, which is running on a Ubuntu 18.04 host with LXD 3.0.3.
I have create the vm05 Debian10 CT and enabled security nesting:
$ lxc config show vm05 --expanded|fgrep nest
security.nesting: "true"
However, after installing apparmor userland tools & profiles and rebooting vm05, it doesn’t load any AppArmor profiles:
root@vm05:~# cat /etc/debian_version
10.4
root@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 libapparmor1:amd64 2.13.2-10 amd64 changehat AppArmor library
root@vm05:~#
root@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@vm05:~#
Strangely, AppArmor profiles seem to load on a Debian 9 (instead of 10) container, on the same Ubuntu 18.04 host running LXD 3.0.3. But without having enabled security.nesting.
$ lxc config show vm01 --expanded|fgrep nest
$
And when logging inside the container:
root@vm01:~# apparmor_status
apparmor module is loaded.
35 profiles are loaded.
2 profiles are in enforce mode.
/usr/bin/freshclam
/usr/sbin/named
33 profiles are in complain mode.
/usr/lib/dovecot/anvil
/usr/lib/dovecot/auth
/usr/lib/dovecot/config
/usr/lib/dovecot/deliver
/usr/lib/dovecot/dict
/usr/lib/dovecot/dovecot-auth
/usr/lib/dovecot/dovecot-lda
/usr/lib/dovecot/dovecot-lda///usr/sbin/sendmail
/usr/lib/dovecot/imap
/usr/lib/dovecot/imap-login
/usr/lib/dovecot/lmtp
/usr/lib/dovecot/log
/usr/lib/dovecot/managesieve
/usr/lib/dovecot/managesieve-login
/usr/lib/dovecot/pop3
/usr/lib/dovecot/pop3-login
/usr/lib/dovecot/ssl-params
/usr/sbin/avahi-daemon
/usr/sbin/dnsmasq
/usr/sbin/dnsmasq//libvirt_leaseshelper
/usr/sbin/dovecot
/usr/sbin/identd
/usr/sbin/mdnsd
/usr/sbin/nmbd
/usr/sbin/nscd
/usr/sbin/smbd
/usr/sbin/smbldap-useradd
/usr/sbin/smbldap-useradd///etc/init.d/nscd
/usr/{sbin/traceroute,bin/traceroute.db}
klogd
ping
syslog-ng
syslogd
5 processes have profiles defined.
1 processes are in enforce mode.
/usr/bin/freshclam (314)
4 processes are in complain mode.
/usr/lib/dovecot/anvil (370)
/usr/lib/dovecot/config (373)
/usr/lib/dovecot/log (371)
/usr/sbin/dovecot (368)
0 processes are unconfined but have a profile defined.
root@vm01:~# dpkg -l|fgrep apparm
ii apparmor 2.11.0-3+deb9u2 amd64 user-space parser utility for AppArmor
ii apparmor-profiles 2.11.0-3+deb9u2 all profiles for AppArmor Security policies
ii libapparmor-perl 2.11.0-3+deb9u2 amd64 AppArmor library Perl bindings
ii libapparmor1:amd64 2.11.0-3+deb9u2 amd64 changehat AppArmor library
root@vm01:~# cat /etc/debian_version
9.12
root@vm01:~#
So, should I enable security.nesting in order to use AppArmor in Debian containers running under LXD?
security.nesting isn’t required for apparmor to work.
Most likely it’s the apparmor init script in that version of Debian which is mis-detecting the ability to load apparmor profiles.
I remember back in the day where we rolled out apparmor namespacing, the apparmor init scripts in Ubuntu required some changes. I don’t know how much of that made it upstream or how widely that is tested on other distros.
Thanks a lot for your quick reply. I have tried setting security.nesting to both “true” and “false” but it didn’t make any difference to the loading of AppArmor profiles on the vm05 Debian 10 CT:
$ lxc config set vm05 security.nesting false
$ lxc config show vm05 --expanded|fgrep nest
security.nesting: "false"
$
Btw if a parameter like security.nesting is unset, does it get its value from LXD’s “default” profile ? (I assume the default for nesting is “false”)
Anyway, I was hoping that Debian 10 (which has enabled AppArmor by default) would be fully supported under LXD … Should I make a regular bug report about this issue at Debian, or do you have a better way?
root@vm05:~# apparmor_parser -r /etc/apparmor.d/usr.sbin.named
root@vm05:~# apparmor_status
apparmor module is loaded.
1 profiles are loaded.
1 profiles are in enforce mode.
/usr/sbin/named
0 profiles are in complain mode.
1 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
1 processes are unconfined but have a profile defined.
/usr/sbin/named (653)
root@vm05:~#
But Debian 10 loads AppArmor profiles fine when run as a VM (under KVM, VMware etc) or on bare metal. This problem only happens when Debian 10 runs under LXD.
By the way, I had enabled security.nesting for CT vm05, because it was needed in order to run MariaDB 10.4 under Debian 10.
Thank you for your feedback, I will try to file a bug report at Debian.
But given that Debian 10 Buster has been around for a year and that AppArmor is now enabled by default, I am frankly a little surprised to be the first person to report this issue and a little anxious about using LXD+Debian in production …
Apparently Debian10 explicitly disables AppArmor when running in container:
root@vm05:~# systemctl status apparmor.service
● apparmor.service - Load AppArmor profiles
Loaded: loaded (/lib/systemd/system/apparmor.service; enabled; vendor preset: enabled)
Active: active (exited) since Wed 2020-07-15 21:38:19 EEST; 1h 58min ago
Docs: man:apparmor(7)
https ://gitlab .com/apparmor/apparmor/wikis/home/
Process: 46 ExecStart=/lib/apparmor/apparmor.systemd reload (code=exited, status=0/SUCCESS)
Main PID: 46 (code=exited, status=0/SUCCESS)
Jul 15 21:38:19 vm05 systemd[1]: Starting Load AppArmor profiles...
Jul 15 21:38:19 vm05 apparmor.systemd[46]: Not starting AppArmor in container
Jul 15 21:38:19 vm05 systemd[1]: Started Load AppArmor profiles.
root@vm05:~#
root@vm05:~# systemd-detect-virt --container
lxc
root@vm05:~#
So Debian10’s /etc/init.d/apparmor explicitly disables loading AppArmor profiles inside a container, unless is_container_with_internal_policy() is true.
Good news, after reporting the aforementioned bug to the Debian AppArmor maintainers, I received a patch which solved the issue and will be included in Debian 10.6.