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

Reynolds5 · 2019-10-11 13:07:59 UTC

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:

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,
# 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.

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,
/usr/share/applications/{,*} r,
/var/lib/snapd/desktop/applications/{,*} r,
owner @{PROC}/@{pid}/fd/[0-9]* w,


# Various files in /run/udev/data needed by Chrome Settings. Leaks device
# information.
# input
/run/udev/data/c1:[0-9]* r,   # /dev/psaux
/run/udev/data/c10:[0-9]* r,  # /dev/adbmouse
/run/udev/data/c13:[0-9]* r,  # /dev/input/*
/run/udev/data/c180:[0-9]* r, # /dev/vrbuttons
/run/udev/data/c4:[0-9]* r,   # /dev/tty*, /dev/ttyS*

github.com

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


bus=session
path=/com/canonical/unity/launcherentry/[0-9]*
interface="{com.canonical.dbusmenu,org.freedesktop.DBus.Properties}"
member=Get*
peer=(label=unconfined),


# unity messaging menu
# first, allow finding the desktop file
/usr/share/applications/ r,
# this leaks the names of snaps with desktop files
/var/lib/snapd/desktop/applications/ r,
/var/lib/snapd/desktop/applications/mimeinfo.cache r,
# parallel-installs: when @{SNAP_INSTANCE_NAME} == @{SNAP_NAME},
# this leaks read access to desktop files of parallel installs of the snap
/var/lib/snapd/desktop/applications/@{SNAP_INSTANCE_NAME}_*.desktop r,


# then allow talking to Unity DBus service
dbus (send)
bus=session
interface=org.freedesktop.DBus.Properties
path=/com/canonical/indicator/messages/service

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 · 2019-10-12 00:54:34 UTC

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 · 2019-10-21 17:49:40 UTC

@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 we 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 · 2019-10-21 17:53:49 UTC

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

Reynolds5 · 2019-10-21 17:56:38 UTC

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 · 2019-10-21 18:03:29 UTC

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 · 2019-10-21 18:14:07 UTC

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.