See the quoted thread, @ali1234 (I think?) and I would like the ability to modify the profile of the Discord snap just so that we can stop various denials from logging. We know that Discord is getting denied ptrace and (when system-observe is connected), open requests, and to stop our logs getting flooded (to the point where, for me, it’s impossible to debug anything that may benefit from journald logs if I’ve had Discord open) we would like the ability to inform our snapd installs that we’re aware of the issue and to silence those logs (a nice interface in snapd to do this would be ideal, something like snap deny discord ptrace (trace) open (r) would be good). I suppose this could reset on refresh though I’m not sure if this is an issue that’ll be fixed anytime in the near-future for Discord, at least.
2 Likes
Note that this topic is only talking about AppArmor policy, but there is also seccomp and udev tagging/cgroups that could be involved. I would highly suggest not exposing security policy on the snap command line otherwise we are simply reinventing another syntax.
If it is agreed this is an approach we’d like to take, I would suggest the following:
- have each snap’s AppArmor policy #include another file (eg,
#include "/var/lib/snapd/apparmor/profiles.local/snap.discord.discord). These files are blank and never touched by snapd (except to make sure they exist). In this manner, an admin could adjust as necessary (upstream apparmor has a similar concept with system profiles in /etc/apparmor.d and /etc/apparmor.d/local). If required, we could extend this for seccomp - add a ‘quiet’ profile flag (for apparmor and possibly seccomp) and some means to toggle it. This flag would suppress all policy violation logging. This would require support from upstream AppArmor