[pkg-apparmor] Bug#879585: apparmor: Pin the AppArmor feature set in Stretch to Linux 4.9's

[intrigeri]

intrigeri at debian.org:
> This is about supporting Stretch users who have enabled AppArmor
> and run a new kernel, e.g. from stretch-backports.

> Similarly to #879584, let's pin the AppArmor feature set to the one
> supported by the Stretch stock kernel, i.e. the one the AppArmor
> policy shipped in Stretch works well with.

I've tested this:

1. start a Stretch system with the AppArmor LSM enabled and the
   apparmor package (from Stretch) installed
2. cp /etc/apparmor.d/cache/.features /etc/apparmor/features
3. echo "features-file=/etc/apparmor/features" >> /etc/apparmor/parser.conf
4. reboot
5. everything comes up fine :)

Now test the case when one runs a newer kernel on Stretch with
a feature set pinned to Linux 4.9's:

6.a reboot on Linux 4.14-rc5 from Debian experimental
7.a everything comes up fine :)

Then roll back to the state we were in after step 5 (i.e.
running Linux 4.9 with its own feature set pinned) and test the
upgrade path to Buster:

6.b copy the 4.14's features file to /etc/apparmor/features
7.b upgrade to my tentative apparmor 2.11.1-1 package; this triggers
    a policy reload that fails and spits out quite a few error messages
    (Unable to replace "sanitized_helper". Profile doesn't conform to
    protocol); but the upgrade succeeds on the dpkg level as the policy
    reload is not fatal in apparmor.postinst.

I think these tests validate the general idea.

Cheers,
-- 
intrigeri