From: smcv@debian.org   
      
   Source: evince   
   Severity: normal   
   X-Debbugs-Cc: apparmor@packages.debian.org, security@debian.org, Jamie   
   Strandboge    
   Control: affects -1 + src:apparmor   
      
   This is prompted by , 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   
   ", 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:   
      
      
      
      
      
      
      
      
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)