Auto-connections for discord

Wimpress · October 6, 2017, 5:48pm

Hi all,

Video calling is now enable for all users of Discord. Discord also have a couple of issue reported regarding AppArmor denials and the inability to exit the application. Those issue have been resolved buy extending the interface Discord uses. Please can we add Discord auto connections for the following interfaces:

camera - The access the camera
mount-observe - For the file picker
network-observe - For network presense detection.
process-control and system-observe - So Discord exits correctly.

niemeyer · October 6, 2017, 6:00pm

-1 on network-control unless we have further data about why this is actually necessary. Most people won’t expect discord to be fiddling with their networking.

Can we also have more details about process-control and system-observe?

camera and mount-observe sound reasonable.

lucyllewy · October 6, 2017, 6:05pm

@wimpress, would network-observe be suitable instead of network-control?

jdstrand · October 6, 2017, 6:07pm

I agree with Gustavo on network-control.

Regarding “process-control and system-observe - So Discord exits correctly.” - the default policy already allows sending signals to oneself (ie, anything running with the snap’s security label), so I suspect discord is being imprecise in trying to kill things, and the denials are a) good and b) not-fatal.

Ads20000 · October 8, 2017, 1:30pm

I think I reported the bug with Discord not exiting correctly. It’s fairly serious. I can’t actually close Discord unless I use kill in Terminal and have to use it several times, sometimes for different PIDs.

I understand the security concerns…any chance @wimpress could get in touch with the Discord devs and ask what’s up with how they’ve coded Discord’s closing?

jdstrand · October 9, 2017, 1:48am

Thank you for pointing out that bug, but it doesn’t say what the PIDs you are killing are for and it doesn’t list the security denials so we might better understand the problem. If someone could do that here, that would be fantastic.

Ads20000 · October 9, 2017, 8:27am

Here you go

Seems the repeated lines are:

apparmor="DENIED" operation="ptrace" profile="snap.discord.discord" pid=6220 comm="Discord" requested_mask="trace" denied_mask="trace" peer="unconfined"

Log: apparmor="DENIED" operation="open" profile="snap.discord.discord" name="/proc/3818/cmdline" pid=6220 comm="Discord" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /proc/3818/cmdline (read)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/cmdline'

How do we adjust Discord to do that?

I also get this in Terminal when I try to close Discord (strange, the other time I tested this the Terminal exited back to where I could type in it (leaving Discord running) rather than leaving me in the program’s Terminal output):

Failed to generate minidump.[WebContents] crashed... reloading
Feature redeclared; is this a duplicate flag?  voice_sound_stop_loop
Feature redeclared; is this a duplicate flag?  voice_relative_sounds
Feature redeclared; is this a duplicate flag?  voice_panning
Feature redeclared; is this a duplicate flag?  voice_multiple_connections
Feature redeclared; is this a duplicate flag?  media_devices
Feature redeclared; is this a duplicate flag?  media_video

The PIDs I’m killing are for two Discord processes. If I go File > Exit, it seems to kill the process that’s taking up the most RAM but leaves the other one alive - this results in Discord reloading (a new process with a new PID (called Discord) that takes up significant RAM is created) and also having a separate blank window. At this point, using File > Exit in either window doesn’t kill any processes. If I kill the process taking up less RAM (via System Monitor, for example), the program ends. If I kill the process taking up more RAM, the window that wasn’t blank goes blank (File > Exit in either window still does nothing). Then I kill the process taking up less RAM (when killing in Terminal sometimes I have to do this twice for the process to die!) and Discord closes.

This is strange because if I don’t use File > Exit and just kill the process taking up more RAM then Discord does close (both processes die).

Here’s the blank window (it seems to use Discord’s background colour):

Wimpress · October 9, 2017, 9:17am

Changing network-control to network-observe results in the following AppArmor denials being logged.

Oct  9 10:13:26 skull kernel: [605716.737513] audit: type=1400 audit(1507540406.053:33011): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=27153 comm="Discord" capability=19  capname="sys_ptrace"

As far as I can tell the application works correctly using network-observe. I’ve updated the opening post.

As for exitting Discord, if I use the Indicator and select quit the application closes correctly.

jdstrand · October 11, 2017, 4:11am

This will go away if the snap plugs ‘system-observe’. I suspect because it can’t read /proc/pid/cmdline, it isn’t finding what it wants to kill, can’t exit, crashes and tries to ptrace itself. Can someone upgrade to core snap 2.28 (it is in stable now), add this interface, make sure it is connected, then try again and report back? If there are still issues, please provide:

snap version
snap interfaces
list any security denials

Wimpress · October 11, 2017, 10:20am

@jdstrand I am running:

snap    2.28.1
snapd   2.28.1
series  16
ubuntu  17.10
kernel  4.13.0-12-generic

I have core 16-2.28.1 (3017) installed. Here are the snap interfaces for discord:

:bluez                     discord,wire
:browser-support           discord,ghost-desktop,lbry,wire
:camera                    discord,wire
:gsettings                 discord,ghost-desktop,lbry,wire
:home                      castersoundboard,discord,ghost-desktop,,node-red,podpublish,review-tools,wire
:mount-observe             discord,wire
:network                   castersoundboard,discord,emoj,ghost-desktop,lbry,lp-build-snap,lxd,matterbridge,node-red,podpublish,pulsemixer,wire
:network-observe           discord
:process-control           discord
:pulseaudio                castersoundboard,discord,ghost-desktop,lbry,pulsemixer,wire
:screen-inhibit-control    discord,wire
:system-observe            discord
:unity7                    discord,ghost-desktop,wire
:x11                       castersoundboard,discord,ghost-desktop,pulsemixer,wire

This is the only denial that remains.

