1713999 - Sandbox the socket process on OpenBSD with pledge/unveil

Status: RESOLVED FIXED

(Core :: Security: Process Sandboxing, enhancement, P5)

Description

[Landry Breuil (:gaston)]

similar to bug #1713745 for RDD, let's try to apply OpenBSD sandboxing (cf bug #1457092 for main/content & bug #1580268 for GPU) to the new socket process i'm seeing with 90.0b1.

I think i have the right code to enable sandboxing at the same spot as windows does (same thing as for GPU) now i just need to figure out at runtime what files the process tries to access to tighten filesystem access via unveil (http://man.openbsd.org/unveil), and what syscalls it tries to do to enable pledge (http://man.openbsd.org/pledge).

If there's a better spot to enable/start sandboxing i'm all ears. Generally, on OpenBSD we enable sandboxing as soon as possible, but on the other hand if some syscalls/file system access is done early in the process initialization and arent needed anymore afterwards (eg when the 'main loop' starts) then it's a better time to enable sandboxing with less capabilities.

Comment 1

[Landry Breuil (:gaston)]

Attachment: patch-netwerk_ipc_SocketProcessImpl_cpp

start sandboxing at the same spot as windows, for now..

Comment 2

[Landry Breuil (:gaston)]

t o read the sandboxing config for the socket process, this chunk is also needed in dom/ipc/ContentChild.cpp:

 10      case GeckoProcessType_GPU:
 11        OpenBSDFindPledgeUnveilFilePath("pledge.gpu", pledgeFile);
 12        OpenBSDFindPledgeUnveilFilePath("unveil.gpu", unveilFile);
 13 +      break;
 14 +
 15 +    case GeckoProcessType_Socket:
 16 +      OpenBSDFindPledgeUnveilFilePath("pledge.socket", pledgeFile);
 17 +      OpenBSDFindPledgeUnveilFilePath("unveil.socket", unveilFile);
 18        break;
 19 -      
 20      default:

Comment 3

[Landry Breuil (:gaston)]

:gcp, feedback and help welcome on sandboxing this, or direct me to the right person :) thanks !

Comment 4

[Gian-Carlo Pascutto [:gcp]]

Alexandre has most recently worked on this, he can take a look at it, I can help if needed.

Comment 5

[Landry Breuil (:gaston)]

i've made good process on sandboxing the process, but so far i havent figured out what it actually does. using MOZ_LOG=socketprocess:5 only shows this at process startup:

[(null) 61702: Main Thread]: D/socketprocess CONSTRUCT SocketProcessChild::SocketProcessChild
[Socket 61702: Main Thread]: D/socketprocess SocketProcessChild::RecvSetOffline aOffline=0

but no further output on random activity.. even after trying queries on about:networking#dnslookuptool. Tracing the process with ktrace shows it just sits here idling doing nothing ? Should security.sandbox.socket.process.level have something else than 0 (the default ?) to enable it further ?

Comment 6

[Landry Breuil (:gaston)]

ok, thanks to lissyx i've figured out that using the socket process is still a long way coming until network.process.enabled and network.http.network_access_on_socket_process.enabled are turned on by default, and to my understanding im seeing the process only because IS_EARLY_BETA_OR_EARLIER is true on 90.0b2. That might explain why the process seems to be idling.

but still, i'll push the code to enable the sandboxing bits to phabricator, at least it'll be there.

Comment 7

[Landry Breuil (:gaston)]

Attachment: Bug 1713999 - Look for unveil/pledge config files for socket process sandboxing on OpenBSD r?gcp

Comment 8

[Landry Breuil (:gaston)]

Attachment: Bug 1713999 - Sandbox the socket process on OpenBSD r?gcp

as done on windows, and as tested with RDD sandboxing in
https://phabricator.services.mozilla.com/D116635, preload the necessary
nss libs before sandboxing. Untested at runtime yet.

Depends on D116640

Comment 9

[Landry Breuil (:gaston)]

Fwiw, after light testing (using MOZ_FORCE_USE_SOCKET_PROCESS=1 MOZ_LOG=socketprocess:5), on OpenBSD it seems filesystem access is only needed for the stat("/etc/resolv.conf") every 30s and the icudata file. As for pledge/syscall subsets, apparently:

stdio
rpath
recvfd
sendfd
inet
dns

is enough for regular use.. i've seen a crash or two with mmap trying to do PROT_EXEC (which is forbidden without prot_exec listed in pledge) but that should be related to me testing without the preloading of the nss libs yet. Doing another build of b3 with my latest patches to confirm.

Comment 10

[Landry Breuil (:gaston)]

there's something fishy to debug somewhere though, because even without MOZ_FORCE_USE_SOCKET_PROCESS=1 (so with just the process running) it seems webrtc is broken, eg trying jitsi doesnt seem to send/receive neither of audio and video. Jitsi is fine with network.process.enabled toggled to 0.

Comment 11

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ac4ed847598c
Look for unveil/pledge config files for socket process sandboxing on OpenBSD r=gcp
https://hg.mozilla.org/integration/autoland/rev/001b61d26864
Sandbox the socket process on OpenBSD r=gcp,necko-reviewers

Comment 12

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/ac4ed847598c
https://hg.mozilla.org/mozilla-central/rev/001b61d26864