Gatekeeper是深度集成于macOS内核与文件系统层的安全执行守门人，启动前通过代码签名与com.apple.quarantine属性双重校验、本地公证票据解析、以及与SIP和launchd的协同裁决，完成原子性验证。
gatekeeper 不是简单弹个窗就完事的“提醒工具”，它是深度集成在 macos 内核与文件系统层的安全执行守门人。它的验证不是运行时临时判断，而是在应用启动前、由内核级组件协同完成的一套原子性检查流程。
签名与隔离属性：启动前的双重标记校验
当你双击一个 .app，系统首先读取其 Mach-O 可执行文件的代码签名（Code Signature），并检查是否附带 com.apple.quarantine 扩展属性——这个属性由下载进程（如 Safari、Chrome）自动写入，标识该文件来自网络。Gatekeeper 将二者绑定验证：未签名 + 有隔离属性 → 直接拦截；已签名但无公证票据 + 有隔离属性 → 触发“无法验证开发者”警告。
- 签名有效性由 trustd 守护进程实时校验证书链，需回溯至苹果根证书且未吊销
- 隔离属性不可手动删除（
xattr -d com.apple.quarantine需先解除 SIP 保护或使用 root 权限） - 即使你用
chmod +x赋予脚本执行权，只要它带 quarantine 属性且无有效签名，仍被拒
公证票据嵌入：运行前的云端信任快照
自 macOS 10.14.5 起，所有非 App Store 的 Developer ID 应用必须嵌入苹果签发的公证票据（notarization ticket）。该票据不是远程联网验证，而是以二进制形式固化在应用包的 _CodeSignature/CodeResources 或独立 plist 中。Gatekeeper 启动时直接解析票据中的哈希值，比对当前应用内容是否被篡改，并确认票据签发时间未过期、对应开发者 ID 未被撤销。
- 票据失效 ≠ 签名失效，两者独立校验；常见于开发者证书过期后重新打包但未重公证
- 离线状态下仍可验证票据（因票据本地存在），但若系统时间严重偏差，可能误判为过期
- 公证票据不等于杀毒扫描报告，它只证明“提交时未检出已知威胁”，不担保后续行为安全
与内核机制联动：SIP 与 launchd 的协同裁决
Gatekeeper 的决策结果并非由用户态进程单独执行。它通过 Mach IPC 向 launchd（系统初始化进程）传递放行信号，而 launchd 在 fork 子进程前，会进一步调用 kernel code signing enforcement 模块做最终确认。若应用启用了 Hardened Runtime 或需要特定 entitlements，还会触发 SIP 对 /System、/usr、/bin 等受保护路径的写入拦截——这意味着 Gatekeeper 放行 ≠ 应用能正常运行，只是获得了“启动资格”。
- 例如：某工具通过 Gatekeeper，但试图 patch 系统 dylib，会被 SIP 直接 kill 并记录到
log show --predicate 'eventMessage contains "SIP"' - Apple Silicon Mac 上，Gatekeeper 还会校验 architectural compatibility（如是否含 Rosetta 2 兼容层），失败则报 “Killed: 9” 而非弹窗
- 所有验证过程均在用户空间进程加载前完成，无法绕过，除非禁用 SIP（不推荐）或降级系统
策略执行点：不只是“第一次打开”
很多人以为 Gatekeeper 只在首次运行检查，其实它在每次启动时都重新验证——特别是当应用被修改（如插件注入、资源替换）、系统更新后证书信任链变更、或用户手动清除公证票据缓存时。macOS 会将验证结果缓存在 /var/db/gk 下的 SQLite 数据库中，但该缓存仅用于加速，不替代实时校验。
- 终端命令
spctl --assess --type execute /path/to/app可模拟 Gatekeeper 实时评估，返回accepted或具体拒绝原因 - 系统日志中搜索
gatekeeper或quarantine可定位拦截细节，例如：log show --predicate 'subsystem == "com.apple.gatekeeper"' - 管理员可通过
spctl --master-enable/disable切换全局策略，但该开关仅影响来源检查逻辑，不影响签名与票据校验本身
