Sandboxing on MacOS is too strict

[silene]

On MacOS, sandbox-exec is called with the policy (deny network*), which breaks programs that rely on unix sockets for inter-process communications. Here is an example of the needed permissions:

(allow network-bind (path "/private/var/tmp/rmk-GjXRh"))
(allow network-outbound (path "/private/var/tmp/rmk-GjXRh"))

Adding (allow network* (remote unix)) after (deny network*) in src/state/shellscripts/sandbox_exec.sh seems to be sufficient and it should still forbid applications from actually accessing the network.

# opam config report
# opam-version      2.0.1 
# self-upgrade      no
# system            arch=x86_64 os=macos os-distribution=homebrew os-version=10.12.6
# solver            builtin-mccs+glpk
# install-criteria  -removed,-count[version-lag,request],-count[version-lag,changed],-changed
# upgrade-criteria  -removed,-count[version-lag,solution],-new
# jobs              1
# repositories      2 (http) (default repo at e5263e9b)
# pinned            0
# current-switch    default

[avsm]

Do you need domain sockets for builds, or just for running tests?

[silene]

It is the build system itself that uses unix sockets, so I need it for potentially everything.

[gasche]

For context: the build system is remake, created by @silene, as a mix of make and (dbj's/apenwarr's) redo, and it uses unix sockets for local IPC (on top of multi-process parallelism, I suppose).

@silene: my current understanding is that your proposal is fairly reasonable: I see no strong security need to prevent local sockets during build. Would you send an actual Pull Requet with your proposed sandboxing-script changes?

[rjbou]

Thanks for the report and contribution!

[avsm]

This does look like it'll allow access to any domain sockets even outside of the build root. From a security perspective, it might be nice to refine this to only allow the sockets to be dropped in the opamroot. remake appears to support setting REMAKE_SOCKET to a suitable value.

My general worry is that we're widening the attack surface on osx a lot with this patch. There are an awful lot of services listening on domain sockets throughout the system...

[silene]

This does look like it'll allow access to any domain sockets even outside of the build root.

How so? The file corresponding to the socket still needs to be accessible.

remake appears to support setting REMAKE_SOCKET to a suitable value.

No, the environment variable REMAKE_SOCKET is set by the socket creator to indicate to other programs what the name of the socket is. What controls the location of the socket is TMPDIR. I suppose that opam sets up a private temporary directory rather than the global one. (Or at least it should.)

There are an awful lot of services listening on domain sockets throughout the system...

Sure, but how many of them are in directories accessible from the sandbox? The issue is not that an application inside the sandbox can use unix sockets. The issue is that an application inside the sandbox can use unix sockets that should have been outside the sandbox.

[avsm]

Sure, but how many of them are in directories accessible from the sandbox? The issue is not that an application inside the sandbox can use unix sockets. The issue is that an application inside the sandbox can use unix sockets that should have been outside the sandbox.

I believe the current sandbox offers read-only access to the whole filesystem; it's only file writes that are restricted. So with this change, socket connects anywhere in the filesystem will probably just work. Previously this wasn't the case since the whole class of connectivity was denied.

No, the environment variable REMAKE_SOCKET is set by the socket creator to indicate to other programs what the name of the socket is. What controls the location of the socket is TMPDIR. I suppose that opam sets up a private temporary directory rather than the global one. (Or at least it should.)

Indeed, that's even better -- opam could just let sockets be connected to from the opam sandbox and tmpdir to let remake work without modifications.