SIP 不依赖实时签名校验，而是通过内核强制访问控制锁定路径；但绕过 SIP 的唯一合法方式是持有 Apple 专用签名，如 softwareupdated 必须带 Apple Software Update Signing Authority 签名才能写入 /System 等受保护区域。
macOS 的系统完整性保护（SIP）本身不依赖传统“签名校验”来运行，它不是靠检查某个文件是否被 Apple 签名才决定是否保护——而是由内核在启动早期就加载固定策略，直接锁定特定路径与行为。但 SIP 与签名机制紧密协同：Apple 签名是**绕过 SIP 限制的唯一合法通行证**，只有持有有效 Apple 签名、且被授权修改系统区域的进程（如软件更新、安装器），才能写入 /System、/usr/bin 等受保护位置。
为什么说 SIP 不做“签名校验”，但又离不开签名？
SIP 的核心是强制访问控制（MAC），它通过扩展属性 com.apple.rootless 和配置文件 /System/Library/Security/rootless.conf 标记哪些路径/进程受保护。每次访问时，内核只判断“当前操作是否在白名单策略内”，不现场验签。但 Apple 把“能触发白名单豁免”的权限，严格绑定到签名上：
- 系统更新工具（softwareupdated）、安装器（Installer.app）等内置进程，必须带有 Apple 的专用签名（如 Apple Software Update Signing Authority），否则即使调用系统 API 也会被拒绝
- 第三方开发者无法获得这类签名，所以你用 sudo 编译一个程序去改 /usr/bin/vim，哪怕代码完全合法，也会被拦截
- 这就是为什么禁用 SIP 后，未签名工具就能写入——不是因为 SIP “验签失败”，而是 SIP 这道门被拆了，不再执行任何策略
如何验证 SIP 相关的签名依赖是否生效？
你可以分两层检查，确认签名与 SIP 的配合状态：
- 查 SIP 当前开关状态：终端运行 csrutil status，显示 enabled 才代表策略正在运行
- 查关键系统进程是否带有效 Apple 签名：比如检查安装器签名，运行 codesign -dv --verbose=4 /Applications/Install\ macOS\ Sequoia.app，确认输出含 Authority=Apple Software Update Signing Authority 或类似 Apple 内部签名标识
- 查受保护路径是否真被锁住：尝试 sudo touch /usr/local/test（允许） vs sudo touch /usr/bin/test（应报错 Operation not permitted），可反向验证 SIP 是否实际起效
常见误判：把 Gatekeeper 或公证警告当成 SIP 问题
用户常遇到“已损坏”弹窗或“无法验证开发者”，这其实是 Gatekeeper + 代码签名 + 公证 链路的问题，和 SIP 无关：
- Gatekeeper 拦截的是首次运行的外来 App，检查的是 com.apple.quarantine 属性和签名/公证状态
- SIP 拦截的是对系统路径的写操作或对 Dock/Finder 等进程的调试注入，不干预 App 启动本身
- 一个未公证的 App 可以正常启动（只要没碰 /usr/bin），但若它试图用 launchctl 注入 kext，SIP 会立刻阻止——两者触发条件完全不同
Apple Silicon 机型的额外签名关联
在 M1/M2/M3 Mac 上，SIP 与 authenticated root 机制联动。系统宗卷（System Volume）默认启用签名验证，即使 SIP 已 disable，root 卷仍是只读，除非同时运行：
- csrutil authenticated-root disable
- 该命令本质是让系统跳过对 root 卷内容的签名校验（即验证 System Volume 是否由 Apple 签名并完整）
- 没有这一步，仅 csrutil disable 无法真正释放 /System 下的写权限
