Chapter 34: Kernel Isolation, Access Control, Attack Surface

手机平台把相机、麦克风、定位、文件、网络和账号数据包装成受控能力，最终仍要依赖内核维持最底层的隔离。应用可以被沙箱限制，系统服务可以执行权限检查，安装包可以经过签名校验；这些控制一旦落到进程、地址空间、文件描述符、设备节点、IPC 通道和驱动入口，内核就成为所有上层安全策略的共同支点。

本章要建立的判断能力是：看到一个 App 可见行为，能够追踪它穿过 Framework、系统服务、IPC、内核入口和驱动边界时，哪些位置属于正常能力调用，哪些位置扩大了攻击面，哪些位置一旦被攻破会改变整个平台的安全结论。贯穿材料使用一个普通应用请求“拍照并上传头像”的路径：应用先申请相机权限，再通过 framework API 打开相机会话，系统服务检查权限和前后台状态，HAL 与驱动管理 ISP、sensor、buffer 和 DMA，网络栈随后承载上传流量。这个行为覆盖本章的核心对象：进程隔离、内存保护、设备访问控制、SELinux / sandbox / entitlement、syscall、IPC、driver surface 和 kernel exploit 风险链。

Kernel boundary 的工作定义是：从用户态进入内核态、从普通对象访问特权对象、从平台公开能力触达设备控制面的所有边界集合。它解决的问题是把“不可信应用代码”和“高权限系统资源”隔开。它的适用边界也很清楚：内核负责进程、内存、文件、socket、设备、调度和低层权限检查；用户授权弹窗、商店审核、服务层业务策略和 UI 提示属于上层平台控制，但这些控制的底层执行仍会落到内核对象和系统服务边界。

Android 和 Apple 在实现细节上不同，安全问题却相同：应用请求能力时，平台要确认调用者身份、限制可访问对象、缩小入口面、记录可观测失败，并在硬件能力和用户数据之间保持最小权限。Android Application Sandbox 文档说明 Android 使用 Linux UID 建立 kernel-level Application Sandbox，并在后续版本中叠加 SELinux、seccomp-bpf、per-app SELinux sandbox 和受限文件系统视图；Apple Platform Security 的运行期安全文档则公开说明 iOS、iPadOS 和 visionOS 使用 sandbox、declared entitlements、ASLR 和 Execute Never 等运行期控制。正文会把这些材料整理成路径判断，而不会把任何一方写成品牌评价。

34.1 Kernel Boundary 作为最高权限边界

Kernel boundary 首先是权限高度的边界。应用进程运行在用户态，拥有自己的虚拟地址空间、文件描述符表、线程、信号处理和语言运行时。内核运行在特权态，持有页表、调度队列、设备对象、文件系统、网络栈、IPC 基础设施和驱动入口。应用调用相机时看到的是 framework API，实际路径会在某个时刻穿过 Binder、Mach message、socket、ioctl、shared memory 或系统调用进入更高权限的对象世界。

在“拍照并上传头像”的贯穿行为中，应用自己只应该持有相机会话的抽象句柄和图片数据的授权视图。相机设备、ISP pipeline、DMA buffer、sensor power state、镜头控制和 raw frame 流由系统服务、HAL、daemon、driver 与内核共同管理。这个分工的安全意义是：应用崩溃或恶意输入应停留在应用进程、会话状态或服务层拒绝中；它不应直接改写内核内存、绕过相机占用策略、读取其他应用 buffer、访问未经授权的设备节点。

Kernel compromise 指攻击者获得足以改变内核控制流、内核数据结构或内核安全判断的能力。这个状态会改变所有上层结论。进程隔离依赖页表和调度上下文，文件访问依赖 VFS 权限和 credential，设备访问依赖设备节点、驱动检查和 IOMMU 配置，平台信任依赖启动链、代码签名、系统分区完整性和运行期策略。内核被控制后，攻击者可能伪造调用者身份、修改权限判断结果、读取其他进程内存、截获键盘或触摸输入、控制摄像头路径、隐藏持久化组件。

