[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 & others!

Thanks a lot for all this useful input! I think there's some
misunderstanding going on about one of my test procedures though, see
below. I also did some more tests which increased my confidence in the
whole idea, so I'm going to upload 2.11.1-1 now.

John Johansen:
> On 10/23/2017 10:30 AM, intrigeri wrote:

>>> 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
> this step is likely not needed as apparmor will detect the feature
> set doesn't match and update the features as it recompiles to the
> new feature set.

Note that at this point I'm not pinning the feature set: I'm *only*
storing the 4.14 feature set somewhere so I can use it later in step
7. I see no way to do step 7 without having this file available,
hence step 2.

>> 3. boot sid with Linux 4.13 from sid
> might want to test that the features file was updated, a timestamp
> since boot should be all you need to check

Which features file?  /etc/apparmor.d/cache/.features?

>> 7. cp /etc/apparmor/features{-4.14,}
> this step is not needed
>> 8. systemctl restart apparmor
> this step is not needed either, but if you want to get the service
> message without digging it shouldn't hurt either.

I don't understand: step 7 + step 8 are precisely what I wanted to
test (upgrading to a feature set newer that contains features not
supported by the running kernel + reloading policy, i.e. exactly what
happens in the situations I want to validate behavior for).

I just did another, more realistic test for the actual upgrade path
I'm interested in ⇒ see #879585.

>> I'm kinda surprised that apparmor_parser does not complain about being
>> explicitly told to enable features that the kernel does not support,

> Well it can, you can use
> --warn=rule-downgraded

> which means some enforcement of the rule but at a coarser level, eg.
> a unix rule to network unix,

> and
> --warn=rule-not-enforced

> which means no enforcement

> you can enable them by default by setting them in /etc/apparmor/parser.conf

> # enable rule downgrade warnings by default
> warn=rule-not-enforced
> warn=rule-downgraded

Right, sorry I forgot about this! I've done some more tests with these
options enabled and the logs confirm my tests results.

>>> 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.

> So this should generally work, as long as the kernel isn't too old.
> The barrier is the abi version supported vs that of the feature file.
> Where the abi version is used a break point.

Interesting! I'd like to check what "too old" looks like in real-life
situations. Where can I find this ABI version? Is it both what I see
in /sys/kernel/security/apparmor/features/policy/versions/ (v5, v6 and
v7 on Linux 4.13) and in my features file ("versions {v7 {yes} v6
{yes} v5 {yes}}")? Can I assume that as long as the intersection of
these list of versions is not empty, we're good?

Now, on Stretch's Linux 4.9
/sys/kernel/security/apparmor/features/policy/versions/ contains only
a "set_load" file and no actual vN file. I guess this is what the
comments in parser/parser_common.c ("parser_abi_version is not
supported by kernels that only support v5 kernel abi"). I hope this
doesn't disqualify the idea of pinning the feature set in Stretch to
what Linux 4.9 supports, does it? (I'll test this and report back on
https://bugs.debian.org/879585.)

Anyway, theory put aside I wanted to check what happens *in practice*
during a Stretch → Buster upgrade. This worked fine (well, the policy
reload failed but at least dpkg thinks the upgrade succeeded): see my
test report on #879585.

Cheers,
-- 
intrigeri