Bug#888620: evince: apparmor profile prevents loading git-annex files

[Michael Gold]

On Thu, Sep 13, 2018 at 11:47:40 -0500, Jason Crain wrote:
> My understanding is that this limitation is in the Linux kernel's
> security module framework. Symbolic links are resolved before AppArmor
> can verify permission for the path, so AppArmor only sees
> "/xr0/michael/...etc...", not "/home/michael/...etc...".

That makes some sense.  It would be reasonable to set different security
policies on different filesystems--even directories within a filesystem,
when fs.protected_hardlinks is in use.

$HOME vs. /xr0 is only part of the problem.  The apparmor rules say that
evince can open:
 * any file under $HOME
 * any file outside of $HOME named *.pdf

What is actually triggering the denial is that the target git-annex path
has no extension.  I don't understand the security benefit, because:
 * the symlink, its target, and both directories are owned by me and not
   writable by anyone else
 * anyone trying to exploit users will simply give the file the expected
   extension (otherwise people would have trouble opening it)
 * harmful files are most likely to be in web/mail download directories,
   which are probably under $HOME so don't even get the extension check

-- Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20180919/5249838d/attachment.sig>