这里需要区分两类失败。第一类是服务层拒绝，例如应用无相机权限，Camera service 返回权限错误，用户看到授权弹窗或调用失败。第二类是边界失守，例如驱动处理某个畸形 ioctl 参数时破坏内核内存，普通应用的输入穿过设备控制面后影响特权态。前者是平台预期内的访问控制结果，后者会把一个普通 App 行为提升成平台级安全事件。

Android 的 Application Sandbox 文档把 UID、进程级隔离和 Linux 标准机制放在核心位置，并说明 sandbox 位于内核中，覆盖 native code、framework、runtime 和应用。这个判断说明 Android 安全模型的底座不是某一种开发语言，而是内核对进程和权限对象的执行。Apple 的公开文档则强调第三方应用 sandbox、只通过系统提供服务访问外部信息、系统分区只读和 entitlement 控制特权操作。两边的共同点是：上层 API 给应用一个能力表面，内核和系统服务共同持有真实资源边界。

判断 Kernel boundary 时，可以按四步走。先找调用者身份：UID、PID、SELinux domain、audit token、entitlement、签名主体或进程凭据。再找目标对象：文件、socket、device node、Mach port、Binder handle、shared buffer 或 driver object。接着找执行点：framework 预检查、系统服务权限检查、IPC 驱动传递身份、内核访问控制、驱动参数校验。最后看失败表现：错误码、权限弹窗、日志拒绝、服务崩溃、kernel panic、设备断开或系统重启。这个顺序可以把“安全模型”落到可追踪对象上。

34.2 Process Isolation、Memory Protection 与地址空间隔离

Process isolation 的工作定义是：内核把每个进程放入独立执行上下文，使一个进程默认只能访问自己的虚拟地址空间、打开的文件描述符和被授权的 IPC 对象。Memory protection 是这个隔离在内存层的执行方式，核心对象包括页表权限、user/kernel split、copy-in/copy-out、只读映射、可执行权限和地址随机化。地址空间隔离给应用沙箱提供了最低层支撑。

拍照路径中至少有三类进程参与。应用进程持有 UI、业务代码和部分图片处理逻辑；系统服务进程持有相机会话、权限判断、资源仲裁和 buffer 队列；HAL、daemon 或驱动上下文负责把请求翻译成硬件控制。隔离的目标是让应用进程只能拿到经过授权的结果，无法直接读取 system_server、camera service、其他应用或内核的内存。共享 buffer 可以提升性能，但共享必须有显式所有权、生命周期和访问权限。

页权限提供最基本的硬边界。用户态页面和内核态页面有不同访问权限，代码页和数据页有不同执行属性，mapped file、匿名内存、共享内存和 device memory 也有不同约束。应用把一块 buffer 交给系统服务处理时，内核需要在用户态地址和内核态对象之间复制或映射数据。这里的关键风险是指针、长度、偏移、引用计数和并发状态。任何一个字段被错误信任，都可能把用户态输入变成内核态越界访问。

ASLR（Address Space Layout Randomization，地址空间布局随机化）的作用是降低内存破坏漏洞的可利用性。它把可执行代码、库、堆、栈和相关映射放到较难预测的位置，使攻击者难以稳定跳转到目标地址。Apple 公开文档明确把 ASLR 列入 iOS、iPadOS 和 visionOS 运行期安全机制；Android 的应用隔离也与 Linux 地址空间、进程凭据、SELinux 和 seccomp-bpf 等机制共同工作。ASLR 本身提供的是利用难度提升，边界仍依赖权限检查、内存安全、控制流保护和最小入口面共同成立。

Sandbox 是地址空间隔离之上的平台语义。Android 给每个应用分配 UID，默认让应用运行在自己的进程中，并由内核使用 Linux 用户、组、文件权限等机制建立隔离；Android 5.0 起 SELinux enforcing 覆盖所有进程，并在 Android 8.0、9、10 继续强化 syscall、per-app MAC 和文件系统视图。Apple 公开文档说明第三方应用被 sandbox，每个应用有唯一 home directory，访问自身之外的信息要通过系统提供的服务。两边都把“进程可运行”与“进程可访问什么”分开处理。

