SELinux 基础：强制访问控制与 avc 日志

上一章看了 AppOps。这一章进入第三层，回答：SELinux 是什么，安全上下文怎么配， avc: denied 日志怎么读、怎么修？

enforcing 下拒绝由策略决定

常见误解	正确理解
SELinux 是“另一个权限系统”	它是内核级强制访问控制，管的是进程与资源之间的操作
关闭 SELinux 就能解决所有问题	permissive 只是不执行只记录，风险和依赖不能忽略
avc denied 都是应用问题	系统服务、init 脚本、HAL 同样会被策略拒绝

核心结论

1. 主体、客体、策略三元组：source context → target context → 允许的操作。
2. enforcing 模式执行拒绝，permissive 模式只记录，生产必须 enforcing。
3. avc: denied 日志包含主体、客体、操作与策略线索。
4. 修复方向：补策略、调整 domain、或改实现，而不是关 SELinux。
5. 排障顺序：看日志 → 定位主体/客体 → 判断是否合法 → 补策略并回归。

访问控制主链

逐步解释：

1. 主体：发起操作的进程，带 domain context。
2. 客体：目标文件/服务，带 type context。
3. 策略：规则决定该组合是否允许。
4. 结果：允许放行，拒绝产生 avc 日志。

avc 日志怎么读

典型拒绝日志：

avc: denied { read } for pid=1234 comm="app" name="secret"
  scontext=u:r:untrusted_app:s0 tcontext=u:object_r:secret_file:s0 tclass=file

关键字段：denied { 操作 }、scontext（主体）、tcontext（客体）、tclass（资源 类型）。定位“谁要做什么被拦”，再决定补策略还是改实现。

源码证据

阅读目标：确认策略来源与审计日志。

正文指针：system/sepolicy/ 的策略定义；内核 SELinux LSM 的审计输出。

# system/sepolicy/ 示例（伪代码，行号以 r75 为准）
allow untrusted_app app_data_file:file rw_file_perms;

这段代码证明： 策略以 allow 规则表达“主体对客体类型的操作”；avc denied 就是规则 不匹配时的内核记录。

验证与排障

环境：开发设备或模拟器；读取 avc 日志需要 root。

adb shell getenforce
adb shell su 0 dmesg | grep -E "avc: denied" | tail -20
adb logcat -v threadtime | grep avc
adb shell su 0 cat /sys/fs/selinux/policy

先确认 enforcing/permissive，再看 avc 日志定位主体与客体。修复后回归验证： 重复触发操作，确认拒绝消失且系统行为正常。

常见误区

1. “SELinux 就是权限”：是内核级 MAC，维度不同。
2. “关掉 SELinux 就能修”：permissive 只记录，风险仍在。
3. “avc denied 都是应用问题”：系统组件同样会被拦。
4. “补策略不用回归”：策略放宽可能引入风险，必须回归。

延伸问题

1. enforcing 与 permissive 在什么场景切换？
2. SELinux 与权限/AppOps 的检查顺序是什么？
3. 如何用 audit2allow 辅助编写策略？
4. 自定义系统服务需要哪些 SELinux 规则？

源码入口

文件	关键位置	作用
system/sepolicy/	策略规则	MAC 策略
内核 SELinux LSM	审计输出	avc 日志
getenforce	命令行	模式检查
/sys/fs/selinux/	运行状态	策略与审计

公共路径：system/sepolicy/ 与内核 security/selinux/。行号以 r75 检索为准。

系统应用能力的签名与白名单条件，见 签名与特权权限。