macOS Gatekeeper Debugging Tips

From Free Pascal wiki
Revision as of 06:09, 9 May 2020 by Trev (talk | contribs) (Gatekeeper tips for debugging)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Notarising your application is necessary to pass Gatekeeper, but it is not sufficient. Gatekeeper has its own array of checks.

To determine why Gatekeeper is not executing your application is quite tricky. In most cases where Gatekeeper denies execution, there is some evidence in the system log. It is not always easy to spot. Some key terms to look for are:

  • gk, for Gatekeeper.
  • xprotect, an internal name for a Gatekeeper subsystem.
  • syspolicyd, see its man page.
  • cmd, for Mach-O load command oddities.

Gatekeeper caches its assessments, and if you ‘hit’ that cache then you may not see anything interesting in the log (because the code that logs the interesting entries is not run). Try testing in a VM:

  • Start with a fresh VM that’s never seen your application.
  • Set up the VM exactly how you need it set up (install the application, prime sudo, and so on).
  • Take a snapshot.
  • Run the program.
  • Collect the logs.

If you need to run it again, restore from the snapshot first.

With regards to collecting logs, you can use the sysdiagnose command line utility (see its man page) for that but it is generally faster to run log collect (see the man page for log) and then export the log to analyse offline on your real Mac.

In many cases, critical log entries have private info redacted. You can disable that system-wide using a configuration profile. See the discussion of Enable-Private-Data property in SystemLogging. IMPORTANT This is on the VM. You really don’t want to do it on any Mac you care about.