This is discussed in Discord ptrace AppArmor denials. While we can suppress the logging with an explicit deny rule, we cannot later undo that rule. What is really needed is an apparmor ‘quiet’ rule that allows suppressing the log without explicitly denying it, and then we need to design in snapd what log suppression should like like.
That said, we’ve recently devised a method of suppressing ptrace under certain conditions (https://github.com/snapcore/snapd/pull/5980). It looks like deny capability ptrace could be added to ptraceTraceDenySnippet. I’ll consider this in the next batch of policy updates.
Keep in mind that is only for ‘ptrace (trace)’ rules and not ‘ptrace (read)’. Can you please paste some representative denials and the output of snap connections discord?
Running snap connect discord:system-observe gets rid of the denials (I’m aware there’s security issues with this but currently the denials are not silenced out-of-the-box)
This is not a security compromise. It is giving information to discord. I think the best path forward is for the discord publisher to request that system-observe be autoconnected or to detail why discord is doing this legitimately or detail what feature to turn off to make the denials stop. Ultimately this is a bug in the discord snap that should be addressed either through auto-connection, code changes or configuration.
We could look into adding an explicit deny for ptrace read on unconfined like we did in https://github.com/snapcore/snapd/pull/7019, but this isn’t going to solve everything (eg, the same sort of denial will pop up for running snaps or system confined processes). Ideally, snapd could use quiet rules or a quiet profile flag to suppress logging for this sort of thing, but this functionality is not yet available in the kernel or apparmor userspace for it to use.
I assume you mean the Discord application developer rather than the snap publisher? Because the snap publisher (snapcrafters) has requested the autoconnection via the OP, just need some +1s from reviewers for it to go through.
Perhaps the easiest thing is for us to use yad (or similar) to do a one-time punch in the face to the user that rich presence won’t work until you connect system-observe. But the downside is the giant logs.
the last update to the discord readme seems to say there discussions with upstream, is there anything can be done to get upstream aka the discord application publisher to request the autoconnection? maybe a request on their uservoice?
This came up again in https://github.com/snapcrafters/discord/issues/23#issuecomment-760365707 where I said (among other things): “there is an upcoming feature regarding apparmor ‘quiet’ rules and profile flags that would be useful. Now that AppArmor 3 is out, we’re closer to being able to implement that. Once done, snapd could add some controls (eg, snap set system:quiet-snap=discord (syntax TBD, but you get the idea) that could enable people to silence the denials in a manner that doesn’t otherwise affect the policy.”
Now that AppArmor 3 is out and we know we want to vendor AppArmor into snapd to help with our cross distro story, I asked @jjohansen about the quiet profile flag and he said that it is currently scheduled for 3.1, but might get pushed to 3.2 depending on timing and other prioritized work. @alexmurray (cc @mvo and @pedronis) - this would be a pretty neat thing for snapd to do. @lucyllewy also had an interesting idea surrounding default behavior (that I’ll let him comment on).
)