SIP的核心防御是切断高权限进程对关键系统组件的篡改路径，聚焦运行时代码注入、调试器附加和内核级劫持三类攻击；它通过拒绝ptrace()等系统调用、禁用未签名调试工具与DTrace、阻止未授权kext加载及用户态驱动劫持来实现，但不保护用户空间非系统路径文件。
系统完整性保护（SIP）对恶意代码注入的防御，核心不是“拦截所有注入行为”，而是切断高权限进程对关键系统组件的篡改路径——尤其针对运行时代码注入、调试器附加和内核级劫持这三类常见攻击面。
限制进程调试与动态注入
SIP 会阻止未签名或非 Apple 签名的调试工具（如 lldb、gdb）对受保护进程执行 attach 操作。例如，尝试用 lldb -p PID 调试 /usr/bin/ls 或 /System/Applications/Terminal.app 时，系统直接返回 “Operation not permitted”。这不是权限问题，而是内核在 syscall 层面拒绝了 ptrace() 和 task_for_pid() 类调用。这意味着攻击者无法通过调试器向系统关键进程（如 launchd、syslogd）注入 shellcode 或修改内存页。
- 即使拥有 root 权限，也无法绕过该限制
- Apple 自家调试工具（如 Xcode 的调试器）依赖特殊 entitlements 才能工作
- 第三方逆向分析工具（如 Hopper、Ghidra 的调试插件）默认失效
阻断 DTrace 和 ptrace 类接口滥用
DTrace 是 macOS 内建的动态追踪框架，曾被用于隐蔽加载恶意逻辑（如早期 OSX.Keydnap）。SIP 启用后，普通用户及 root 均无法使用 dtrace -n 'syscall:::entry { ... }' 监控系统级进程，也无法通过 dtrace 加载自定义探针脚本到受保护进程空间。类似地，ptrace(PT_TRACE_ME)、task_for_pid()、mach_port_insert_right() 等底层 API 在涉及 SIP 保护进程时均返回失败。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 攻击者无法用 DTrace 注入任意代码段或重写函数入口
- 基于 ptrace 的内存补丁工具（如 r2pipe + ptrace hook）对 /bin、/sbin 下命令无效
- 部分恶意 loader 依赖这些接口实现无文件驻留，SIP 直接堵死其基础能力
防止内核扩展与用户态驱动劫持
SIP 与内核签名机制协同作用：它不仅禁止未签名 kext 加载，还限制已签名但未获 Apple 明确授权的内核模块修改关键内存区域（如内核文本段、I/O Kit registry）。更重要的是，SIP 阻止用户态进程通过 IOConnectCallMethod 等接口向受保护驱动发送恶意控制命令——这类手法曾被 OSX.Mokes 用来篡改网络过滤驱动行为。
- OS X Yosemite 起，所有 kext 必须经 Apple 公证并启用 SIP 才能加载
- macOS Sequoia 15.2 修复的 CVE-2024-44243 正是绕过 SIP 加载恶意 kext 的漏洞
- 用户态进程无法通过 Mach IPC 向 /System/Library/Extensions 中的驱动发送危险 selector
不覆盖的盲区：用户空间逻辑层仍可被利用
SIP 不保护用户主目录、/Applications（第三方）、/usr/local 或任何非系统路径下的可执行文件。这意味着：
- 恶意脚本仍可在 ~/Downloads 中运行，并 fork 出子进程注入自身（如 Python 的 ctypes 加载 .so）
- 攻击者可通过 osascript 或 launchd plist 启动合法进程，再利用其权限读取敏感数据（TCC 绕过）
- 无文件攻击（如 curl | bash、/dev/fd/ 管道执行）完全不受 SIP 影响
换句话说，SIP 守住的是“系统根”，而非“用户边界”。它让恶意代码难以扎根进操作系统骨架，但无法替代 Gatekeeper、XProtect 和用户行为意识。
