AppArmor profile

[martijntje]

Since I would like to run Spotify on my work laptop, I need to be able to verify what it can do (policy is either open-source software, constrain with AppArmor, or run in Docker container).

I could not find an AppArmor profile. When trying to create one I noticed that the client tries to read /proc/*/cmd. Allowing this would give the app a complete view of all the processes running on the machine. This seems utterly unnecessary. I assume that it's to make sure you don't end up with multiple running spotify instances, but this is much better handled with a pid-file (maybe in /tmp/<userid>/spotify.pid).

Can anybody explain the reason for wanting this permission?

[jooon]

It shouldn't need to have all of those rights though.The client code base is quite complicated since it use CEF which uses Chromium. I don't understand all of it. The current client actually doesn't detect properly if another instance is running (which is another bug).

It does query /proc/ a bit though. I see this with strace:

$ spotify --version
Spotify version 1.0.93.238.g2712e516, Copyright (c) 2018, Spotify Ltd
$ strace /usr/bin/spotify 2>&1 | grep '/proc/'
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
openat(AT_FDCWD, "/proc/filesystems", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/proc/self/cmdline", O_RDONLY) = 4
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 64) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4096) = 26
openat(AT_FDCWD, "/proc/meminfo", O_RDONLY|O_CLOEXEC) = 37
stat("/proc/meminfo", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
openat(AT_FDCWD, "/proc/vmstat", O_RDONLY|O_CLOEXEC) = 37
stat("/proc/vmstat", {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 4095) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 99) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 64) = 26
readlink("/proc/self/exe", "/usr/share/spotify/spotify", 64) = 26

I wonder if it is following the symlink /proc/self that makes it need /proc/* access? I have never used apparmor, but would something like:

@{PROC}/@{pid}/** r,

work?

[martijntje]

Well, I can certainly add a line to allow Spotify to allow it's own process in /proc, the worrying aspect is it trying to access /proc/*/cmd.

Since /proc/self is simply a symlink, there would be no need for this. All that would happen is a readlink() on /proc/self and then a read on /proc/<pid>/...

I cannot think of any reason why Spotify would need information on all running processes on the host.

[jooon]

So, what do you see when you run this?

/usr/bin/spotify --version
strace /usr/bin/spotify 2>&1 | grep '/proc/'