[pkg-apparmor] Interest in backporting AppArmor 5 to Trixie once released?

[intrigeri]

Hi,

(adding the team mailing list to Cc for posterity; please consider
removing debian-backports@ from recipients for follow-ups, if we dive
further out of scope for that list than I already did here :)

Aaron Rainbolt (2026-03-22):
> While working on Whonix (an anonymity-focused hardened Debian
> derivative), I discovered that AppArmor 4 is missing fine-grained UNIX
> socket mediation. This is a bit of a problem for us, since unrestricted
> access to D-Bus can be used to modify the environment systemd starts
> new processes with, and can be used to restart services, allowing
> an application to escape AppArmor confinement by getting systemd to
> restart a service with an LD_PRELOAD environment variable pointed at a
> malicious library. We have at least two GUI applications that we cannot
> deny UNIX socket access to, and that we also want to stay confined,
> which is impossible to do with AppArmor 4 unless running applications
> under a different user account (which in our situation is not practical
> for a couple of different reasons).
>
> Kernel 6.19 apparently has UNIX socket mediation and D-Bus mediation,
> and is available in trixie-backports, but both features require
> AppArmor 5, which is still in beta at the moment.

This matches my understanding.

Along those lines, you might want to also consider dconf write access;
thanks Simon McVittie for bringing this to my attention recently!

> It doesn't look like
> historically there have been AppArmor userspace backports to Debian
> stable releases, so I'm wondering if it would be practical to backport
> AppArmor 5 to Trixie once it is released, so that downstreams like
> Whonix can take advantage of it.

AFAICT this would bring very little value to Debian users, but it
seems feasible.

Technically this should be rather straightforward and in theory it
should be safe, as long as the backport keeps the same AppArmor
features set pinning as the version from Trixie — otherwise we'll be
breaking apps.

There's been some parser bugs in the past where this "in theory it
should be safe, as long as […]" did not work that well, but this
should be rare, and probably not a blocker for backporting IMO.

Derivatives such as Whonix would then be free to tweak the pinned
features set to their heart's content, e.g. to enable the `dbus`
feature, and deal with the consequences (e.g. policies that need
updating to cope with that new feature; this is work we'll need to do
anyway in Debian during the Forky dev cycle, if we want to enable this
feature in Forky, but I don't plan to backport any of that to Trixie).

> If the existing maintenance burden of AppArmor in Debian is too high
> for this to be practical, I might be able to offer some help.

The package has had a RFH bug opened since 2022 (#1006872), and to be
honest I lack both capacity and motivation to do extra work in this
area that will not directly benefit any Debian or Tails users, so the
only way I could become happy to maintain this backport is if I got
significant help in other areas of my AppArmor work in Debian from
you folks :)

For example:

 - Once AppArmor 5.x userspace is in Debian: ensure the policy we ship
   is compatible with the new features, in particular the D-Bus one.

   This is probably the best way to ensure that the feature you need
   will work well in Forky: I can't guarantee anyone else will do that
   work within that timeframe. And it's probably more cost-effective
   and collaboration-inducing than doing a subset of this work in your
   own Trixie derivative. And once that's done, you'll know exactly
   what extra changes you need to backport to your Trixie derivative
   to make the whole thing work well!

   If someone committed to start this work soon, I would be happy to
   package a 5.0 beta in experimental, once we're done with the next
   item on this list:

 - Help with the current Glycin + bwrap vs. AppArmor mess

   (starting point: #1127935, I can provide more context and point to
   what I think would be the best solution, if desired; the next item
   on this list can also help determine how much effort this is worth)

 - Help determine which AppArmor profiles provide enough meaningful security
   compared to their maintenance cost (starting points: #1128767, #1128770)

 - A bunch of bug reports would benefit from some help

 - If I knew more about your skills and what kind of work makes you
   happy, I would be happy to provide other pointers.

Cheers,
-- 
intrigeri