discord spamming log with apparmor="DENIED" messages

[wilx]

I have installed Discrod application on Ubuntu 18.04. When I run it, it spams log with several messages per second like this:

audit[17638]: AVC apparmor="DENIED" operation="ptrace" profile="snap.discord.discord" pid=17638 comm="Discord" requested_mask="trace" denied_mask="trace" peer="unconfined"

The above are the main bulk. Then there are few like the following sprinkled around:

AVC apparmor="DENIED" operation="open" profile="snap.discord.discord" name="/proc/2750/cmdline" pid=17638 comm="Discord" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

[wilx]

> snap list discord
Name     Version  Rev  Tracking  Publisher     Notes
discord  0.0.5    73   stable    snapcrafters  -

[popey]

@wilx Apologies for the delay. Can you please try snap connect discord:process-control and see if that makes it go away.

[wilx]

@popey commented on Sep 27, 2018, 12:38 PM GMT+2:

@wilx Apologies for the delay. Can you please try snap connect discord:process-control and see if that makes it go away.

That didn't help. But connecting the discord:system-observe plug seems to have fixed the spam. The question is, do I really want Discord to have those privileges?

[furioness]

Ubuntu 18.04. Still unfixed.
I disabled all scanning stuff that discord's menu gives but still have spam.

[lathiat]

This is a duplicate of #23

[Fuseteam]

it comes don't to discord's "Status messages" there is a thread on what could be done for finer control in #23

[ThePythonicCow]

Working with my son, a gamer, and with my own skills using the strace(1) command, I think I figured out what Discord is doing that is generating all the log file spam, when Discord is run inside a Snap sandbox.

Discord has a "feature" where it automatically tells all your Discord friends what game you're playing, with a "Playing World of Warcraft" (or whatever game) below your name on your friend's Discord panel(s).

Discord implements this feature by doing a scan, once every five seconds, of every numeric entry in the /proc file system. Let's say your current Linux user id is "joe", and one (of hundreds) of processes you are running is process pid == 999. Then Discord will first stat "/proc/999", and if that proc directory is owned by yourself, "joe", it will then further try to "open /proc/999/cmdline" and " readlink /proc/999/exe", in an effort to see if you're also running a recognized game executable. If (for example) it sees that you're running a World of Warcraft executable, it will tell your connected friend's Discords to add the "Playing ..." annotation below your name "Joe" on their Discord. The above stat of "/proc/999" call does not generate an error (when run by Discord inside a snap sandbox), but the additional two " open /proc/999/cmd" and "readlink /proc/999/exe" do generate EACCES (Permission denied) errors. If the only entries that Discord found matching the pattern "/proc/NNN", for some decimal number NNN, were not owned by the current Discord user, then I imagine that Discord would quietly decide that you're not running any recognized games and go on about its other business, until the next five second loop.

So ... question for snap experts. Could the Discord snap be packaged with a fake "/proc" file system, that contained exactly one entry, an empty directory "/proc/1", owned by uid 65535 (nobody)? I'd wager that Discord would cease flooding my log files with these error messages.

[wilx]

I wonder if they couldn't do the access(2) check first to avoid the issue.

[ThePythonicCow]

The access(2) system call, to quote the man page:
allows set-user-ID programs and capability-endowed programs to easily determine the invoking user's authority. In other words, access() does not answer the "can I read/write/execute this file?" question. It answers a slightly different question: "(assuming I'm a setuid binary) can the user who invoked me read/write/execute this file?", which gives set-user-ID programs the possibility to prevent malicious users from causing them to read files which users shouldn't be able to read.

In my experience, this access(2) call is over-used. It's only relevant in the case of setuid executables, which probably does not apply here. I'd guess that most likely, if Discord did first ask if it could "access(2)" these proc cmdline and exe files, the access would either succeed, because according to the permission bits on the file said it was OK, or the access would fail in the same way that the current open and readlink calls fail, because Discord is prohibited by the apparmor code from referencing these /proc/NNN/{cmdline,exe} files at all.

In any case, it seems that Discord is less interested in lifting a finger to help this problem than the Snapcrafters might be, so a snap workaround with a fake "/proc/1" subtree might be more likely to happen, if it works, than a change to the Discord code ... all just guesses and surmises on my part of course.

[ThePythonicCow]

Above I suggested:

So ... question for snap experts. Could the Discord snap be packaged with a fake "/proc" file system, that contained exactly one entry, an empty directory "/proc/1", owned by uid 65535 (nobody)? I'd wager that Discord would cease flooding my log files with these error messages.

This suggestion of mine fails. Discord has additional expectations on certain entries under /proc and elsewhere in snap's "core" and "snapd" runtime.

Discord also expects to examine the read the symlink "/proc/self/exe", to see by what name it was invoked.

Such examination of /proc/self/exe is fairly common in Linux, allowing a single binary executable file to behave differently, depending on what name it was called when executed.

I hacked around that /proc/self/exe symlink problem, then hit another problem. Discord expected to read /proc/self/mountinfo in order to "determine nfs usage in generateSystemKey" (quoting its error message.)

I hacked around that.

I then got an error system_key.go:142: cannot determine seccomp compiler version in generateSystemKey: fork/exec /snap/snapd/current/usr/lib/snapd/snap-seccomp: no such file or directory

I hacked around that.

I then got an error system_key.go:142: cannot determine seccomp compiler version in generateSystemKey: invalid version-info length: "2c4cf1ac0f802f4eb72a2ae972b18425228c8510 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af bpf-actlog"

I then gave up.

Perhaps I will next try running Discord inside a virtual machine, that I can setup just to keep Discord happy (and deprive it of the opportunity to spy on what else I run on my system.)

[Fuseteam]

can the people with this issue check the latest comment in #23

[flexiondotorg]

Duplicate of #23