AppArmor denial cluttering systemd logs #23
Comments
|
Yeah, it seems like discord likes to interrogate other applications on the system, probably so it can show to your friends what game you're currently playing. I don't know what we can do about this. I expect there needs to be a tweak to the apparmor policy. I think we may need to get jdstrand involved. Mind starting a forum thread? |
|
Will do, thanks for the speedy response 😃 |
@popey should that last one be added to the README? Or maybe we could remove them all? I'm not sure Discord needs any of them and seems to only need |
|
Sorry, I know this is closed, but the issue is still there. I do not consider it fixed by running those commands because of 2 reasons:
this is not acceptable |
|
To remove the need to manually connect Also, please could you (Daniele) attach the outputs of: You can use the HTML below to make it look nice! |
Discord 0.0.8 2019-02-14 (91)thank you @Ads20000 |
|
@danielesegato as @diddledan on the forum suggests, could you please run then in a Terminal whilst Discord is running? Then provide the output (in Note that it might not be possible to ever make this automatic because it might be that the snappy team are never convinced that Discord needs these permissions to run. Snaps are confined and should be reasonably safe for you to run, giving Discord automatic access to things like |
|
@Ads20000 it's not gonna contains much usefulness sys_ptrace snappy debug |
|
I totally agree about being unreasonable. |
|
As far as I know, the apparmor logs are somewhat of an issue resulting from the fact that's surprisingly convoluted to deny specific apparmor messages silently in the autogenerated snap apparmor config files. I have a way for doing it manually, but every snap update/tiny change breaks that. By adding to then running |
|
what is it even denying? can/should we allow it instead?
…On Mon, Mar 11, 2019, 15:52 Rigo ***@***.***> wrote:
As far as I know, the apparmor logs are somewhat of an issue resulting
from the fact that's surprisingly convoluted to deny specific apparmor
messages silently in the autogenerated snap apparmor config files. I have a
way for doing it manually, but every snap update/tiny change breaks that.
By adding to /var/lib/snapd/apparmor/profiles/snap.discord.discord:
deny capability sys_ptrace,
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#23 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJ8GW17mcogqGq6q7PIcLb4PLXn7Au01ks5vVqX2gaJpZM4TfuTg>
.
|
FYI, my comment here: https://forum.snapcraft.io/t/auto-connections-for-discord/2392/21 where we can update our conditional explicit deny policy. |
doing this and deactivating streamer mode (searching for running apps like obs, ..) and tracking of currently played games fixed the issue on my end. |
|
I agree with @danielesegato I don't want to provide the access discord wants, but i don't want it cluttering my log files. I would like it to fail silently. The level of log spam is absurd. |
|
See my new analysis of what Discord is doing, and a possible workaround (if the Snap packagers think it is practical) at #43 |
|
It's not that hard to check if the syscall failed ( |
|
canonical/snapd#7019 (ie canonical/snapd@a87003c#diff-a34e166c5b3016c122430c5884f41e9b) was included in snapd 2.40. People who are still seeing this, can you perform |
|
I am still seeing this. I have manually connected |
Can you perform a: If I do that here, I see: Also, can you paste some representative apparmor denials you are still seeing? |
|
Also note, while discord plugs syste-observe, process-control and network-observe, these are not auto-connected by default. |
|
@wilx - right, those are different denials that should go away once you 'snap connect discord:system-observe'. |
|
This is still a, frustrating, issue.... What if I don't want Discord to be connected to system-observe? |
|
@douglasg14b its a "feature" of discord to show off what your doing |
Are you referring to my post? |
|
isn't it labeled as bug? |
|
Strictly speaking, the apparmor profile should explicitly allow or deny every action that the application attempts. Explicitly denied actions are not logged even though they are blocked. So, while I can see the case to be made that this behavior is expected (and indeed it is from the perspective of apparmor), in my opinion, the lack of an explicit deny entry in the apparmor profile is a bug in the profile. These logs exist to tell you that your profile needs fixed. Since snapd generates the profile from the application's manifest, this could be thought of as a bug in either the application manifest failing to ask for that action to be allowed or denied, or in snapd for not providing a manifest syntax to make that feasible. I prefer the latter since this is a very common issue in among snaps. Ideally, discord should have a user-visible setting to disable whatever feature relies on ptrace, assuming it has a legit reason to do it, but no one puts effort into the linux build of multiplatform apps so that's not going to happen. |
Yes, of course it's a bug. If the original Discord application uses the ptrace system call, then the snap must of course allow it (if users don't want this, then let them disable it. Opt-in.) ptrace is a system call that allows a program to inspect other program run by the same user. For instance, it's used for debugging other programs. Discord might use it to find out what the user is currently running - I've seen some Discord status messages that say: "currently playing minecraft" or similar messages. Obviously, package providers like snap cannot substitute their own judgement for how an application should work - that's the purview of the user. |
I'd be all for that but snap makes it very hard for users to override the generated profile.
Just telling which applications are running is possible without ptrace by inspecting The thing that gets me is that the feature that says what map someone is playing (in a fps), what queue they are in (in a moba) or what dimension they are in in minecraft - which requires a more in-depth inspection than the procfs can provide - still works on my case in spite of ptrace being denied. I've always wondered how discord manages to do that, and what more it would be using ptrace for if it were allowed. Perhaps it detects ptrace is being denied and uses some other method instead. |
|
You can attach strace. For instance, assuming that - for my warning - 141 actually corresponds to where 488284 is an internal thread previously listed as: Presumably, they are trying to assign this thread to the real-time scheduling priority class ( Unfortunately, the real-time priority classes are reserved for root (typically), so they cannot possibly expect that to work. |
Root is not the only way to gain access to RT priority. A non-root app can increase it's own priority or the priority of any other app if it has the |
Dude that's exactly what snapcrafters does. See https://github.com/snapcrafters
|
|
@memory-thrasher |
Ok fair. I do hate everything about snap and would gladly live without it if discord had another sane deployment option. Manually re-downloading a deb annoyed me just as much. |
|
For a "sane" deployment you need an automated setup mechanism for generating a fresh clean sandbox (probably in qemu) with just minimal config each time you want to start discord. Checking for a new deb and potentially downloading it should be a tiny part in comparison. |
That doesn't sound sane to me. Discord has too many features that wouldn't work when sandboxed (screen sharing for example). I am talking about the deployment environment discord should provide. It would not include any sandboxing because discord devs trust discord devs. Sandboxing is what a (paranoid) user would add. It would update itself as it does on windows without a third-party sandboxing tool like snap to find and whine about suspicious system calls and we would never know. That is very different from the insane (paranoid) user setup that I am now considering implementing. There is also a tarball download option for discord. I am looking at putting that into a user-writable directory that is covered by a strict, static, custom-made apparmor profile. |
Explain what you mean by that. Do you think Discord expects to be packaged in a snap in a way that it has Also, how can an apparmor profile hand out elevated privileges? I was under the assumption that this would require |
System capabilities are separate from and predate apparmor. You're right, apparmor does not hand them out, and the app does have to request them. Apparmor can either deny the request or allow it. What I mean is that it is common for apps to require admin ("require" means the app crashes if the capability is denied), and therefore it is also common for apparmor profiles to explicitly allow the application to acquire that capability. As the apparmor docs say regarding granting capabilities:
|
|
I think this would require to run the app as sudo (or in a container). This is because below all of snap, AppArmor, containers, etc. you still have the old-fashioned Unix model where you can't just declare that you want to be or partially act like |
One would think, but no. It only has to have the capability set on the binary (the same way sudo gains root), and that bit is set by the installer (snap or deb). |
|
ofc, only root can set that bit, but everyone and their dog runs the installers as root because they've been trained to. |
|
|
well on my box that is a directory so yeah. |
|
Copy and paste mistake. I meant |
|
hmm. sudo is also showing empty on my end. I've never used |
to answer your question though, yes and no, I think discord expects to be packaged in a way that does not deny those capabilities. Apparmor allows everything when there is no profile for an executable, and lots of apps use those capabilities, even when run without root. If it were run as root, it would not need capabilities to grant subsets of what root can always do. Giving non-root applications specific elevated capabilities is why the whole concept of capabilities exists. |
|
Thanks to some comments in this thread, I got rid of most of the spam that was printed on a regular interval by copying the discord snap profile ( Then loading this change using I am running Ubuntu 22.04.4 LTS EDIT: I just saw that this already has been posted #23 (comment) |
|
Sorry if this was already posted, but I wanted to share a completely different solution I've been very happy with. I completely removed the Discord application from my system, and proceeded to create a application shortcut to discord from my browser. This created a I've used both the deb packages and snap packages in the past - but this is by far the best experience I've had. (I'm sure some features are not available with this approach, but so far it's been great for my usage...) https://superuser.com/questions/33548/starting-google-chrome-in-application-mode |
That'll work in the short term but expect troubles with the next update. Snap will regenerate a new profile with those rules still missing, and attempt to load it. Either it'll replace yours or it'll fail to load, depending on how snap attempts it. |
To bring context back, the logs are indeed a sign that action should be taken. That action is the command @kenvandine posted.
The solution is technically to have that be autoconnected but half this thread does not want that despite this being a built in function of discord: rich presence. Discord has a ui switch for it, but it's only surface level. This is the conclusion reached years ago. There has been attenpts to reach out to discord about it, but afaict discord has been despondent. However if the decision has been made to no longer pursue autoconnection— perhaps the permission should be denied by default, maybe a PR is in order? |
That's a temporary, per-installation measure. Even when pasted into the readme, that is at best a workaround. The default profile (generated from the manifest) should work without log spam, one way or the other.
Yes and yes. I for one do not want discord to have ptrace, but I can do that on my end so I don't care much what the default is.
Where? I looked through the entire settings menu and could not find one, nor can I now with internet searches.
Agreed. The current default behavior is agreeably broken, and this is the smallest change that fixes it (as it's denied now, just less quietly). The readme will still be there for people who want to enable it (though might need re-wording), though I for the life of me cannot tell what feature needs ptrace (as previously stated, everything that should need it seems to work without it) and therefore I cannot imagine anyone going out of their way to enable it. |
|
I myself would really like it if the discord snap would deny the above mentioned instead of logging them. Alternatively this sounds like a case for some way for users to be able to add permanent modifications to their snap app profiles, in theory this could perhaps even be some sort of GUI, but that would probably be a lot of work if it doesn't exist already. One alternative perhaps could be to have some sort of patch files that are automatically applied to new versions or something like that.
Same here, I do not need discord to announce my activities, or even for it to know about it itself. |
That's not a bad idea, but is way beyond what this repo is about. That would be a feature of snap or a new package entirely.
Again, discord seems to do this even while ptrace is denied. ptrace being denied does not seem to affect what features work at all in my testing. Your (andoks) |
Turns out discord tarball and snap behave very differently, but both use an external suid binary to gain temporary elevation and then capabilities from there. snap:strace shows that executing
When allowed to run normally, the snap discord wrapper eventually calls the actual discord binary like so:
While that binary runs as the normal user, it clearly has capabilities that were set up by (and inherited from) the "confine" process. From previous experience, tarball:The discord tarball includes a bundled install of chrome, including a binary called
I am currently working on creating a restrictive apparmor profile that will allow me to run discord without snap nor the obtrusive system calls. |
and others
audit[6291]: AVC apparmor="DENIED" operation="ptrace" profile="snap.discord.discord" pid=6291 comm="Discord" requested_mask="trace" d(I can't see the rest of the line throughsystemctland I can't open the file in Text Editor (it's too big) andcatandnanocan't seem to read it (is that normal?)) is repeated many times in /var/log/journal/system.journal making it 100MB for just a few days of logging. The /var/log/journal directory is over 4GB.The text was updated successfully, but these errors were encountered: