SIP通过内核级实时拦截保护系统库路径，主要包括/usr（不含/usr/local）、/bin、/sbin、/System/Library/Frameworks、/private/etc等，其机制依赖rootless标记与XNU内核访问决策，而非传统权限控制。
macOS 系统完整性保护（SIP）对系统库路径的保护，不是靠“禁止写入”这种表面权限控制，而是通过内核级强制访问控制，在每次文件访问时实时拦截非法操作。
受保护的系统库路径有哪些
SIP 明确锁定以下路径中的系统库及相关二进制文件：
-
/usr：包含核心动态链接库（如
/usr/lib/libSystem.dylib）、运行时加载器（/usr/lib/dyld）及标准工具（/usr/bin/clang等），但/usr/local不在保护范围内 -
/bin 和 /sbin：存放基础 shell 工具（
bash、ls、ifconfig），这些可执行文件被绑定到系统签名，修改即失效 -
/System/Library/Frameworks 和 /System/Library/PrivateFrameworks：Apple 官方框架所在位置，所有 dylib 和 bundle 均带
com.apple.rootless扩展属性 -
/private/etc（即
/etc的真实路径）：配置文件如hosts、sudoers受保护，普通用户或 root 都无法直接覆盖
保护机制如何实时生效
关键不在文件权限，而在内核访问决策点：
- 每次 open()、mmap()、dlopen() 或 execve() 操作触发时，XNU 内核会检查目标路径是否标记为 rootless；若命中保护列表，立即拒绝，返回
EPERM - 系统通过扩展属性
com.apple.rootless标记受保护对象，该属性不可被用户清除（即使 root 权限下xattr -d也会失败） - 策略来源是只读内存中加载的
rootless.conf，该文件由苹果硬编码进系统镜像，不响应用户修改，更新时会被重置
为什么 /usr/local 不受影响
这不是疏漏，而是设计上的明确划分：
-
/usr/local被 SIP 显式排除在保护路径之外，用作第三方软件的标准安装位（如 Homebrew、MacPorts） - 该路径下的库（如
/usr/local/lib/libcurl.dylib）可自由替换、升级，且能被用户程序正常dlopen()加载 - 系统默认将
/usr/local/lib加入动态链接器搜索路径（dyld的LC_RPATH或环境变量DYLD_LIBRARY_PATH），但不会将其用于系统自身启动流程
绕过限制的合法路径
开发者和管理员无需禁用 SIP 即可完成多数系统集成任务：
- 把自定义库放在
/usr/local/lib或/opt/homebrew/lib，通过 rpath 或 linker flags 显式引用 - 使用 macOS 提供的 系统扩展（System Extensions） 替代传统 kext，运行于用户态，无需签名豁免即可与系统交互
- 对需要写入系统配置的场景（如网络过滤），应调用 Network Extension 或 Endpoint Security 框架 API，而非直接修改
/private/etc/pf.conf
