This is prompted by <https://bugs.debian.org/1127935>, but that isn't
the only relevant issue.

For about 10 years, evince in Debian has had an AppArmor profile
originating from Ubuntu. The justification for why this was done has
been lost: the Debian changelog just says "Install apparmor profiles and
apport hook, both coming from Ubuntu", and the Ubuntu changelog was lost
in a rebase on Debian.

In theory the benefit of this profile (if I'm guessing the history
correctly) is that it mitigates security vulnerabilities that might
exist in poppler, libevdocument and similar libraries (poppler in
particular has had lots of CVEs) by making it harder for an attacker to
exploint those vulnerabilities by supplying a crafted
PDF/Postscript/etc. document.

However, a comment at the top of the profile says:

    evince is not written with application confinement in mind and is
    designed to operate within a trusted desktop session where anything
    running within the user's session is trusted.
    ...
    complete confinement is not possible

In particular, the profile includes "include
<abstractions/dbus-session>", which means arbitrary code execution
within evince is arbitrary code execution at the desktop session level
(the attacker can simply ask systemd, gnome-session, dbus-daemon, etc.
to act on their behalf). A comment says "We can blacklist any
problematic [services]" but I don't think that's actually realistic,
both because "enumerating badness" is inherently doomed, and because it
is likely that some of the services that are functionally necessary are
also a sandbox escape route (for example dconf).

Meanwhile, the cost of this profile is that any time evince or one of
its dependencies needs to do something for its normal operation that the
author of the profile didn't foresee, that feature will not work. This
was made particularly visible recently by gdk-pixbuf switching its image
loading to use glycin, which runs image loaders in a sandboxed
environment (via bubblewrap), which is not allowed by evince's AppArmor
profile: now, one layer of security hardening is preventing a different
layer from working as designed.

Other bugs that appear to be a result of the AppArmor profile:
<https://bugs.debian.org/1029760>
<https://bugs.debian.org/888620>
<https://bugs.debian.org/915024>
<https://bugs.debian.org/929358>
<https://bugs.debian.org/1037199>
<https://bugs.debian.org/1071608>
<https://bugs.debian.org/1084761>
<https://bugs.debian.org/923345>

I'm now questioning whether the benefit of the AppArmor profile is worth
its cost. Would it be better if we just removed it?

Evince wasn't designed to be sandboxed, which means that retrofitting
sandboxing onto it is never going to work particularly well. If it had
been designed (upstream) with sandboxing in mind, one way that could
happen would be for it to have a subprocess dedicated to doing the
error-prone and easily-attackable parts of parsing documents, which
would not need to do any of the obvious sandbox escapes like access to
D-Bus, and could be sandboxed using some combination of AppArmor,
Landlock, user namespaces (bwrap or otherwise), seccomp and so on -
exactly like the image loaders in glycin, or the sandboxed subprocesses
in modern web browsers. However, for that to work, it would have to be
something that is done upstream (in Evince or its replacement Papers),
rather than being bolted on afterwards by Debian/Ubuntu.

    smcv

Hi,

Simon McVittie (2026-02-22):

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,