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,