在移动 OS 中，内存保护还要处理性能路径。相机、图形、视频和机器学习都依赖大 buffer，频繁复制会增加延迟和功耗。系统会使用共享内存、dma-buf、IOSurface、memory descriptor 或类似机制把数据在多个组件之间传递。安全判断的重点变成：谁创建 buffer，谁持有写权限，谁能导出 handle，哪个服务负责关闭，硬件 DMA 能访问哪些物理页，buffer 生命周期结束后是否还存在可复用引用。高性能路径扩大了对象数量，也提高了所有权管理要求。

可复用判断顺序如下。先确认应用能否直接触达目标内存；再确认共享对象是否通过系统服务或 kernel object 授权；接着确认读写执行权限是否分离；最后确认失败时对象如何回收。看到 crash 日志时，应用崩溃通常指向应用地址空间、JNI、图像解码或业务逻辑；系统服务崩溃指向 service 输入校验、状态机或 IPC；kernel panic 指向驱动、内核子系统、DMA、锁或内核内存破坏。不同崩溃位置对应不同安全边界。

34.3 Device Access Control 与驱动攻击面

Device access control 的工作定义是：系统把真实硬件控制权留在内核、驱动、HAL、daemon 或系统服务中，只向应用开放经过权限、策略和生命周期约束的能力接口。它解决的问题是硬件设备通常带有高权限数据面和控制面，例如相机 sensor、麦克风、基带、Wi-Fi、触摸、NFC、USB、GPU、display 和 secure element。应用直接访问这些设备会绕过并发仲裁、隐私提示、功耗策略和输入校验。

驱动攻击面来自驱动必须接受外部输入。设备节点的 open、read、write、mmap、poll、ioctl，firmware parser，sysfs/procfs/debugfs 节点，netlink/socket，DMA buffer 导入导出，硬件事件上报，外设协议包，都可能把低权限或不可信输入送入高权限代码。移动设备还增加了 vendor driver 和 firmware 边界：SoC 厂商、OEM、外设供应商、基带、相机模组、触控芯片和电源管理芯片都可能引入设备特有协议。

拍照路径是典型例子。应用调用 Camera framework，不应直接打开 camera sensor 的字符设备或向 ISP 驱动提交任意寄存器配置。系统服务负责权限、前后台、相机占用和用户隐私指示器；HAL 负责把平台请求翻译成 vendor 能力；驱动负责队列、buffer、DMA、中断和硬件状态。攻击面收缩的关键是让应用输入停留在“会话参数”和“图像数据”层面，并由服务和 HAL 把参数收敛成有限的驱动命令。

ioctl 是驱动攻击面中最需要警惕的入口之一。它通常承载设备特有控制命令，参数结构体包含指针、长度、枚举、offset、handle、flag 和版本字段。驱动收到 ioctl 后要把用户态参数复制到内核态，验证大小、对齐、范围、对象所有权、调用者权限和当前设备状态，再触发硬件操作。任何跳过校验的字段都会把“普通应用传入的字节”推近内核控制逻辑。

Firmware parser 也是高风险入口。相机、Wi-Fi、蓝牙、基带、触控和安全芯片都可能加载 firmware 或解析外设提供的数据包。解析器要处理版本、长度、校验、签名、状态机和异常恢复。攻击面判断不能停在“文件来自系统分区”这一点，还要看 firmware 更新链、签名校验、外设输入可信度和 parser 运行位置。运行在内核态或高权限 daemon 中的 parser，缺陷影响范围更大。

DMA 把问题推到内存边界。硬件通过 DMA 直接访问内存，系统需要 IOMMU 或等价机制限制设备可访问的物理页。相机 frame、GPU texture、视频码流和网络包都可能经 DMA 进入内存。如果设备能写入未授权页，进程隔离会被硬件路径绕过；如果 buffer 所有权在 HAL、驱动和应用之间混乱，应用可能读取旧数据或影响其他会话。安全设计要把 DMA window、buffer pin、map/unmap、cache coherency 和引用计数纳入同一个生命周期。

