Source: evince Severity: normal X-Debbugs-Cc: [email protected], [email protected], Jamie Strandboge <[email protected]> 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
