Comment 1 for bug 1868051

Currently the desktop-legacy and unity7 interfaces allow:

/var/lib/snapd/desktop/applications/ r,
/var/lib/snapd/desktop/applications/mimeinfo.cache r,
/var/lib/snapd/desktop/applications/@{SNAP_INSTANCE_NAME}_*.desktop r,

Due to how apparmor works, deny rules take precedence over allow rules.

A) Adding:

  deny /var/lib/snapd/desktop/applications/ r,

would block all of that for desktop-legacy and unity7.

B) Using this instead:

  deny /var/lib/snapd/desktop/applications/*.desktop r,

would block @{SNAP_INSTANCE_NAME}_*.desktop rule for desktop-legacy and unity7. It would also leave the information leak open (since can read the dir).

C) is like B but we also replace the @{SNAP_INSTANCE_NAME}_*.desktop rule in desktop-legacy and unity7 with the explicit deny rule. This might cause a regression for anything expecting to read its own desktop file.

D) We could simply remove the rules from browser-support, but that would mean we'd have noisy denials in the logs (as happens now for anything that tries to read these files (like anything that doesn't plugs browser-support[allow-sandbox=true]).

E) We could create a utility function in the interfaces code that dynamically generates the deny rule and the allow rule based on @{SNAP_INSTANCE_NAME}. Eg

  spec.AddSnippet(specific_desktop_applications(<snap instance name>))

where it yields for foo.desktop:

  /var/lib/snapd/desktop/applications/ r,
  /var/lib/snapd/desktop/applications/@{SNAP_INSTANCE_NAME}_*.desktop r,
  deny /var/lib/snapd/desktop/applications/@{HOME}/[^f]*.desktop r,
  deny /var/lib/snapd/desktop/applications/@{HOME}/f[^o]*.desktop r,
  deny /var/lib/snapd/desktop/applications/@{HOME}/fo[^o]*.desktop r,
  deny /var/lib/snapd/desktop/applications/@{HOME}/foo[^_.]*.desktop r,

(we can clean up /usr/share/applications a bit as well to only allow access to mimeapps.list, snap-handle-link.desktop and xdg-open.desktop).

We can use this in browser-support, desktop and desktop-legacy which allows all the expected access, eliminates the noise and should be low risk of regression. Info leak remains.

I don't care for A, B or C since they seem regression prone. A and C remove the info leak, yes, but this bug isn't about the info leak and there are other leaks in the code base (we should try to not introduce more info leaks to the code base, but removing them must be done with care and in a way so as not to break existing applications).

The options are then D and E IME. D can be done quickly and will introduce some noise, but we can perhaps get that into 2.44.1. E would be in a subsequent PR in 2.45.