Does anyone have a tip to keep macOS from phoning home when you run unsigned binaries?
I almost locked up my entire computer this week, presumably because of this... here's the story for that:
I had setup unbound listening on 127.0.0.1:53 as the only DNS resolver for all network interfaces, so that I hijack several responses that I might want to (e.g. adnet sinkholes) and forward the rest to Google/Cloudflare over TLS.
When I rebooted the Mac, the entire computer was so fucked that I panicked cause I thought my SSD was failing. Turns out unbound failed to start so all DNS was down. I suspect it to be the "phoning home" because when I opened the Terminal, running `ps aux | grep unbound` took like 5 seconds to return anything (as did everything else that tried to run), and that behavior has been reported by other users as Gatekeeper's Phone Home checks being at fault.
So that's why I was wondering if anyone has found out how to keep macOS from doing this (preferably without disabling all of SIP), cause that'd be one hell of a tip...
First: binaries that ship with the system are not included in this because they're platform binaries. Tools like ps or grep won't be included.
Second: once the binary has been checked for malware it won't be checked again.
Third: if the connection fails immediately the malware check is skipped immediately. So if you are offline or otherwise force the relevant server DNS names to be rejected immediately it shouldn't wait for any timeout.
Fourth: anything you build with the Xcode UI is automatically excluded since you are using the user interface and explicitly asking to run "unknown" code.
Fifth: Anything listed as a Developer Tool in Privacy will have its child processes excluded from GateKeeper scanning. This command will make the category show up and put Terminal in it:
"sudo spctl developer-mode enable-terminal"
Once it shows up there go to Privacy and check the box to enable Terminal.
If you run CI or automation you can do the same by putting your Jenkins or other binary in the list, causing all subprocesses to be excluded.
I was partly aware of many of these, and like I said I'm not 100% sure if this really is the culprit. Your comment is a solid reference on this topic though (better than most of what's on SO), but here's a few comments regarding my specific incident...
On your first point: Was aware of this, and this is the part that is most puzzling about the whole incident to me. I just checked my $PATH and I am indeed running the system binaries, so not sure how to explain this one.
On your second point: Was aware of this too, but I assume a lot of the slowness comes from JITted programs, for which there will be phoning-home for any new executable memory page (AFAIK), and the policy decision caching semantics for things that are not on disk are not as clear to me.
On your third point: While this is true for the connection that gets established to Apple's servers, I think this might have had to do with DNS being UDP based by default (AFAIK), so there is no explicit refusal, and it hangs on a timeout because of that, even though DNS can be done over TCP as well. Haven't investigated this though, just a hunch...
On your fourth and fifth points: I don't use XCode, but my terminal (Kitty) was already on the Developer Tool list when this happened, which makes the situation with ps and grep even more mysterious to me...
#3: Sorry I meant use hosts to skip DNS resolution and just map them to 127.0.0.1 directly (assuming you aren't running an https server locally). The names are ocsp.apple.com and api.apple-cloudkit.com.
Clearly something was trying to resolve hostnames but it may not be related to GateKeeper malware scanning. TBH a tarpit DNS server is not a case I have personally thought about before but is interesting to consider!
On your last point, would that include the jenkins-agent.jar file? If so, is there a way to dynamically add it? We download our agent jars on boot which I'm pretty sure would replace the preview permission, so it'd be great to add it after download.
The Developer Tool permission excludes a process's child processes from scanning, not the process itself, so you'd have to add whatever launches the Jenkins agent, not the agent JAR itself. That's probably either ssh or launchd; adding a blanket exception to either of those is probably undesirable (if macOS will let you do it at all).
Usually you have something configured as a LaunchDaemon or LaunchAgent. Put that process in the list so once it goes out and downloads the jar then executes it you're good.
I don't recommend putting java in the list. That would grant that power to all Java apps (or at least all that start through that copy of Java).
I guess the questions I'd have regarding this that I'd need to validate would be:
- Does this setting persist across reboots?
- Does it stop phoning-home altogether, or will it still phone-home, but always authorize regardless of answer?
- Is there a more granular way to disable just phoning-home, rather than nuking all of Gatekeeper? (Some of its things like disallowing access to personal files by default are still nice to have)
Adhoc code signatures just ensure the code pages are the same as they were when the binary was written without the system needing to jump through other hoops to fake up a different identity because the binary doesn't have one.
I almost locked up my entire computer this week, presumably because of this... here's the story for that:
I had setup unbound listening on 127.0.0.1:53 as the only DNS resolver for all network interfaces, so that I hijack several responses that I might want to (e.g. adnet sinkholes) and forward the rest to Google/Cloudflare over TLS.
When I rebooted the Mac, the entire computer was so fucked that I panicked cause I thought my SSD was failing. Turns out unbound failed to start so all DNS was down. I suspect it to be the "phoning home" because when I opened the Terminal, running `ps aux | grep unbound` took like 5 seconds to return anything (as did everything else that tried to run), and that behavior has been reported by other users as Gatekeeper's Phone Home checks being at fault.
So that's why I was wondering if anyone has found out how to keep macOS from doing this (preferably without disabling all of SIP), cause that'd be one hell of a tip...