深入Android系统安全：从DAC到MAC，SEPolicy如何重塑应用沙盒与进程隔离
深入Android系统安全：从DAC到MAC，SEPolicy如何重塑应用沙盒与进程隔离
在移动操作系统领域，Android的安全架构演进堪称一场静默的革命。当开发者们沉浸在应用功能的实现时，系统底层正经历着从"自由放任"到"精细管控"的范式转变。这场变革的核心武器——SEPolicy，不仅重新定义了Android的权限边界，更从根本上改变了系统组件的交互方式。
1. 传统Linux安全模型的局限性
早期的Android系统沿用了Linux传统的自主访问控制（DAC）模型，这种机制存在三个致命缺陷：
权限继承问题
- 进程拥有与执行用户完全相同的权限
- root进程可不受限制地访问系统所有资源
- 一旦应用获得root权限，整个系统门户洞开
边界模糊问题
# 经典提权漏洞示例 adb shell chmod 777 /data/system/packages.xml这种操作在DAC体系下完全合法，却可能破坏系统完整性
横向渗透风险
通过Linux组权限机制（如AID_SDCARD_RW），不同应用可相互访问数据文件，导致隐私数据泄露
2. SELinux的架构革新
2000年美国国家安全局（NSA）推出的安全增强型Linux（SELinux），为Android带来了强制访问控制（MAC）机制。这种模型的核心转变体现在：
| 特性 | DAC模型 | MAC模型 |
|---|---|---|
| 权限决定因素 | 用户身份 | 安全策略 |
| 修改权限 | 用户可自主调整 | 仅策略管理员可修改 |
| 默认行为 | 允许所有访问 | 拒绝所有未明确允许的访问 |
| 审计重点 | 成功访问记录 | 权限拒绝记录 |
**安全上下文（Security Context）**成为MAC体系的基石，其格式为：
user:role:type:sensitivity在Android中简化为：
u:r:type:s03. Android SELinux实现机制
3.1 策略语言核心要素
类型强制（Type Enforcement）
# 允许system_server访问hal服务 allow system_server hal_fingerprint_default:binder call;属性继承机制
type hal_foo_default, domain; typeattribute hal_foo_default halserverdomain;多级安全检查流程：
- 传统DAC权限检查
- SELinux MAC策略检查
- 特殊能力（capabilities）检查
3.2 关键策略文件
文件结构示例：
/system/sepolicy/ ├── private/ # 核心策略 ├── public/ # 公开接口 ├── vendor/ # 厂商扩展 └── prebuilts/api/ # 版本兼容典型配置文件：
file_contexts：文件安全标签service_contexts：系统服务绑定权限seapp_contexts：应用进程标签策略
4. 实战：进程隔离机制解析
以系统服务访问HAL为例，完整权限检查流程：
- Binder调用初始化
// frameworks/native/libs/binder/IPCThreadState.cpp status_t IPCThreadState::transact(int32_t handle,...) { // SELinux检查点 if (selinuxEnforce) { err = selinuxCheckCall(handle, code); } }- 安全上下文对比
调用方：u:r:system_server:s0 被调用方：u:r:hal_fingerprint_default:s0- 策略规则匹配
# 必须存在对应allow规则 allow system_server hal_fingerprint_default:binder call;- 审计日志记录
avc: denied { call } for scontext=u:r:untrusted_app:s0 tcontext=u:r:system_server:s0 tclass=binder5. 策略调试与优化
高效调试方法论：
- 收集完整avc日志
adb logcat | grep "avc:" > avc_denials.txt- 使用audit2allow生成建议
audit2allow -i avc_denials.txt # 输出示例： allow untrusted_app system_server:binder call;- 策略合规性检查
m selinux_policy && adb push out/target/product/.../etc/selinux/ /etc/selinux/常见陷阱解决方案：
问题场景：HAL服务无法注册到hwservicemanager
根本原因：
# 缺少hwservice_manager_type属性 neverallow hal_foo_default hwservice_manager:hwservice_manager { add };修正方案：
type hal_foo_hwservice, hwservice_manager_type; allow hal_foo_default hal_foo_hwservice:hwservice_manager { add };6. 现代Android的纵深防御
随着Treble架构的引入，SEPolicy在以下领域持续进化：
分区隔离强化：
- 系统/vendor/product分区间默认拒绝访问
- 通过
attributes定义分区属性边界
HIDL/AIDL接口管控：
# 限制HIDL接口访问 neverallow { domain -hal_client_domain } hal_foo_hwservice:hwservice_manager find;最小权限实践：
# 精细化控制示例 allow system_server { hal_foo_default hal_bar_default }:binder call; neverallow * hal_foo_default:file { open read };在Android 13中，SELinux策略已超过50万行，管控着：
- 超过200个系统服务
- 300+ HAL接口
- 数千个文件资源
这种精细化的权限管理，使得即使获得root权限的攻击者，也难以突破SEPolicy构建的隔离屏障。正如Linux内核安全维护者Casey Schaufler所言："SELinux将Android从'默认允许'的安全荒漠，变成了'默认拒绝'的坚固堡垒。"