macOS Darwin Sandbox与MACF强制访问控制完全实战指南：黑苹果安全机制深度解读

'''

引言：当黑苹果也需要"权限沙箱"——Sandbox与MACF

许多黑苹果用户在使用过程中会遇到"应用无法访问~/Documents"、"辅助功能授权失败"、"开发者证书无法签名"等权限问题。这些问题看似系统bug，实际上是macOS的安全子系统在起作用——Darwin Sandbox（Seatbelt）与MACF（Mandatory Access Control Framework）共同构成了macOS纵深防御的中坚力量。在macOS Catalina之后，所有非Apple应用都必须经过Sandbox与MACF的"双重审核"才能访问系统资源。理解这两个框架，对解决黑苹果环境下的应用兼容性、SIP配置、Rootless机制等问题至关重要。

MACF强制访问控制框架

MACF与DAC的区别

传统的UNIX权限模型（Discretionary Access Control, DAC）基于"文件所有者可以决定谁能访问"，但这存在根本缺陷：恶意程序一旦以root身份运行，就可以访问所有资源。MACF（Mandatory Access Control Framework）打破了这一假设——它在内核的每个关键操作点（syscall入口、vnode操作、mach message传递）注册了一组"策略钩子"，由可加载的MAC Policy模块决定是否放行。

macOS实现了多种MAC Policy：

• amfi.kext：Apple Mobile File Integrity，处理代码签名与entitlement
• Sandbox.kext：每个进程的内核态沙箱实现
• Quarantine.kext：处理从网络下载的文件的"隔离"标志
• TMSafetyNet.kext：第三方kext加载时的安全检查
• SocketFilter.kext：网络数据包内容过滤（如家长控制）

MACF Label与Cred

每个进程在内核中有两种Label：

• Process Label：存储在proc_t结构的p_label字段，由mac_proc_label_init初始化
• Vnode Label：存储在vnode结构的v_label字段，包含文件来源（下载/本地）、签名状态、隔离标志等

当进程打开文件时，MAC Policy会调用mac_vnode_check_open钩子，传入proc label与vnode label，由各个policy决定是否允许。这种基于label的二元检查比传统的"比较uid/gid"更灵活——Sandbox可以基于"该文件是从Safari下载的"这一语义而非"该文件的uid是501"来决策。

Seatbelt沙箱架构

用户态与内核态分工

Seatbelt是macOS沙箱的"用户面孔"，其实现分为两层：

• 用户态（libsandbox.dylib）：解析.sb格式的profile，转换为内核态可识别的规则集
• 内核态（sandbox.kext）：执行实际的钩子检查，与MAC Policy协作

当一个进程调用sandbox_init()时，libsandbox会读取profile（编译成.sb二进制格式），转换为SBPL（Sandbox Policy Language）规则，然后通过syscall(sandbox_init, ...)将规则集推入内核。内核态sandbox模块将规则编译为高效的位图查找表，每次vnode操作只需一次内存查找即可完成决策。

沙箱Profile结构

一个标准的.sb profile包含三个段：

(version 1)
(deny default)              ; 默认拒绝所有操作
(allow process-exec)        ; 允许执行子进程
(allow sysctl-read)         ; 允许读sysctl
(allow file-read*           ; 允许读文件，但仅限以下路径
  (subpath "/usr")
  (subpath "/Library")
  (subpath "/private/var")
  ...)
(allow network-outbound     ; 允许主动出站网络
  (remote ip "*:*"))

每条规则都基于"操作类型"+"对象过滤"的双维度，例如(allow file-read* (subpath "/Users/me"))表示允许读取/home目录。每个进程启动时都有自己独立的沙箱——Safari的沙箱规则与Finder的完全隔离，即使Safari被攻破也无法读取Finder的"系统完整性保护"信息。

常见系统沙箱场景

App Sandbox（macOS 10.7+）

所有从App Store下载的应用都被强制打上com.apple.security.app-sandbox entitlement。它们的沙箱规则固定为：

• 只能访问~/Library/Containers/<bundle-id>下的文件
• 无法访问其他应用的沙箱目录
• 网络访问受entitlement控制（com.apple.security.network.client）
• 硬件访问（USB、摄像头、麦克风）需要明确entitlement

在黑苹果环境下，App Sandbox可能与SMBIOS的混淆导致SystemPolicyTable加载失败，表现为"应用打开后立即崩溃"。此时需要确保OpenCore配置中的PlatformInfo中的SystemProductName与"AllowedModels"plist对应（Macmini8,1、iMacPro1,1等）。

systemd-launchd Sandbox

从macOS Big Sur开始，launchd管理的系统守护进程（如backupd、cloudd）默认也启用了沙箱。例如backupd的profile仅允许它读取/Volumes下的Time Machine目标卷，禁止访问~/Documents/。这种"系统服务沙箱化"显著降低了恶意dylib通过注入系统服务来提升权限的可能性。

代码签名与AMFI

AMFI在MACF中的位置

Apple Mobile File Integrity（AMFI）是MAC Policy的一个具体实现，但它在黑苹果场景中格外重要。AMFI负责：

• 验证二进制签名：检查所有可执行文件的Code Directory Hash是否与Apple的"信任缓存"匹配
• 强制entitlement：阻止应用使用未声明的entitlement
• 第三方kex签名检查：Big Sur之后，第三方kext必须使用Apple Developer ID签名

在黑苹果中，AMFI的"信任缓存"是由OpenCore的KernelCollection（kc）注入的。如果某个kext（如NVMeFix.kext）未包含在kc中，内核在启动时会拒绝加载，表现为"kext not valid"或"kext signature invalid"。

Rootless与csrutil

macOS从El Capitan开始引入System Integrity Protection（SIP，俗称Rootless）。SIP实际上是AMFI+Sandbox+chroot+扩展属性的一组策略组合：

• /System, /usr：挂载为只读，禁止任何进程修改（包括root）
• com.apple.rootless entitlement：只有Apple签名进程才能"绕过"某些限制
• csrutil disable：在Recovery模式下部分禁用SIP

csrutil可配置多个位标志：

csrutil disable           # 关闭所有SIP
csrutil enable --without kext  # 允许加载未签名kext
csrutil enable --without fs    # 允许修改/System
csrutil enable --without debug # 允许调试系统进程

黑苹果用户在Recovery模式下可以执行csrutil enable --without kext来允许加载第三方kext，但需要注意：每次系统大版本升级后可能需要重新执行。

调试Sandbox与MACF

log stream与predicate

当应用被沙箱拒绝时，可以实时查看日志：

log stream --predicate 'subsystem == "com.apple.sandbox" OR
  (process == "kernel" AND eventMessage CONTAINS "Sandbox")' --info

典型日志会显示：

Sandbox: Sandbox(4783) deny(1) process-exec
  /Applications/Some.app/Contents/MacOS/Some
  (pid 4783)  -> /usr/bin/some-helper

这表示进程4783（Some.app）尝试执行/usr/bin/some-helper被拒绝。解决方案有两种：在profile中添加(allow process-exec (subpath "/usr/bin/some-helper"))，或者从Apple开发者后台为该应用申请com.apple.security.temporary-exception.process-exec.absolute-path entitlement。

sandbox-exec手动测试

macOS提供了sandbox-exec工具用于手动测试沙箱profile：

sandbox-exec -f /tmp/test.sb /bin/ls /Users

如果profile错误，ls命令会被立即拒绝并显示"Sandbox: deny"。这对于开发自定义profile的开发者非常有用。常用的debug技巧：先写一条(profile) allow all允许一切，再逐步缩小范围，最终确定最小权限集合。

黑苹果实战：解决"Sandbox deny"类问题

辅助功能授权失败

一些黑苹果用户会遇到"无法授权辅助功能"的问题。这通常是因为TCC（Transparency Consent and Control）数据库损坏或SIP配置异常：

1. 重启到Recovery模式（macOS）或启动OpenCore Shell
2. 执行csrutil status检查SIP状态
3. 如果SIP开启，尝试在Recovery中执行csrutil enable --without tcc
4. 重启到系统，删除/Library/Application Support/com.apple.TCC/TCC.db
5. 重新授权应用

开发证书签名失败

在黑苹果上使用Xcode签名应用时，可能出现"errSecInternalComponent"错误：

• 检查AMFI是否启用了trust cache
• 在Xcode Preferences > Accounts中重新登录Apple ID
• 删除~/Library/MobileDevice/Provisioning Profiles/下的过期profile
• 执行security delete-identity -Z "Apple Development"清理旧证书

结语

Darwin Sandbox与MACF构成了macOS纵深防御的核心。从用户态的.sb profile到内核态的MAC Policy钩子，从代码签名的AMFI到Rootless的SIP，每一层都在阻止攻击者的横向移动。在黑苹果场景下，理解这些机制不仅能解决"为什么我的应用被拒绝访问"，更能帮助我们正确配置OpenCore的Security选项，在功能与安全之间找到最佳平衡点。下一步建议探索Library Validation、TCC、Hardened Runtime等更细致的安全特性。

'''