SIP 不验证签名，但仅 Apple 签名进程可绕过其路径限制；Gatekeeper、AMFI、TCC 等依赖签名验证身份，二者分工明确、协同构成完整信任链。
SIP 本身不验证二进制文件是否签名，但它与签名机制深度协同——签名不是 SIP 的前提，却是绕过 SIP 限制的唯一合法通道。
SIP 是内核级强制访问控制，它不关心你有没有证书，只按路径和进程属性做硬性拦截。但 Apple 设计了一个关键例外：只有经过 Apple 签名的进程（如 launchd、mds、Dock），才能在受保护路径下执行写入、注入或加载操作。这意味着：
- 一个未签名的程序，哪怕以 root 运行，也不能
cp覆盖/usr/bin/python3； - 一个已签名且带特定 entitlements（如
com.apple.security.cs.allow-jit）的 Apple 官方工具，可以在/System/Library/Extensions加载 kext（需额外开启 kext-dev-mode）； - 第三方开发者无法获得 Apple 私钥签名权限，因此其二进制天然被 SIP 拒绝修改系统路径——这不是缺陷，是设计闭环。
真正依赖签名的，是 SIP 之外的其他层：
- Gatekeeper 在首次运行时检查开发者 ID 或公证票据，决定是否放行启动；
- AMFI（Apple Mobile File Integrity）在加载时校验代码签名有效性，失败则直接终止进程（报
Killed: 9）； - Library Validation 要求 dylib 必须与主程序共用签名，否则
dlopen失败； - TCC 权限弹窗背后也依赖签名一致性，篡改包结构会导致授权状态失效。
所以，当你看到 Operation not permitted，问题不在签名缺失，而在 SIP 拦截了路径；但如果你改完二进制再想运行，没重签名就会卡在 AMFI 验证——两道关卡，一前一后，互不替代，却环环相扣。
常见误区澄清：
- ✅ SIP 启用时，
codesign --force --deep --sign "Developer ID Application: XXX" app.app只解决 Gatekeeper 和 AMFI 问题，不能让你写进/System； - ✅ 把已签名 App 改装后放进
~/Applications，SIP 完全不管，但 Gatekeeper 可能因签名失效再次拦截； - ❌ 用
sudo+--no-sandbox运行脚本，只是避开某些沙盒检查，不绕过 SIP 对路径的内核级封锁； - ❌ 临时禁用 SIP（
csrutil disable）后安装，若二进制本身无有效签名，后续仍可能被 AMFI 拒绝加载。
本质上，签名不是给 SIP 看的，而是让整个信任链——从 Gatekeeper 到 AMFI 再到 TCC——能确认“这个东西确实是它声称的身份”。SIP 负责守住门，签名负责证明你是谁。门不会因为你有身份证就自动打开，但没身份证，连敲门都不让。
