Apparmor-related denials for Spotify snap

I’m running the Spotify snap (version 1.1.46.916.g416cacf1, snapd 2.48+20.04 on Ubuntu 20.04), and noticed repeated apparmor audit messages for stuff that was denied. I understand that snapd generates this policy based on the snap metadata, so I’m wondering where these should be fixed (by silently denying them, or allowing them)? Iow, should I report a bug with Spotify and if so, what should I tell them?

The errors are:

[960286.727553] audit: type=1400 audit(1607100224.709:35211):
                apparmor="DENIED" operation="open"
                profile="snap.spotify.spotify"
                name="/home/matthijs/.config/xdg-templates/" pid=3220240
                comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
[960291.908537] audit: type=1400 audit(1607100229.889:35212):
                apparmor="DENIED" operation="open"
                profile="snap.spotify.spotify"
                name="/home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled"
                pid=3220144 comm="spotify" requested_mask="r"
                denied_mask="r" fsuid=1000 ouid=1000
[960293.920460] audit: type=1107 audit(1607100231.901:35213): pid=1513
                uid=105 auid=4294967295 ses=4294967295
                msg='apparmor="DENIED" operation="dbus_method_call"
                bus="system" path="/org/freedesktop/NetworkManager"
                interface="org.freedesktop.NetworkManager"
                member="state" mask="send" name=":1.6549" pid=3220144
                label="snap.spotify.spotify" peer_pid=1173777
                peer_label="unconfined" exe="/usr/bin/dbus-daemon"
                sauid=105 hostname=?  addr=? terminal=?'
[961133.425258] audit: type=1107 audit(1607101071.403:35231): pid=1513
                uid=105 auid=4294967295 ses=4294967295
                msg='apparmor="DENIED" operation="dbus_signal"
                bus="system" path="/org/freedesktop/NetworkManager"
                interface="org.freedesktop.NetworkManager"
                member="CheckPermissions" name=":1.6549" mask="receive"
                pid=3220144 label="snap.spotify.spotify"
                peer_pid=1173777 peer_label="unconfined"
                exe="/usr/bin/dbus-daemon" sauid=105 hostname=? addr=?
                terminal=?'

The error for /home/matthijs/.config/xdg-templates/ sounds like it would be fixed by including abstractions/xdg-desktop, which I thought contains a blanket allow for ~/.config and ~/.local, so would fix the /home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled error as well. But it doesn’t work here, so maybe the allow in that file is just for listing those directories, rather than accessing things under them, and explicit rules should be added? These error messages only happen once when starting spotify, so they’re not too annoying (and Spotify probably doesn’t really need either of these files, so no harm done).

Note that I think both of these files are not common, I suspect most people will not have either of them, so most people probably wont’ see these.

As for the NetworkManager dbus calls, it seems Spotify calls to dbus to get network information, which is not allowed. Is that something that must be explicitly enabled in the snap? Or should this be added to the default profile in snapd maybe? These seem to happen more often (seems they happen when devices are added or remove, i.e. USB devices), so are annoying in the log and having access to the network state might be actually useful to Spotify as well.

I’ve now fixed this locally by adding these rules to ``, but that will of course be overwritten on an update, so I’d rather get this fixed properly.

dbus (send,receive)
     bus=system
     path="/org/freedesktop/NetworkManager"
     interface="org.freedesktop.NetworkManager"
     member="{CheckPermissions,state}",

owner @{HOME}/.config/xdg-templates/ r,
owner @{HOME}/.local/share/glib-2.0/schemas/gschemas.compiled r,

looks like not all interfaces are connected … check with

snap connections spotify

if after connecting there are still errors, you can use the snappy-debug command from the snappy-debug snap, run it in a terminal while running the app and see if there are any suggestions … if there are still remaining denials that do not come with suggestions, thats likely a bug (either in spotify or likely a missing/inclomplete interface in snapd)

Thanks for the useful suggestions.

There was indeed an open :network-manager connection, all others seem to have been autoconnected. Connecting that indeed fixes the audit errors. However, I do wonder:

  • If Spotify only queries the network state, it would be more appropriate for it to declare network-manager-observe, to not allow access to modify the network config? I tried connecting the existing network-manager plug to the :network-manager-observe slot, but as expected that doesn’t work.
  • Even if Spotify might in some cases modify NM settings (i.e. add port forwards or QOS settings or whatnot), I suspect it might be appropriate for the snap to declare both a :network-manager and :network-manager-observe plug and allow the user to decide how much access to grant.
  • I see :network-manager-observe is also not autoconnected, even though that seems like a fairly harmless permission. Is there any documentation about such a decision?
  • If such an interface is not connected, wouldn’t it make sense to add explicit (silent) deny rules rather than deferring to the default (noisy) denial for these requests? Or is a snap that declares such an interface expected to ask snapd whether the interface is connected and if not, refrain from making these requests?
  • Would/should the installation of this snap have asked me about making this connection? I can’t recall, but I think it didn’t ask (though the “software” GUI tool on this Ubuntu system stopped working (keeps loading indefinitely), so I can’t check there now).

For the file accesses, snappy-debug says:

But I’m not sure how appropriate these are. Adding personal-files seems overkill, since I suspect spotify is not actually accessing files, just letting GTK/Glib or some other library do its default initialisation (which probably also complicates applying the first suggestion). I could report a bug, but as I said, these are not quite that annoying and probably don’t apply to 99% of the users, so I think I’ll let these slide.

could you paste the lines before and after as well ? just seeing the errors without any context does not help a lot :slight_smile:

Oh, that’s just the error messages from dmesg that I previously posted. But here’s the complete output from snappy-debug:

INFO: Following '/var/log/syslog'. If have dropped messages, use:
INFO: $ sudo journalctl --output=short --follow --all | sudo snappy-debug


= AppArmor =
Time: Dec  5 12:55:53
Log: apparmor="DENIED" operation="open" profile="snap.spotify.spotify" name="/home/matthijs/.config/xdg-templates/" pid=3354443 comm="head" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /home/matthijs/.config/xdg-templates/ (read)
Suggestions:
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
* add 'personal-files (see https://forum.snapcraft.io/t/the-personal-files-interface for acceptance criteria)' to 'plugs'

= AppArmor =
Time: Dec  5 12:55:53
Log: apparmor="DENIED" operation="open" profile="snap.spotify.spotify" name="/home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled" pid=3354352 comm="spotify" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
File: /home/matthijs/.local/share/glib-2.0/schemas/gschemas.compiled (read)
Suggestions:
* adjust program to read necessary files from $SNAP, $SNAP_DATA, $SNAP_COMMON, $SNAP_USER_DATA or $SNAP_USER_COMMON
* add 'personal-files (see https://forum.snapcraft.io/t/the-personal-files-interface for acceptance criteria)' to 'plugs'

aha … i wonder if the desktop interface should be extended to allow read access of these … or if we dont want this if the apparmor complaints could be quietened … perhaps the @security team could chime in here …

I don’t know if it’s that though, but I couldn’t find anything else on the Internet about it, that’s why I come here Krogerfeedback

Just in case these are the snap packages I have installed:

core

core18

gnome-3-28-1804

gtk-common-themes

quake-toolkit

snapd

trenchbroom

Please help!

Edit: This also happens when I try to run any snap (tried with quake-toolkit tools).

5 Comments

this is neither related to the sporitfy app nor to the apparmor denials listed above, could you please open a new thread (and attach the output of snap version there, along with snap debug confinement and snap debug sandbox-features ) ?