Bug 200182 – Allow more syscalls in the WebContent process' sandbox profile

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit2

[Chris Dumez]

Allow more syscalls in the WebContent process' sandbox profile to avoid getting killed.

[Chris Dumez]

<rdar://problem/53594973>

[Chris Dumez]

Created attachment 374998 [details]
Patch

[Alexey Proskuryakov]

Comment on attachment 374998 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=374998&action=review

> Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:945
> +        (syscall-number SYS_recvmsg)

This one looks suspicious. Looking at the logs, it seems like there is actual networking happening in WebContent, which is not allowed. So we may need a higher level fix here.

[Chris Dumez]

Comment on attachment 374998 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=374998&action=review

>> Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:945
>> +        (syscall-number SYS_recvmsg)
> 
> This one looks suspicious. Looking at the logs, it seems like there is actual networking happening in WebContent, which is not allowed. So we may need a higher level fix here.

I am no sandboxing expert so I followed the existing pattern. We already allow SYS_recvfrom / SYS_recvfrom_nocancel / SYS_sendto / SYS_sendmsg_nocancel / SYS_sendto_nocancel.

[Chris Dumez]

Comment on attachment 374998 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=374998&action=review

>>> Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:945
>>> +        (syscall-number SYS_recvmsg)
>> 
>> This one looks suspicious. Looking at the logs, it seems like there is actual networking happening in WebContent, which is not allowed. So we may need a higher level fix here.
> 
> I am no sandboxing expert so I followed the existing pattern. We already allow SYS_recvfrom / SYS_recvfrom_nocancel / SYS_sendto / SYS_sendmsg_nocancel / SYS_sendto_nocancel.

Couldn't it be a socket used to talk to a daemon, as opposed to actual networking?

[Alexey Proskuryakov]

> Couldn't it be a socket used to talk to a daemon, as opposed to actual networking?

I have no definitive proof, but I doubt it - there's always com.apple.NSURLConnectionLoader thread in those processes, and usually people who use sockets use them through low level API.

> I am no sandboxing expert so I followed the existing pattern. We already allow SYS_recvfrom / SYS_recvfrom_nocancel / SYS_sendto / SYS_sendmsg_nocancel / SYS_sendto_nocancel.

Maybe all of those are wrong :-O

[Geoffrey Garen]

Comment on attachment 374998 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=374998&action=review

r=me

>>>> Source/WebKit/WebProcess/com.apple.WebProcess.sb.in:945
>>>> +        (syscall-number SYS_recvmsg)
>>> 
>>> This one looks suspicious. Looking at the logs, it seems like there is actual networking happening in WebContent, which is not allowed. So we may need a higher level fix here.
>> 
>> I am no sandboxing expert so I followed the existing pattern. We already allow SYS_recvfrom / SYS_recvfrom_nocancel / SYS_sendto / SYS_sendmsg_nocancel / SYS_sendto_nocancel.
> 
> Couldn't it be a socket used to talk to a daemon, as opposed to actual networking?

FWIW, in the traces I saw, each call to recvmsg was triggered by a network connection failure. Seems like someone might have tried to do some networking, but didn't necessarily succeed.

Given that these similar sys calls are already allowed, I'm inclined to allow this one too, so folks can stop crashing while we figure out how to generally remove access to this set of syscalls.

[Alexey Proskuryakov]

Comment on attachment 374998 [details]
Patch

Let's not be in such a crazy hurry.

[Alexey Proskuryakov]

> SYS_sendto 

Used by ASL logging facility, so definitely needed.

> SYS_recvfrom_nocancel 
> SYS_sendmsg_nocancel 
> SYS_sendto_nocancel

Very few tests hit these, http/tests/workers/service/serviceworker-websocket.https.html being one of those.

> SYS_recvfrom 

I didn't see this one hit on layout tests, but I did see SYS_recvmsg, the same test reproduces it. Maybe the internal implementation in libnetwork switched from one to another after Per Arne's initial testing.

So WebSockets in service workers try to use networking in WebContent. This appears related to bug 200161 and bug 199906. The former has a fix posted today, so we should re-test and hopefully remove the unnecessary syscalls.

I suggest landing this patch with only SYS_chmod_extended and SYS_lstat_extended added for now. We also need to wire service worker processes to WebKitTestRunner's crash reporting - it's quite unfortunate that these crashes are currently silent during tests.

[Chris Dumez]

Committed r247890: <https://trac.webkit.org/changeset/247890>