Android 的 vendor driver 攻击面还受到设备碎片化影响。AOSP 定义 framework、HAL、Treble、SELinux policy 和测试边界，具体设备仍包含大量厂商代码。Android SELinux 文档提到 Android 8.0 的 Treble 把较低层 vendor code 与 Android system framework 分离，并让 policy 支撑 vendor 与 platform 之间的兼容。这个设计的安全收益在于把系统升级边界和厂商适配边界显式化；它仍要求每个 vendor driver、HAL service 和设备节点保持最小权限。

Apple 平台公开材料能确认两点：iOS、iPadOS 和 visionOS 对第三方应用使用 sandbox 和 entitlement；macOS 的 DriverKit让一类驱动运行在用户空间以提升安全与稳定性，并减少 kernel panic 和 attack surface。对于 iPhone 和 iPad 的内部驱动实现，公开资料不足以把每个私有 driver path 展开到源码级。正文采用的安全判断是公开可证的分层原则：把设备控制从应用侧收回平台侧，把特权代码从大内核攻击面中拆出，把硬件访问绑定到签名、entitlement、daemon 和系统服务边界。

34.4 SELinux、Sandbox、Entitlement 与 Kernel Enforcement 的关系

SELinux、sandbox、entitlement 和 kernel enforcement 解决同一类问题：调用者能否访问目标对象。差别在于它们的表达层级不同。SELinux 是 Linux Security Module 语境下的 mandatory access control，使用 domain、type、class 和 policy 决定主体能否操作对象。Sandbox 是平台对应用可访问资源集合的封装。Entitlement 是 Apple 平台中由签名绑定到进程的能力声明。Kernel enforcement 是这些声明最终落到内核对象、系统服务边界或 IPC 入口时的执行。

Android 中，UID sandbox 提供基础隔离，SELinux 提供强制访问控制。Android SELinux 文档说明 Android 使用 SELinux 对所有进程执行 MAC，即使进程具有 root/superuser 权限也受限制；SELinux 遵循 default denial，未显式允许的动作会被拒绝。这个结论对移动 OS 非常关键：Android 的 root 权限在 SELinux enforcing 环境中仍受 policy 约束，高权限进程也需要在特定 domain 中获得目标对象访问规则。

Android 权限路径可以分成两层。第一层是 framework 和系统服务的语义权限，例如相机、麦克风、定位、通知、后台任务和存储访问。第二层是内核和 SELinux 的对象权限，例如某个进程能否打开设备节点、访问 socket、读取目录、调用 binder service、写入系统文件。应用请求相机时，Camera service 会检查 runtime permission、AppOps、前后台状态和资源占用；底层进程还要受到 SELinux domain、device node label、binder policy 和文件权限限制。

Apple 的 entitlement 路径强调签名与能力绑定。Apple 运行期安全文档说明 entitlements 是签入应用的 key-value pair，用于控制第三方应用访问用户信息、iCloud、扩展性等能力；系统应用和 daemon 也大量使用 entitlement 执行特权操作。这个设计把“谁签了这个程序”和“程序可使用哪些平台能力”合在一起。应用运行后，sandbox 负责默认收缩资源视图，entitlement 负责打开少量受控能力。

Kernel enforcement 并不总是出现在内核代码的同一位置。Android 的 SELinux 决策由内核 LSM hook 执行，Binder 驱动会承载调用者身份传递，系统服务会做业务权限检查。Apple 的公开层面可以确认 sandbox、entitlement、ASLR、XN、系统服务和代码签名共同构成运行期控制；具体到私有 daemon 与 XNU hook 的每条路径，公开资料不足以逐行验证。写作时应把公开事实和合理推断分开：公开事实支持平台使用这些控制，路径推断用于解释为什么同一个能力请求会经过多个执行点。

