[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

[John Johansen]

On 10/23/2017 10:30 AM, intrigeri wrote:
> 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.
> 
Testing so far has been good, I have a volunteer who has been encountering
this issue testing as well.

>> 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. That is unless you have not enabled writing cache
files during init, in which case apparmor will just not update the
cache file and basically you won't get cache hits except for on
kernels that match those of the feature file.

> 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

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

> 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
> 
looks good

> 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

see
apparmor_parser --help=warn for all supported options in a given parser

what currently isn't supported is failing the compile based on enforcement
being downgraded or not enforced.

btw that trick works for Optimize and Dump
apparmor_parser --help=O
apparmor_parser --help=D



> 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?
> 
nope, but the result is the same.

It will compile it to the given feature set. If the kernel supports
that given abi it will then do the other half providing the intersection.

This is done to allow policies from different versions to be loaded and
used simultaneously. Think of a buster host running an lxd stretch
guest, sharing the same kernel but enforcing different version of
policy.

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

The compiler could and should check for this and do further rule feature
downgrading by intersecting with the kernel but it currently doesn't.

The current abi is flexible in that each feature can declare within
the compile whether it is being supported/enforced or not. And the
kernel is selectively enforcing at this level.

So yes it should generally work, but we could support this a little
better

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