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

[Aaron Rainbolt]

On Tue, 31 Mar 2026 13:43:20 +0200
intrigeri <intrigeri at debian.org> wrote:

> 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 :)

Good idea, done.

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

Hmm, I didn't realize that was something AppArmor was able to mediate
nowadays. Good to know!

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

To be clear, you're talking about using the 5.0 ABI in policy files
correct? (AIUI that's how one enables this kind of feature, but the
wording kind of sounds like this might be something that would need to
be enabled at a deeper level, which would be problematic for Whonix. If
it's just using the 5.0 ABI though, that's something we can work with.)

> > 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 :)

This is something we're interested in. In the short term we mostly want
AppArmor to enforce our own custom policies adequately, but we really
would like as much stuff to be confined as possible where it makes
sense, so working on the bigger picture of AppArmor in Debian should be
mutually beneficial.

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

Where is this policy located? Is it a part of the apparmor package
itself? Does it cover other/all packages in the Debian archives that
ship files in /etc/apparmor.d? Or is it referring to something else?
(I can probably work on this regardless of what the answer is, but
would like to know the scope of what is being done.)

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

That looks interesting. Whonix currently uses loupe as our image viewer
specifically because it uses Glycin which provides sandboxed rendering,
so getting that working right upstream sounds like something we should
do.

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

I assume there's much more to this than just those two bug reports.
This probably involves going through all packages that ship AppArmor
profiles and filing bugs against those that look like a poor fit for
confinement?

On these two bugs specifically, looking at this from Whonix's
perspective, our long-term plan is to integrate apparmor.d into the
base system, then provide a sandboxing system based on systemd-nspawn
and containers to allow running applications that don't cope well with
confinement. (We don't want to use Flatpak for this because of the
sometimes lacking nature of the sandboxing, the per-app nature of the
sandboxing as opposed to per-use-case, and possible supply chain issues
with Flathub.) In that scenario, confining things like PDF viewers
probably doesn't make that much sense, since those would ultimately be
run inside a container/sandbox rather than directly on the end-user
machine. Extra confinement for applications within the sandbox would be
a nice-to-have though. (We also prefer using web browsers for PDF
rendering rather than native PDF renderers, because they do the whole
process in a sandbox.)

From a non-Whonix perspective, I think I mostly agree with Simon on
those bug reports. If something isn't designed to be confined and is
only intended to process trusted data, confining it is probably
fighting a battle that ultimately can't be won. There's also a push
from other upstreams (such as systemd) to consider anything that isn't
sandboxed to be trusted (see
https://github.com/systemd/systemd/pull/40954#issuecomment-4045027951),
so assuming the rest of the ecosystem goes this direction, we probably
should expect user-facing apps to gravitate more toward sandboxing and
less toward unsandboxed confinement.

There seem to be much more than just these two apps that need looked
at. I'd be happy to look at all of them and file bugs for those where
confinement doesn't make sense.

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

Skill-wise, I'm not necessarily an expert in AppArmor, but I know my
way around it and can find answers to questions on my own pretty
easily. I'm a MOTU in Ubuntu and help develop Kicksecure and Whonix
(both Debian derivatives), so I have a good understanding of Debian
packaging. Depending on what is involved in maintenance, I can probably
help out regularly, since I work on Whonix under contract and am able
to spend work time on AppArmor maintenance. (Note that I do not have DD
or DM privileges, so I will need sponsorship for any work I do.)

As for what makes me happy, mostly getting a backported AppArmor 5
userland would make me happy since there are a few spots in Whonix that
are a bit more open than they should be as a result of missing UNIX
socket and D-Bus mediation. The alternative to getting an
AppArmor backport is probably to write a sandboxing framework in
a hurry, which is probably a LOT more work than just helping
with AppArmor maintenance, and isn't practical for everything. So I'm
happy to work on pretty much anything that needs help if we can get a
newer AppArmor into our Trixie-based distros at the end of it.

--
Aaron
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-apparmor-team/attachments/20260331/2f743160/attachment.sig>