用同一组维度比较 Android 与 Apple，可以得到稳定判断。入口 API：Android 常见是 framework manager 与 Binder，Apple 常见是 public framework 与 XPC / Mach 基础设施。调用者身份：Android 使用 UID、PID、SELinux context、package identity 和 permission state，Apple 使用 code signing identity、sandbox profile、entitlement、audit token 和进程身份。执行边界：Android 明显落到 system_server/native service、Binder driver、SELinux 和 kernel driver；Apple 公开可见的是 framework、daemon、XPC/Mach、sandbox/entitlement 和 XNU 资源边界。失败表现：Android 常见 permission denied、SecurityException、SELinux denial、service error；Apple 常见 API 返回失败、系统弹窗、TCC / privacy 拒绝、entitlement 不匹配或 sandbox violation。

在拍照路径中，这些控制的关系可以这样理解：runtime permission 表达用户是否授权；AppOps 或等价策略表达当前状态是否允许；系统服务表达谁持有相机资源；SELinux 或 sandbox 表达进程能否访问底层对象；entitlement 表达签名主体是否拥有某些特权能力；kernel enforcement 表达对象级访问是否真正放行。安全设计依赖这些层次叠加，单一层通过不代表整个能力调用成功。

34.5 System Call Surface、Driver Surface 与 IPC Surface

Attack surface 的工作定义是：不可信或低权限输入能够触达的代码、对象和状态集合。移动 OS 中最常见的入口面是 syscall surface、driver surface 和 IPC surface。Syscall surface 连接应用与通用内核服务，driver surface 连接应用或服务与设备控制，IPC surface 连接应用与系统服务、daemon、HAL service 或其他受控进程。三者共同决定普通 App 行为能把输入送到多深的系统层。

syscall surface 包括文件、进程、内存、网络、时间、信号、线程、调度和命名空间等通用内核入口。Android 8.0 起所有应用使用 seccomp-bpf filter 限制允许的 syscall 集合，Application Sandbox 文档把它描述为 strengthening the app/kernel boundary。这个机制的安全意义是直接减少应用可触达内核代码路径。应用仍可通过 framework 和系统服务获得能力，但原始 syscall 入口被收缩。

driver surface 比 syscall surface 更贴近硬件状态。相机、GPU、显示、音频、传感器、Wi-Fi、基带和 USB 都有设备特有接口。驱动接收的参数通常和硬件队列、buffer、寄存器、firmware 和 DMA 相关。由于驱动代码常与厂商实现、性能优化和硬件协议绑定，它的输入校验和权限隔离质量直接影响平台安全。一个高质量平台会把大多数应用请求挡在 framework 和 service 层，只让少量受控服务触达驱动控制面。

IPC surface 是移动平台最频繁的入口面。Android 的应用与系统能力大量通过 Binder 进入 system_server、native service 或 HAL service。Apple 平台公开文档强调系统提供服务、sandbox 和 entitlement；在架构上，public framework 通过 XPC、Mach port 或 daemon 接入系统服务是常见模式。IPC surface 的风险来自参数解析、对象引用、handle 权限、调用者身份传递、异步回调、死亡通知、并发重入和服务状态机。

下面的图把三类入口面放回“拍照并上传头像”的路径中。它只表达攻击面分类，不表示某个平台的完整私有实现。

图中有两条路径需要分开看。第一条是平台期望路径：App 通过 Framework 和 IPC 进入系统服务，系统服务执行权限和状态检查，再由 HAL 或 daemon 访问驱动。第二条是通用 syscall 路径：App 仍可使用文件、socket、mmap、线程等内核服务。安全设计要让敏感硬件控制走第一条路径，并把第二条路径的可用 syscall、文件可见性、设备节点权限和网络能力限制在沙箱范围内。

分析一个入口面时，先问输入来自谁。来自应用、网页内容、网络包、蓝牙包、USB 外设、图片文件、媒体码流、通知负载和传感器数据的输入可信度不同。再问输入到哪里结束。输入停在应用解析器，影响范围较小；输入进入系统服务，可能影响多个应用；输入进入驱动或内核，风险升高；输入进入 firmware 或基带，还要考虑独立处理器、更新链和主系统之间的隔离。最后问失败如何呈现：返回错误、拒绝授权、服务重启、设备失效、panic、重启或静默数据泄露，对应不同严重度。

IPC surface 的一个常见误判是把服务调用看成普通函数调用。普通函数调用的调用者和被调用者共享地址空间，错误主要在同一进程中传播；IPC 调用跨进程，必须携带调用者身份、序列化参数、对象 handle 和返回状态。系统服务不能信任客户端传来的“包名”“进程状态”“buffer 归属”这类声明，必须以内核传来的调用者身份、PackageManager / launch services 查询结果、权限数据库和系统状态为准。这个原则直接支撑 capability mediation。

34.6 Kernel Exploit 对手机平台安全模型的破坏路径

Kernel exploit 的风险来自权限层级跳变。普通应用漏洞通常影响应用数据和当前进程；系统服务漏洞可能影响某项系统能力或多个客户端；内核漏洞可能改变所有进程和硬件资源的访问规则。手机平台把大量敏感资源放到系统服务和内核边界之后，Kernel exploit 一旦成功，就可能把权限弹窗、沙箱、文件保护、设备访问和持久化防护串成连续破坏路径。

贯穿行为中的风险链可以这样展开：攻击者把畸形输入放进图像文件、相机参数、IPC parcel、shared buffer 或驱动命令；输入经过 framework 或服务层后触达高权限组件；组件解析或状态转换出现内存破坏、越界、UAF、整数溢出或竞争条件；攻击者获得任意读写、控制流劫持或 credential 修改能力；随后读取其他应用数据、访问敏感硬件、关闭审计、提升进程权限或植入持久化组件。真实攻击通常还需要绕过 ASLR、XN、PAC、CFI、KASLR、SELinux、sandbox、签名和完整性检查等防护。

这个风险链可以用阶段图表示。图中的每个阶段都对应一类平台防护和一个可观测失败点。

正常防护希望风险在 Reject 或 Crash 处终止。权限拒绝说明策略执行点起效；参数拒绝说明输入校验起效；服务崩溃虽然影响可用性，但仍可能被进程边界限制；kernel panic 是严重稳定性问题，也可能阻断进一步利用。最危险的是攻击者越过崩溃阶段，获得稳定 primitive，并把 primitive 转换成权限与身份改写。

提权是最直接的破坏。内核维护进程 credential、capability、UID、GID、SELinux context、sandbox 相关状态和打开对象。攻击者如果能修改这些对象，就可能让普通应用表现成系统进程，或让受限 domain 获得设备节点、文件、socket、Binder service 的访问能力。Android 中，SELinux enforcing 会增加提权后的约束，但内核级写能力可能同时修改策略相关数据或绕过检查。Apple 中，公开文档可确认 entitlement 与 sandbox 参与运行期控制；内核级控制能力可能影响它们的执行结果或绕过由系统服务维护的判断。

沙箱逃逸是第二条路径。应用沙箱假设应用无法读取其他应用目录、无法访问未授权系统资源、无法直接控制敏感设备。Kernel exploit 可以通过读取其他进程地址空间、打开受限文件、伪造 IPC 调用者、导出未经授权的 port / handle、修改文件权限或改变 mount / vnode 状态来突破这些假设。用户可见层面可能表现为相册、定位、麦克风、键盘输入、账号 token 或本地数据库被异常访问。

敏感硬件访问是第三条路径。相机、麦克风、定位、蓝牙、NFC 和基带都带有隐私和安全含义。正常路径要求用户授权、前后台策略、系统指示器和服务仲裁共同成立。Kernel exploit 可能尝试绕过设备节点权限、伪造系统服务状态、干预 buffer 流、拦截传感器数据或修改指示器相关状态。平台设计会把硬件控制拆分到系统服务、driver、firmware、安全处理器和用户可见 UI 中，以减少单点失守后的影响。

持久化是第四条路径。Verified Boot、签名分区、只读系统分区、Data Protection / 文件加密、rollback protection、系统完整性和安全更新共同限制持久化空间。内核级控制可以在运行期隐藏进程、修改内存对象或影响文件系统视图，但要跨重启保留通常还需要攻破启动链、可写分区策略、签名检查、配置 profile、启动项或恢复环境。这里的判断边界是：运行期内核控制和跨重启持久化属于不同阶段，后者需要额外信任链破坏。

