WebTorrent-Desktop subprocess killed by seccomp on syscall 41 (socket)


#1

I can’t work out whether I’m missing a plug in my attempt at snapping webtorrent-desktop as requested in the wishlist thread, or if there’s a gap in the available interfaces?

= Seccomp =
Time: Oct  2 11:18:10
Log: auid=1000 uid=1000 gid=1000 ses=2 pid=26459 comm="Chrome_libJingl" exe="/snap/webtorrent-desktop/x1/WebTorrent-linux-x64/WebTorrent" sig=31 arch=c000003e 41(socket) compat=0 ip=0x7f2a2f0ce567 code=0x0
Syscall: socket

app stanza in the yaml:

apps:
  webtorrent-desktop:
    command: bin/electron-launch WebTorrent
    plugs:
      - browser-support
      - gsettings
      - network
      - network-bind
      - opengl
      - pulseaudio
      - unity7
      - x11

#2

This denial is likely due to a missing netlink rule. Unfortunately due to a limitation in the kernel that is unlikely to be resolved, seccomp denials do not include the values of the arguments to the denied syscall which makes this difficult to debug.

Today, you could put the snap in devmode, then strace it choosing -e socket and see what it is using, then add an appropriate plug. Soon, we will use EPERM instead of kill in the seccomp policy, which would mean you wouldn’t need to put the snap in devmode.

snappy-debug should be updated (it is in backlog) to list the interfaces that have netlink rules so you can better decide what to plug.

Looking at existing plugs and the name of the snap, I’m going to suggest you try to plugs network-observe (don’t forget to snap connect it!) and see if it makes a difference.


#3

these are the unique socket calls - most of these are repeated many times:

socket(0x7b /* AF_??? */, SOCK_DGRAM, 0)
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP)
socket(AF_INET6, SOCK_STREAM, IPPROTO_TCP)
socket(AF_INET6, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP)
socket(AF_INET, SOCK_DGRAM, IPPROTO_IP)
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP)
socket(AF_INET, SOCK_DGRAM|SOCK_NONBLOCK, IPPROTO_IP)
socket(AF_INET, SOCK_STREAM, IPPROTO_IP)
socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)
socket(AF_INET, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP)
socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)
socket(AF_NETLINK, SOCK_RAW|SOCK_CLOEXEC|SOCK_NONBLOCK, NETLINK_KOBJECT_UEVENT)
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0)
socket(AF_UNIX, SOCK_STREAM, 0)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC, 0)
socket(AF_UNIX, SOCK_STREAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0)

I think the first one on the list is suspect…


#4

Yes, 0x7b is 123 in decimal and AF_MAX in include/linux/socket.h is 44. If you add:

socket 123

to /var/lib/snapd/seccomp/bpf/snap.webtorrent-desktop.webtorrent-desktop.src and then run:

$ sudo /usr/lib/snapd/snap-seccomp compile /var/lib/snapd/seccomp/bpf/snap.webtorrent-desktop.webtorrent-desktop.src /var/lib/snapd/seccomp/bpf/snap.webtorrent-desktop.webtorrent-desktop.bin

and then start the application again, does it work?


#5

yes, that allows it to work better in jailmode (still no audio, but that’s another unrelated issue)


#6

That’s ‘good’, but still don’t know what ‘123’ is. This could be a bug in their code or something that should be added to snapd. I researched it and could find anything. I looked in the webtorrent-desktop upstream project and couldn’t find any use of socket…


#7

webtorrent desktop allows you to use chromecast, iirc that sort of works by opening a port locally on the device that will cast which the chromecast client would connect to (it also supports DLNA).

The upstream project itself might use it, but one of the libraries it depends on might.


#8

I believe it’s related to the torrent functionality - without the fixed seccomp policy the client cannot download anything. With the fix, both download and play work fine.

Chromecast seems unrelated as it successfully detects my CC both with and without the fix.


#9

Sorry to dig up an old post. We’re seeing the same issue with the Snap version of Wavebox when adding Google Allo. The fix suggested by @jdstrand fixed the issue when I tried it, but I was wonder if there is any way to ship this out in the built versions of the snap?


Wire snap fails to use the network
#10

I’ll do some more investigating and see if I can find anything more on the protocol. If I can, we can expose it in snapd somehow.


#11

This is usrsctp: https://github.com/sctplab/usrsctp/blob/master/usrsctplib/usrsctp.h#L109


#12

I’m preparing a PR for this now.


#13

This is committed to master. We’re working to also get it into 2.31.


#14

That’s awesome! Thank you :slight_smile: