words of wisdom from a systems engineer

Enable AppArmor on a Debian Jessie cloud image


I merged some initial Debian support into the openstack-ansible-security role and ran into an issue enabling AppArmor. The apparmor service failed to start and I found this output in the system journal:

kernel: AppArmor: AppArmor disabled by boot time parameter

Digging in

That was unexpected. I was using the Debian jessie cloud image and it uses extlinux as the bootloader. The file didn’t reference AppArmor at all:

# cat /boot/extlinux/extlinux.conf
default linux
timeout 1
label linux
kernel boot/vmlinuz-3.16.0-4-amd64
append initrd=boot/initrd.img-3.16.0-4-amd64 root=/dev/vda1 console=tty0 console=ttyS0,115200 ro quiet

I learned that AppArmor is disabled by default in Debian unless you explicitly enable it. In contrast, SELinux is enabled unless you turn it off. To make matters worse, Debian’s cloud image doesn’t have any facilities or scripts to automatically update the extlinux configuration file when new kernels are installed.

Making a repeatable fix

My two goals here were to:

  1. Ensure AppArmor is enabled on the next boot
  2. Ensure that AppArmor remains enabled when new kernels are installed

The first step is to install grub2:

apt-get -y install grub2

During the installation, a package configuration window will appear that asks about where grub should be installed. I selected /dev/vda from the list and waited for apt to finish the package installation.

The next step is to edit /etc/default/grub and add in the AppArmor configuration. Adjust the GRUB_CMDLINE_LINUX_DEFAULT line to look like the one below:

GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet apparmor=1 security=apparmor"

Ensure that the required AppArmor packages are installed:

apt-get -y install apparmor apparmor-profiles apparmor-utils

Enable the AppArmor service upon reboot:

systemctl enable apparmor

Run update-grub and reboot. After the reboot, run apparmor_status and you should see lots of AppArmor profiles loaded:

# apparmor_status
apparmor module is loaded.
38 profiles are loaded.
3 profiles are in enforce mode.
35 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.

Final thoughts

I’m still unsure about why AppArmor is disabled by default. There aren’t that many profiles shipped by default (38 on my freshly installed jessie system versus 417 SELinux policies in Fedora 25) and many of them affect services that wouldn’t cause significant disruptions on the system.

There is a discussion that ended last year around how to automate the AppArmor enablement process when the AppArmor packages are installed. This would be a great first step to make the process easier, but it would probably make more sense to take the step of enabling it by default.

Photo credit: Max Pixel