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
