1619661 - [socket-process] Investigate and restrict the kind of sockets the SocketProcess can connect to

Status: ASSIGNED

(Core :: Networking, enhancement, P2)

Comment 1

[Gian-Carlo Pascutto [:gcp]]

As pointed out on Matrix, prctl() is currently completely unrestricted as well.

Comment 2

[:gerard-majax]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)

As pointed out on Matrix, prctl() is currently completely unrestricted as well.

I did a quick change, moving to just the SandboxPolicyCommon and a mach try auto seems to be not in such a bad shape after all: https://treeherder.mozilla.org/jobs?repo=try&revision=c9c2089b10ce3cd94934943970288ef43db7d72c

Comment 3

[:gerard-majax]

(In reply to Alexandre LISSY :gerard-majax from comment #2)

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)

As pointed out on Matrix, prctl() is currently completely unrestricted as well.

I did a quick change, moving to just the SandboxPolicyCommon and a mach try auto seems to be not in such a bad shape after all: https://treeherder.mozilla.org/jobs?repo=try&revision=c9c2089b10ce3cd94934943970288ef43db7d72c

Which might just be because: MOZ_FORCE_USE_SOCKET_PROCESS=1 is not enforced, when I enforce it locally, not even changing the sandbox, it's already impossible to open a website :)

Comment 4

[:gerard-majax]

So, I've been able to make progress (there was a breakage of DNS as mentionned in comment #3 because of glibc) and I can load a few pages with socket process enforced.

In order to properly continue my investigation, I'd like to make sure whether we want to restrict sockets for any use by the browser or if it's only focused on running for TLS/WebRTC as mentionned in the doc linked on the beta bug 1322426 ?

Comment 5

[Michael Froman [:mjf]]

I wasn't a part of the discussions for that document, but my understanding was that eventually all network access would move to the new process. WebRTC was just the first early adopter. I happened to be available to make some tweaks to the socket process startup/teardown and sandboxing since I'd worked through some of those issues on the RDD process. Sorry I don't have more info beyond that.

Comment 6

[:gerard-majax]

(In reply to Gian-Carlo Pascutto [:gcp] from comment #1)

As pointed out on Matrix, prctl() is currently completely unrestricted as well.

M-spi on https://treeherder.mozilla.org/jobs?repo=try&revision=86aec66ad4910ac9414f7b640a84f24d44f534fc should now follow the common prctl policy instead of Allow().

Comment 7

[Kershaw Chang [:kershaw]]

(In reply to Alexandre LISSY :gerard-majax from comment #4)

So, I've been able to make progress (there was a breakage of DNS as mentionned in comment #3 because of glibc) and I can load a few pages with socket process enforced.

Could you explain more about the DNS problem? I think DNS service should be working with MOZ_FORCE_USE_SOCKET_PROCESS=1.

In order to properly continue my investigation, I'd like to make sure whether we want to restrict sockets for any use by the browser or if it's only focused on running for TLS/WebRTC as mentionned in the doc linked on the beta bug 1322426 ?

Since the ultimate goal is moving all network access from parent process to socket process, I think we can't only focus on running TLS/WebRTC. We might need to allow socket process to open more than TCP and UDP sockets.
Apart from TCP and UDP, we might also want to allow socket process to open domain sockets. On windows, we could create a name pipe here.

Comment 8

[:gerard-majax]

(In reply to Kershaw Chang [:kershaw] from comment #7)

(In reply to Alexandre LISSY :gerard-majax from comment #4)

So, I've been able to make progress (there was a breakage of DNS as mentionned in comment #3 because of glibc) and I can load a few pages with socket process enforced.

Could you explain more about the DNS problem? I think DNS service should be working with MOZ_FORCE_USE_SOCKET_PROCESS=1.

Basically, trying to use MOZ_FORCE_USE_SOCKET_PROCESS=1 here locally on m-c would just fail silently on getaddrinfo() returning ENONAME. It turned out to be glibc doing stat64("/"): https://sourceware.org/git/?p=glibc.git;a=blob;f=nss/nss_database.c;h=cf0306adc47f12d9bc761ab1b013629f4482b7e6;hb=9826b03b747b841f5fc6de2054bf1ef3f5c4bdf3#l396

Allowing this in the socket process unblocked it for me, but I'm unclear whether this is an expected failure or a new regression.

In order to properly continue my investigation, I'd like to make sure whether we want to restrict sockets for any use by the browser or if it's only focused on running for TLS/WebRTC as mentionned in the doc linked on the beta bug 1322426 ?

Since the ultimate goal is moving all network access from parent process to socket process, I think we can't only focus on running TLS/WebRTC. We might need to allow socket process to open more than TCP and UDP sockets.

Thanks!