排查安全事件时，不要把所有异常都归因于 kernel exploit。相机打开失败可能来自权限拒绝、资源占用、温控降级、HAL 错误或应用生命周期；上传失败可能来自网络权限、后台限制、TLS、DNS、蜂窝策略或服务端拒绝。Kernel exploit 的证据通常更底层：异常权限状态、跨应用数据访问、SELinux denial 与实际结果矛盾、驱动崩溃、kernel panic、设备节点异常访问、系统完整性状态改变、重启后可疑组件保留。证据链需要从可见现象回到边界执行点。

34.7 最小权限、攻击面收缩与平台安全设计

最小权限的核心判断是：每个组件只持有完成当前职责所需的对象、权限、入口和生命周期。攻击面收缩则把低权限输入能触达的代码路径减少到必要集合。平台安全设计要把两者落实到 App、Framework、系统服务、IPC、驱动、内核和硬件每一层，而非停留在“安全策略”口号上。

对 App 层，最小权限表现为按需申请用户权限，使用系统提供的 picker、content provider、photo library selector、document picker、share sheet 和 background API。应用需要头像时，可以请求用户选取图片或在授权后打开相机；它不需要枚举整个文件系统、持久持有相机设备、读取麦克风、访问联系人或常驻后台。应用侧的输入解析也要分层：图片解码、EXIF、压缩、上传和缓存都应限制大小、格式和生命周期。

对 Framework 和系统服务层，最小权限表现为集中执行身份识别、权限检查、状态判断和资源仲裁。相机服务要确认调用者、权限、前台状态、隐私指示器、并发占用、设备能力和温控状态；网络服务要确认网络权限、VPN / proxy、metered network、后台传输和数据节省策略；文件服务要确认 URI 授权、scoped storage、Data Protection class 或 app group。服务层是 capability mediation 的主体，负责把复杂策略转换成稳定结果。

对 IPC 层，攻击面收缩表现为稳定接口、窄参数、强类型、调用者身份由内核传递、handle 生命周期清晰、回调权限可撤销。一个服务方法应表达明确能力，例如“创建相机会话”“提交 capture request”“关闭 session”，而不应暴露任意设备命令转发。参数结构要有版本、长度、枚举范围和默认拒绝行为。回调要考虑客户端死亡、重入、超时和队列积压。

对驱动和内核层，最小权限表现为设备节点权限收敛、SELinux / sandbox policy 收敛、seccomp-bpf 收敛、debug 接口收敛、firmware 签名校验、IOMMU 限制 DMA、buffer 所有权清晰、用户态 driver 或 daemon 拆分高风险解析器。Android 官方文档中 SELinux default denial、per-app MAC、seccomp-bpf 和 Treble vendor boundary 都可以放入这个模型。Apple 公开文档中 sandbox、entitlement、ASLR、XN、系统服务访问外部信息、DriverKit 用户态驱动趋势，也可以放入同一模型。

对平台更新层，攻击面收缩还依赖签名、完整性和快速修复。安全更新要覆盖内核、驱动、firmware、HAL、系统服务和 framework。Verified Boot 与系统完整性保证启动镜像可信；rollback protection 限制降级；商店审核和 notarization 限制分发入口；运行期审计记录拒绝、崩溃和策略异常。平台安全不是单次授权动作，而是安装、启动、运行、更新、撤销和恢复共同构成的闭环。

下面给出一个可迁移的检查顺序，用来分析任意移动能力调用：先确定能力属于硬件、数据、网络、传感器、账号还是后台执行；再确定 App 可见 API 和系统服务所有者；接着列出调用者身份、目标对象、策略检查点和底层执行点；然后区分 syscall、IPC、driver 三类入口面；最后写出失败表现和最小权限改进点。这个顺序可以用于相机、定位、麦克风、蓝牙、通知、文件、网络和后台任务。

