Reading /var/lib/snapd/desktop/(applications,icons}

Reynolds5 · October 11, 2019, 1:07pm

System: ubuntu 19.04
snap version: 2.42 series 16

On each snap startup it tries to read /var/lib/desktop/icons which is blocked by apparmor:
audit[1901]: AVC apparmor="DENIED" operation="open" profile="snap.firefox.firefox" name="/var/lib/snapd/desktop/icons/" pid=1901 comm="firefox-bin" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Basing on irc discussion /var/lib/snapd/desktop/icons is a new directory introduced in snapd 2.42. The similar path /var/lib/snapd/desktop/applications is allowed to read by multiple interfaces:

https://github.com/snapcore/snapd/commit/c9ddbe94c75137c7589847f0a20d6138d6d7c797

github.com

snapcore/snapd/blob/release/2.42/interfaces/builtin/desktop_legacy.go#L229


    path=/org/gtk/vfs/mounttracker
    interface=org.gtk.vfs.MountTracker
    member=ListMountableInfo,
dbus (send)
    bus=session
    path=/org/gtk/vfs/mounttracker
    interface=org.gtk.vfs.MountTracker
    member=LookupMount,
# This leaks the names of snaps with desktop files
/var/lib/snapd/desktop/applications/ r,
/var/lib/snapd/desktop/applications/mimeinfo.cache r,
# Support BAMF_DESKTOP_FILE_HINT by allowing reading our desktop files
# parallel-installs: this leaks read access to desktop files owned by keyed
# instances of @{SNAP_NAME} to @{SNAP_NAME} snap
/var/lib/snapd/desktop/applications/@{SNAP_INSTANCE_NAME}_*.desktop r,
`
const desktopLegacyConnectedPlugSecComp = `
# Description: Can access common desktop legacy methods. This gives privileged
# access to the user's input.

https://github.com/snapcore/snapd/commit/b3b4df2e62f0598156c8fdcf7800ac99bd032f32

github.com

snapcore/snapd/blob/release/2.42/interfaces/builtin/browser_support.go#L114


# capability. When snapd uses SECCOMP_RET_ERRNO, we can remove this rule.
# https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/46
deny capability mknod,
`
const browserSupportConnectedPlugAppArmorWithSandbox = `
# Leaks installed applications
# TODO: should this be somewhere else?
/etc/mailcap r,
# Snaps should be using xdg-open from the runtime instead of reading these
# files directly since the snap is unable to do anything with these files
# but these accesses have been allowed for a long time and remain so as not
# to break existing snaps. These could be changed to explicit deny rules,
# but that provides a worse debugging experience. Combined, the risks
# outweigh the benefits of closing this information leak for the small
# number of snaps allowed to use allow-sandbox: true. Reference:
# https://forum.snapcraft.io/t/cannot-open-pdf-attachment-with-thunderbird/11845
/usr/share/applications/{,*} r,
/var/lib/snapd/desktop/applications/{,*} r,
owner @{PROC}/@{pid}/fd/[0-9]* w,

https://github.com/snapcore/snapd/commit/050d70cb3a9d4209cadc2cbc8be0e8bdaf36bdce

github.com

snapcore/snapd/blob/master/interfaces/builtin/unity7.go#L483


dbus (send)
    bus=session
    path=/org/freedesktop/Notifications
    interface=org.freedesktop.DBus.Properties
    member="Get{,All}"
    peer=(label=unconfined),
dbus (receive)
    bus=session
    path=/org/freedesktop/Notifications
    interface=org.freedesktop.DBus.Properties
    member=PropertiesChanged
    peer=(label=unconfined),
dbus (send)
    bus=session
    path=/org/ayatana/NotificationItem/*
    interface=org.kde.StatusNotifierItem
    member=XAyatanaNew*
    peer=(name=org.freedesktop.DBus, label=unconfined),

according to @jamesh allowing those accesses was unnecessary:

I don’t think it is useful there either, since neither interface provides a way to launch those applications or access e.g. referenced icons

I believe both /var/lib/snapd/desktop/(applications,icons} should be treated the same by either allowing read access or denying it to prevent spam syslogs. I was advised to ask @jdstrand opinion on that matter.

jamesh · October 12, 2019, 12:54am

From the discussion on IRC, I suspect we are seeing the audit messages now because they only get generated when access is denied to existing files: not when the process tries to access a path that would be denied if it existed.

Since we add /var/lib/snapd/desktop to $XDG_DATA_DIRS and that setting leaks to the sandbox, it is not surprising that various libraries will try to access paths under that directory. If I created a /var/lib/snapd/desktop/themes directory, I wouldn’t be surprised if I started seeing denial audit messages about that too.

So I propose that we silence denial messages for accesses to /var/lib/snapd/desktop/**, since they are likely to just be noise.

As for the browser-support and desktop-legacy interfaces granting access to /var/lib/snapd/desktop/applications directory, I suspect that this could safely be removed. Neither interface lets sandboxed applications do anything useful with files in that directory (since they don’t allow launching of other snap applications). I kind of wonder if the rule originated in browser-support from seeing the audit messages, without deciding whether the access actually made sense?

Reynolds5 · October 21, 2019, 5:49pm

@jamesh while waiting for decision about denying whole /var/lib/snapd/desktop/** (which changes existing behavior thus can cause regressions) could you just deny /var/lib/snapd/desktop/icons for now? This is new dir which was never allowed so blocking it should be safe.

Currently it spams me with denials when I run every single snap which is annoying. I would do PR for that myself but I don’t know in which file this rule should go

ogra · October 21, 2019, 5:53pm

did you consider just renaming or deleting the dir for the moment to quieten the denials ?

Reynolds5 · October 21, 2019, 5:56pm

Wouldn’t it come back after delete with snapd update? I think renaming won’t help as it just tries to read all dirs inside /var/lib/snapd/desktop/.

ogra · October 21, 2019, 6:03pm

sure, it would come back … i was just referring to the time frame between today and the update of snapd where the fix shows up (potentially the next version since it is a tiny “fix” (1 char ?) after all)

Reynolds5 · October 21, 2019, 6:14pm

My concern is that if I fail to get developers attention this time frame may stretch up to infinity

I’ll happily deal with this myself while waiting for upstream fix just want be sure there will be something to wait for.

jdstrand · October 24, 2019, 7:08pm

I’ve added silencing the icons directory to my list of updates for 2.43.