Oct 11 11:08:44 skull kernel: [76321.897443] audit: type=1400 audit(1507716524.086:63997): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=25700 comm="Discord" capability=19  capname="sys_ptrace"
Oct 11 11:08:49 skull kernel: [76326.898282] audit: type=1400 audit(1507716529.087:63998): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=25700 comm="Discord" capability=19  capname="sys_ptrace"

I am experiencing the failure the exit Discord issue.

jdstrand · October 11, 2017, 6:45pm

Is this denial triggered by trying to exit?

Can you add to /var/lib/snapd/apparmor/profiles/snap.discord.discord:

capability sys_ptrace,

then run:

sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.discord.discord

start the app and try again? Does it still fail to exit? Are there new denials?

Wimpress · October 12, 2017, 11:45am

I’ve made the requested changes. Yes, Discord still fails to exit. Here are the apparmor logs:

Oct 12 12:42:13 skull kernel: [ 1416.283832] audit: type=1400 audit(1507808533.318:124): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.discord.discord" pid=10875 comm="apparmor_parser"
Oct 12 12:42:20 skull kernel: [ 1423.530101] audit: type=1400 audit(1507808540.564:125): apparmor="DENIED" operation="capable" profile="/usr/lib/snapd/snap-confine" pid=11000 comm="snap-confine" capability=2  capname="dac_read_search"
Oct 12 12:42:20 skull kernel: [ 1423.530110] audit: type=1400 audit(1507808540.564:126): apparmor="DENIED" operation="open" profile="/usr/lib/snapd/snap-confine" name="/sys/module/rfkill/uevent" pid=11000 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Oct 12 12:42:20 skull kernel: [ 1423.556602] audit: type=1400 audit(1507808540.591:127): apparmor="DENIED" operation="open" profile="snap.discord.discord" name="/etc/xdg/user-dirs.conf" pid=11057 comm="xdg-user-dirs-u" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

When attempting the exit Discord it segfaulted.

Oct 12 12:42:37 skull kernel: [ 1440.378478] Discord[11208]: segfault at 70 ip 00007fb1eca41330 sp 00007fb1e77faae8 error 4 in discord_utils.node[7fb1eca23000+23000]

jdstrand · October 13, 2017, 2:27am

The two snap-confine denials shouldn’t affect this (I’ve taken a todo to fix the uevent denial, the user-dirs.conf is already on the list to look at). The read on /etc/xdg/user-dirs.conf also should not affect the exit (I suspecct all of these happen on start, not at exit).

You said before the issue is resolved if you connect process-observe, is that correct? (I don’t see a denial related to process-observe in your last paste).

jdstrand · October 27, 2017, 6:30pm

https://github.com/snapcore/snapd/pull/4097 has a fix for the user-dirs.conf denial. I’ve requested it for 2.29.

jdstrand · October 27, 2017, 6:42pm

The uevent denial has a fix in https://github.com/snapcore/snapd/pull/4098. I’ve requested this for 2.29.

Ads20000 · May 5, 2018, 2:07am

From Discord ptrace AppArmor denials (that topic was actually a repetition of what I said earlier in this topic oops):

@wimpress can you ask the Discord devs to adjust or is that unlikely to happen and we should again request auto-connecting this interface?

jdstrand · May 23, 2018, 9:48pm

I was reminded that there was no vote for system-observe. I’d like to hear back from upstream before casting my vote.

Ads20000 · February 22, 2019, 11:43pm

What could be causing the following denial?

[ 9217.259134] audit: type=1400 audit(1550748163.700:6490): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19  capname="sys_ptrace"
[ 9222.258887] audit: type=1400 audit(1550748168.700:6491): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19  capname="sys_ptrace"
[ 9227.261310] audit: type=1400 audit(1550748173.704:6492): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19  capname="sys_ptrace"
[ 9242.263344] audit: type=1400 audit(1550748188.704:6493): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19  capname="sys_ptrace"
[ 9247.264970] audit: type=1400 audit(1550748193.708:6494): apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=5462 comm="Discord" capability=19  capname="sys_ptrace"

A user says that these aren’t resolved by connecting system-observe and unity7…

Applies to Discord 0.0.8 2019-02-14 (91) on core 16-2.37.2 (6405) (current versions, as of 23/02/2019 15:42 GMT+0) on Ubuntu 18.04.

lucyllewy · February 23, 2019, 4:10pm

Try process-control. Ptrace is a debugging thing. You can also try using snappy-debug which will advise relevant interfaces for things it sees being blocked while you run it at the same time as your app:

sudo snap install snappy-debug 
snappy-debug.security scanlog

Press ctrl + c to stop it again. Run your application in a second terminal and reproduce the denial - snappy-debug will output its advise in the first terminal.

Ads20000 · February 26, 2019, 5:58pm

The new reporter on GitHub has given the following output:

= AppArmor =
Time: Feb 25 16:55:33
Log: apparmor="DENIED" operation="capable" profile="snap.discord.discord" pid=7216 comm="Discord" capability=19  capname="sys_ptrace"
Capability: sys_ptrace
Suggestions:
* adjust program to not require 'CAP_SYS_PTRACE' (see 'man 7 capabilities')
* do nothing if program otherwise works properly

I reckon Discord wants advanced permissions because it observes if games are running and then automatically displays the user on Discord as playing that game. It’s an active status thing. I doubt the problem with Discord’s permissions will be resolved unless snappy and Discord find a way to give Discord more limited fine-grained access to view what processes are running (rather than giving it full process-control)…

Is there any way of silencing the denials so they don’t clutter the journal? I think I must’ve silenced mine at some point because they’re not coming up anymore but I can’t remember how I did that and the reporter wants to know!