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

[Simon McVittie]

Source: evince
Severity: normal
X-Debbugs-Cc: apparmor at packages.debian.org, security at debian.org, Jamie Strandboge <jamie at ubuntu.com>
Control: affects -1 + src:apparmor

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