[pkg-apparmor] Bug#1128767: /etc/apparmor.d/usr.bin.evince: consider whether cost/benefit ratio justifies using AppArmor here

[intrigeri]

Hi,

Simon McVittie (2026-02-22):
> I'm now questioning whether the benefit of the AppArmor profile is worth 
> its cost.

Thank you for asking and thanks a lot for the summary!

This resonates a lot: in the last few years I've been leaning more and
more towards answering "no". I think it might be time to let go and
drop the AppArmor profiles that have a non-trivial maintenance cost,
while comparatively providing little¹ meaningful security benefit.

If maintainers choose to drop this kind of AppArmor profiles from
their packages, I will understand and fully support their decision.

[1] I'm writing "little" and not "no" because I'm not 100% convinced
    these sandbox escapes make the profiles entirely useless:
    I understand the existing policy raises the bar from "I've
    exploited poppler, now I have arbitrary code execution" to "I've
    exploited poppler, now I need to figure out which sort of sandbox
    the apps that uses the library is running in, and I have to
    implement the adequate sandbox escape". I suppose some adversaries
    are happy to pay this cost if this gives them access to high-value
    targets, who are known to use a given app or OS, so they'll
    happily adjust their exploit accordingly; while for some other
    adversaries, it's not worth the effort, considering all the less
    protected targets that are available elsewhere.


For extra context, my previous hopes for using AppArmor for meaningful
confinement of desktop apps, and in particular GTK apps since I've
been focused on those much more closely, were based on the hope that
a few things would happen quickly enough. Off the top of my head, this
included:

 - Fine-grained D-Bus confinement becomes available at a time when
   there's a healthy dynamics to collaboratively maintain AppArmor
   policy cross-distro.

   (D-Bus support is finally coming, hopefully in Forky. And for
   policy maintenance, https://github.com/roddhjav/apparmor.d/ is the
   new thing that gives me some hope back, but it's a huge and complex
   beast, I don't know if anyone has figured out how to use this as
   a distribution.)

 - GTK apps installed from Debian can be easily instructed to behave
   essentially as if they were running via Flatpak, i.e. using Portals
   for everything relevant, no direct dconf access, etc., so that we
   can ship much stricter AppArmor policy in Debian packages.

   (We've experimented with the idea in Tails, starting with the
   obvious GTK_USE_PORTAL=1, quickly faced limitations that were
   blockers for us, and ended up running some apps as "fake" Flatpak
   apps with flatpak-run(1), using our underlying SquashFS as the
   runtime. This hack works fine for our particular use case, but it's
   probably not worth generalizing to a context like Debian.

   I'm not complaining: I did not invest any effort into resolving the
   root causes in GNOME land. My guess is that there would be little
   interest upstream, and frankly, I find the expected rebuttal pretty
   convincing: "why don't you just install the app from
   Flathub then?")

 - Safer accessibility frameworks become the norm

 - AppArmor being enabled by default in Debian raises interest in
   working on things like the above, as a way to protect our users
   better, while sparing us the discussion, design & implementation
   work required to change in depth how we distribute apps.


Cheers,
-- 
intrigeri