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

[intrigeri]

Hi,

Aaron Rainbolt (2026-03-31):
> On Tue, 31 Mar 2026 13:43:20 +0200
> intrigeri <intrigeri at debian.org> wrote:
>> Aaron Rainbolt (2026-03-22):
>> 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 can't, which is why we have a problem: if a (non-Flatpak) app uses
dconf to store its settings, its AppArmor profile must give it write
access to the full dconf database, which can be turned into a sandbox
escape with arbitrary code execution.

FWIW https://gitlab.tails.boum.org/tails/tails/-/work_items/21439
analyses this a little bit.

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

I was not. I was referring to /usr/share/apparmor-features/features.

/etc/apparmor/parser.conf reads:

  ## Pin feature set (avoid regressions when policy is lagging behind
  ## the kernel)
  policy-features=/usr/share/apparmor-features/features

I did not check if the ABI system would be enough to avoid the kind of
problems I have in mind here.

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

Wrt. "as much stuff to be confined as possible", this seems to match
the goal of another project: https://github.com/roddhjav/apparmor.d/

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

With "policy we ship" I meant this: all AppArmor profiles shipped
in Debian. Given we're talking about D-Bus, this should primarily be
about desktop apps, as I don't expect server daemons to break due to
the lack of fine-grained D-Bus rules.

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

OK, then this would be, by far, the best way to support my AppArmor
work at the moment, as it's the hottest topic, probably needs a few
hours of work, and I don't seem to find them.

The way I would approach it would be to provide a set of profiles that
apps profile can use for this. I would start from
https://github.com/roddhjav/apparmor.d/tree/main/apparmor.d/namespaces/glycin,
i.e. the namespace version of their solution, that works for processes
even if they have NNP set, and adjust this as needed for usage outside
of roddhjav/apparmor.d.

For inspiration, I've done something similar already there, albeit
without using the namespace version (which only works for processes
that don't have NNP set):
https://gitlab.torproject.org/tpo/applications/torbrowser-launcher/-/merge_requests/42

I would propose this new set of profiles upstream and backport to
Debian. I would use different profile & file names from
roddhjav/apparmor.d's to avoid conflicts.

For more context, background, and inspiration:

 - https://apparmor.pujol.io/development/internal/#no-new-privileges
 - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1127671
 - https://github.com/roddhjav/apparmor.d/issues/881
 - https://salsa.debian.org/gnome-team/extras/evince/-/merge_requests/10

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

Yup.

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

Sweet!

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

Sounds great!

Cheers,
-- 
intrigeri