[pkg-apparmor] Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

Hi,

(John, there's a question for you below and I'll like you to
double-check my testing procedure :)

intrigeri:
>> 1. in testing/sid, ship a conffile (in a package built from
>>    src:apparmor) that pins the most recent feature set fully supported
>>    by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
>>    we've fixed all the regressions brought by 4.13 yet); this should
>>    make the transition to Linux 4.14 smooth;

Implemented locally.

All test results below look good to me so I'll wait for John's answer
and will then upload to id.

Sadly, that this is not fully effective in the specific case of
4.14-rcN up to 4.14-rc6 due to a kernel bug with pinned older feature
sets, that will likely be fixed in Linux 4.14-rc7. For example, with
Linux 4.14-rc5 some network (e.g. unix, inet, inet6) operations are
denied despite the fact this pinned feature does not enable network
mediation support. For details, see:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
A fix is being tested and will hopefully be sent to Linus today.

> I'll need to test what happens when upgrading the feature set file +
> Linux in lockstep, when the new feature set includes features brought
> by the Linux upgrade and not supported by the running kernel.
> This will happens when upgrading to the next Debian stable, or on
> a rarely upgraded testing/sid system. It'll be solved on reboot but
> I want to ensure the package upgrade succeeds.

It seems to work just fine. Here's how I tested it:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features-4.14
3. boot sid with Linux 4.13 from sid
4. save the 4.13 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
5. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
6. reboot on Linux 4.13 again
7. cp /etc/apparmor/features{-4.14,}
8. systemctl restart apparmor
9. look at what happened:
   - apparmor.service was successfully restarted
   - the restart logs say 'apparmor="STATUS"
     operation="profile_replace" info="same as current profile,
     skipping"'
   - the policy has been successfully reloaded (actually not as said
     above, but that's fine)
   - the output of aa-status is what I would expect

I'm kinda surprised that apparmor_parser does not complain about being
explicitly told to enable features that the kernel does not support,
but OTOH its --help says "--features-file n Use only features in file
n" that I understand as the features file is only used to exclude
features not listed in there, and the parser actually uses the
intersection of the features specified in that file and the features
actually supported by the kernel. John, did I guess right?

> A special case of this general problem is when one intentionally runs
> an older kernel than the one whose feature set we've pinned. I did not
> test this yet. My understanding is that the worst that can happens is
> that one gets no AppArmor confinement at all, which is not exactly
> a regression compared to what Debian has been doing so far, and it's
> a corner case so I won't treat this as a blocker.

It seems to work just fine too. Here's how I tested this:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
3. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
4. reboot on Linux 4.13 from sid and look at what happened:
   - the policy has been successfully loaded
   - apparmor.service was successfully started
   - the output of aa-status is what I would expect

Cheers,
-- 
intrigeri