Closed Bug 969715 Opened 6 years ago Closed 3 years ago
RTC creates a PF _NETLINK socket in the content process
58 bytes, text/x-review-board-request
0 libc.so + 0xcf00 1 libxul.so!getifaddrs [ifaddrs_android.cpp : 119 + 0x7] 2 libxul.so!sctp_init_vrf_list [sctp_bsd_addr.c : 460 + 0x9] 3 libxul.so!sctp_pcb_init [sctp_pcb.c : 6745 + 0x5] 4 libxul.so!sctp_init [sctp_usrreq.c : 162 + 0x3] 5 libxul.so!usrsctp_init [user_socket.c : 81 + 0x3] 6 libxul.so!mozilla::DataChannelConnection::Init(unsigned short, unsigned short, bool) [DataChannel.cpp : 343 + 0xb] 7 libxul.so!sipcc::PeerConnectionImpl::EnsureDataConnection(unsigned short) [PeerConnectionImpl.cpp : 952 + 0xf] 8 libxul.so!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, nsDOMDataChannel**) [PeerConnectionImpl.cpp : 1030 + 0x3] 9 libxul.so!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, mozilla::ErrorResult&) [PeerConnectionImpl.cpp : 1004 + 0x13] 10 libxul.so!mozilla::dom::PeerConnectionImplBinding::createDataChannel [PeerConnectionImplBinding.cpp : 917 + 0x2d] This should be remoted to the parent process at some point in this stack.
Bug 916427 and changes to the config we use should eliminate any external socket creation.
Assignee: nobody → rjesup
Should this be marked as depending on bug 916427?
A relevant fact: our content processes already can't create AF_INET or AF_INET6 sockets — they aren't in the AID_NET group and the kernel has CONFIG_ANDROID_PARANOID_NETWORK=y. So if usrsctp is trying to do any of that in the content process, then it's already broken on b2g.
If I modify the syscall filter to reject all socket()s with EACCES, then the mochitests in gecko/dom/media/tests all pass and the test at http://mozilla.github.io/webrtc-landing/data_test.html appears to work. So that seems to also be possible as a workaround (and indicates that whatever is going on in sctp_pcb_init isn't actually necessary).
This is no longer a seccomp blocker, as of bug 974230; clearing needinfo.
Since we landed Bug 916427 I should look at this again - the dependency was missing
Depends on: 916427
Michael - FYI. I'll look at this soon
Rank: 35 → 25
Priority: P3 → P2
The call is needed if you want to support SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6. However, for SCTP/DTLS/UDP/IPv4 or SCTP/DTLS/UDP/IPv6 as used by WebRTC this is not needed. You can disable the support of SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6 by NOT defining INET and INET6 when compiling the usrsctp stack and in all files which include usrsctp.h. You can remove INET from https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/src/moz.build#56 https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/datachannel/moz.build#26 and INET6 from https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/src/moz.build#64 https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/datachannel/moz.build#30 There should be no change for WebRTC.
Comment on attachment 8817593 [details] Bug 969715: remove INET and INET6 from sctp build env. https://reviewboard.mozilla.org/r/97824/#review98194
Attachment #8817593 - Flags: review?(rjesup) → review+
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/572fdb501218 remove INET and INET6 from sctp build env. r=jesup
You need to log in before you can comment on or make changes to this bug.