Hello,

It seems that the AppArmor profile is not allowing evince to read file
accessed via the GVFS on Google drive (and probably other integrations)

I get the following denials:

type=AVC msg=audit(1674751821.962:528): apparmor="DENIED" operation="open" profile="/usr/bin/evince" name="/run/user/1000/gvfs/google-drive:host=example.com,user=foo/<path>" pid=11026 comm="EvJobScheduler" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000FSUID="bigon" OUID="bigon"

Adding the following rule is allowing me to read my files, but I'm not
sure that enough or consistant with the other rules (shouldn't write
access be allowed too?):

/{,var/}run/user/*/gvfs/** r,

Kind regards,
Laurent Bigonville

Hi,

Laurent Bigonville (2023-01-27):

I don't have the infrastructure in place to reproduce this easily,
so I'm going to ask some more info.

I suppose you've redacted this part:

  user=foo/<path>

I'd like to understand why the value for "name" did not match any of
these rules:

  /**.[bB][mM][pP]     r,
  /**.[dD][jJ][vV][uU] r,
  /**.[dD][vV][iI]     r,
  /**.[gG][iI][fF]     r,
  /**.[jJ][pP][gG]     r,
  /**.[jJ][pP][eE][gG] r,
  /**.[oO][dD][pP]     r,
  /**.[fFpP][dD][fF]   r,
  /**.[pP][nN][mM]     r,
  /**.[pP][nN][gG]     r,
  /**.[pP][sS]         r,
  /**.[eE][pP][sS]     r,
  /**.[eE][pP][sS][fFiI23] r,
  /**.[tT][iI][fF]     r,
  /**.[tT][iI][fF][fF] r,
  /**.[xX][pP][mM]     r,
  /**.[gG][zZ]         r,
  /**.[bB][zZ]2        r,
  /**.[cC][bB][rRtTzZ7]  r,
  /**.[xX][zZ]         r,

Could you please share a bit more about the value of "name" in the
error message, possibly privately?

Does it end with ".pdf", like name="/run/..../....pdf", or does it
look different?

Cheers,

Hi,

Since then, Laurent shared details privately (thanks!) and we now know
that the path passed to name="..." does not end with a known
extension, so we can't match on that :/

This is, unfortunately, a good example of the limitations of AppArmor
for desktop apps.

Short term, we need to choose between:

- Option A: works out of the box for files stored behind gvfs, impact
  of exploitation of Evince is higher by default

  Add a rule like the one you suggested initially.

- Option B: opening files stored behind gvfs requires tweaking files
  in /etc, impact of exploitation of Evince is lower by default

I think the maintainers of the app are generally the best placed to
decide what's best.

My 2 cts: personally, given how wide open the Evince profile already
is, I don't think the marginal security improvement of option B is
worth the UX pain, so I would go for option A.


And in passing, another 2 cts: mid term, as long as we ship desktop
apps as Debian packages weakly-sandboxed with AppArmor, as opposed to
Flatpak, perhaps we should consider making them use Desktop Portals
(e.g. via GTK_USE_PORTAL=1). This would allow us to make the AppArmor
policy much stricter, and would solve the whole class of UX problems
that this bug is part of.

Cheers,