回到本章主问题，Kernel isolation 不是孤立的内核主题。它决定应用沙箱是否可信，access control 决定能力调用是否按身份和策略执行，attack surface 决定普通输入能接近多少高权限代码。Android 和 Apple 的平台差异改变的是实现路径、公开材料和生态控制方式；共同系统问题始终是把不可信 App 行为限制在可授权、可调度、可审计、可恢复的边界内。

最小自检任务

一个头像应用在用户点击“拍照上传”后执行以下行为：申请相机权限，打开相机会话，拿到一张 JPEG，压缩后上传到服务器。请写出这条路径中的 App 意图、Framework 入口、系统服务、策略检查、内核 / 驱动边界、三类攻击面和失败表现，并说明哪个环节一旦被 kernel exploit 攻破会改变整个平台安全结论。

答案要点

App 意图是获取一张用户授权的头像图片并上传；它的正常入口应是相机或图片选择相关 framework API。Framework 入口把调用转换成系统服务请求，并通过 IPC 传递调用者身份、会话参数和回调对象。系统服务负责检查 runtime permission、前后台状态、相机占用、隐私指示器、温控或功耗状态，并把通过后的请求交给 HAL、daemon 或 driver path。

内核 / 驱动边界出现在 IPC 驱动、文件和 socket syscall、shared buffer、设备节点、ioctl、DMA buffer 和网络栈中。syscall surface 主要承载文件、内存、线程、socket 和网络上传；IPC surface 承载 App 到系统服务、HAL service 或 daemon 的方法调用；driver surface 承载相机、ISP、buffer、DMA、中断和硬件状态控制。正常失败表现包括权限拒绝、相机被占用、后台状态拒绝、服务错误、上传网络错误、HAL 超时或设备热降级。

Kernel exploit 改变平台结论的原因是它可能修改进程身份、权限判断、页表、文件访问、设备节点访问、IPC 调用者身份或驱动状态。普通应用 bug 通常被应用进程边界限制；系统服务 bug 可能影响某项能力；内核级控制可能读取其他应用数据、绕过 sandbox、访问相机或麦克风、隐藏持久化组件并影响系统完整性。正确判断顺序是从 App 可见行为回到调用者身份、目标对象、执行点和失败表现，而后再评估攻击面是否触达内核或驱动。

本章知识点总结

• 最高边界：Kernel boundary 持有进程、内存、文件、设备、网络和底层权限对象，是移动平台安全策略的共同支点。
• 贯穿路径：拍照上传路径会穿过 Framework、IPC、系统服务、策略检查、HAL / daemon、驱动、内核和硬件。
• 内核失守：Kernel compromise 可能改变调用者身份、权限结果、进程隔离、设备访问和平台信任状态。
• 进程隔离：Process isolation 依赖独立地址空间、页表权限、文件描述符、IPC 对象和内核调度上下文。
• 内存保护：ASLR、XN、权限位、copy-in/copy-out、共享 buffer 生命周期和 DMA 限制共同降低内存路径风险。
• 设备控制：Device access control 把真实硬件控制权留在系统服务、HAL、daemon、driver 和内核中。
• 驱动入口：设备节点、ioctl、firmware parser、DMA、vendor driver 和外设输入构成驱动攻击面。
• Android 控制：Android 使用 UID sandbox、SELinux、seccomp-bpf、per-app MAC、权限服务和 vendor boundary 叠加限制能力访问。
• Apple 控制：Apple 公开材料显示 sandbox、entitlement、ASLR、XN、系统服务和 DriverKit 等机制共同收缩运行期风险。
• 执行层次：权限弹窗表达用户授权，系统服务表达能力所有权，SELinux / sandbox / entitlement 表达对象访问边界。
• 入口分类：syscall surface、IPC surface 和 driver surface 分别对应通用内核服务、系统服务通信和硬件控制路径。
• 攻击链条：内核攻击通常从不可信输入进入入口面，经解析或状态缺陷获得 primitive，再转向权限改写、资源访问和持久化。
• 最小权限：每个组件只持有当前职责所需的对象、权限、入口和生命周期，可以降低单点缺陷的影响范围。
• 判断顺序：分析移动能力调用时，先找调用者身份和目标对象，再找策略检查点、底层执行点、入口面和失败表现。