[apparmor] AppArmor version for upcoming Debian 13 (Trixie)

Thu Feb 13 17:51:18 UTC 2025

On 2/13/25 08:02, intrigeri wrote:
> Hi,
> 
> Thanks for the quick reply! Some comments and more questions inline
> below:
> 
> John Johansen (2025-02-10):
>> On 2/10/25 03:48, intrigeri wrote:
>>> Currently Debian testing/sid is tracking AppArmor 3.1.x.
>>>
>>> I'm wondering if I should upgrade to 4.x for Debian 13 (Trixie), whose
>>> freeze will start in a few months. I would greatly appreciate
>>> some advice.
>>>
>> Yes. We have been planning to get debian updated to 4.1. Beta4
>> should be dropping some time today. We still have a couple of
>> known issues to fix before finally release but it is getting
>> close. It should release some time this month (February).
>>

Based on early testing on suse and ubuntu build systems we had a
few build issue for some platforms shake out so I am going to cut
a beta5

Ubuntu has an updated packaging for beta4/5 that I can send you

>> 4.1 will be a long term support version, where the current 4.0
>> release was not.
> 
> OK, so I'll try to upload 4.1.0~beta4 to experimental ASAP. I hope
> I can recycle some of the 4.1.0~beta1 packaging work from Ubuntu even
> though the Ubuntu packaging has switched to a Git workflow that makes
> this hard.
> 
> And then from there we'll see what's left to do and whether that's
> realistic to get it into Debian testing in time for the freeze for
> disruptive changes (March 15). I'll make the final decision once 4.1
> final is released.
> 
>>> Do I understand correctly that 4.x (or is it only 4.1?)
>>> may not support policy that was written for 3.x?
>>>
>>
>> AppArmor 4.x is backwards compatible with 3.x through the abi
>> mechanism. If a profile declares support for a 3.x abi that
>> is what will be supported and used.
> 
> OK, so, do I understand correctly that if we ship 4.1 in Debian
> Trixie, all profiles shipped in Trixie MUST:
> 
>   - Either declare abi/4.x — there's already a few in Debian, but not
>     many; this will work.
> 
>   - Or declare abi/3.0 — there's already a few in Debian, but not many;
>     this will work in most cases, but in some cases profile
>     interactions may break things and extra work is needed to
>     fix things.
>

No. How the abi system works is if profiles declare an abi, then the
parser will use the profiles declared api, and also what is advertised
by the kernel and intersect them as part of the compile so that if
the profile doesn't support something in the kernel, the compile
will reflect that and the kernel won't (mostly there may be some things
that has to be done) enforce it.

If a profile doesn't declare an abi then it is assumed to be a 2.x
profile and we fall back to the abi pinning system. You can find
more detail in the wiki https://gitlab.com/apparmor/apparmor/-/wikis/apparmorpolicyfeaturesABI

>     To tell whether that's the case, is it sufficient to run them
>     through `apparmor_parser --skip-cache --skip-kernel-load`
>     and assume the parser will error out if they're not compatible?
> 
yes the parser will error out if it doesn't understand something.

As for compatible, that depends on what you mean. The parser can do
rule downgrade, and drop features entirely if the kernel doesn't
support them. You can have the parser be silent about those changes,
warn on them, or error out.

see
$ apparmor_parser --help=warn

for the current set of supported warnings. But what you are specifically
looking for is

[no-]rule-not-enforced 	warn if a rule is not enforced
[no-]rule-downgraded   	warn if a rule is downgraded to a lesser but still enforcing rule
[no-]abi               	warn if there are abi issues in the profile

you can disable a warning with, eg.
    apparmor_parser --warn=no-rule-not-enforced

you can enable a warnings with, eg.
    apparmor_parser --warn=rule-not-enforced

and you can cause the parser to error out on a specific warning with
    apparmor_parser --Werror=rule-not-enforced

you can set these in /etc/apparmor/parser.conf or on the cmdline, the
cmdline will override what is set in the apparmor.conf file

There is one more wrinkle, for a build time test you are going to
want to specify the expected kernel ABI, so that you aren't testing
against the build host and what ever random kernel it has

you will need to set the flag

--kernel-features=the/kernel/features/file

you can get the kernel features file by running the following cmd
on a Trixie system

$ aa-features-abi -x > kernel-feature-file

There is a caveat that I thought of that the current warns don't
cover.
warn=abi covers your profile file having a different abi than the
          includes you are using
warn=rule-downgraded covers cases like unix socket rules getting
          downgraded to just a network socket rule
warn=rule-not-enforced covers the cases where a rule just can't be
          enforced at all

what isn't covered is if the profiles abi (what ever it is) doesn't
cover what the kernel supports. That is the kernel can enforce
restriction beyond what the profile will. ie. warn that this profile
should be upgraded/improved.

>     If that works, we're in luck: I can do that via autopkgtests!
>     If takes more manual work, I doubt we'll have capacity to evaluate
>     all the profiles in Debian in due time.
> 
setting Werror should allow autopkgtests to catch errors

>   - Or declare no ABI but luckily be compatible with ABI 4.x. I think
>     the majority of the profiles we have in Debian currently declare
>     no ABI. I don't know if they are compatible with ABI 4.x.
> 

profiles that don't declare an ABI will be assumed to be ABI 2.x, the
specific ABI will be taken from the parser.conf pinning that debian
has enabled.

Policy loaded with a 2.x ABI can co-exist in the kernel with 3.x and
4.x ABIs, each being enforced as best as possible using their respective
ABIs.

This does mean 2.x policy isn't enforcing newer features, eg. on Ubuntu
the user namespace restrictions. But it allows for incremental policy
updates, and for LXD to have a debian Buster container using its
policy while running on debian Trixie

>     Same as above:
> 
>     To tell whether that's the case, is it sufficient to run them
>     through `apparmor_parser --skip-cache --skip-kernel-load`
>     and assume the parser will error out if they're not compatible?
> 

yes, same answer as above.

>     If that works, we're in luck: I can do that via autopkgtests!
>     If takes more manual work, I doubt we'll have capacity to evaluate
>     all the profiles in Debian in due time.

ideally (hoefully) it will just work without having to do any policy
updates.

however its not a bad idea to go through and take a look at what
could be upgraded

> 
> Correct?
> 
> I've tried to understand how this works from
> https://gitlab.com/apparmor/apparmor/-/wikis/AppArmorpolicyfeaturesabi
> but I failed so far. If there's other doc I should read, please point
> me to it :)
> 
Oh. Well that means I need to work on improving that doc then :)

> Cheers,