1. 课程导入

在Android安全体系中,SELinux(Security-Enhanced Linux)并不是一个可选的“附加功能”,而是从Android 4.3开始引入、Android 5.0起强制启用的核心安全机制。它位于Linux内核层,与传统的DAC(自主访问控制)共同构成Android的访问控制体系。理解SELinux的定位与价值,是后续策略开发与调试的起点。

核心定位:SELinux在Android中承担“强制访问控制(MAC)”角色,即使进程以root身份运行,也必须遵守SELinux策略。它把“谁可以访问什么”从用户自主决定,转变为由系统策略统一裁定。

一、为什么Android需要SELinux

传统Linux的DAC模型以UID/GID和文件权限位为基础,存在两个根本问题:一是root权限过大,一旦进程被提权,攻击者可获得几乎全部资源;二是权限粒度粗,难以限制同一用户下的进程间越权访问。Android作为移动终端,应用数量多、来源复杂、攻击面广,仅靠DAC无法满足安全需求。

SELinux通过“主体(Subject)—客体(Object)—策略(Policy)”模型,为每个进程和资源打上安全上下文标签,并由内核在每次访问时进行强制检查。其价值可归纳为三点:

  • 最小权限原则:每个域(domain)只被授予完成其功能所需的最小权限,越权访问默认被拒绝。
  • 攻击面收敛:即使某个进程被攻破,攻击者也被限制在该进程的域内,难以横向扩散。
  • 合规与可审计:策略文件可版本化、可审查,拒绝日志可追踪,满足企业级安全合规要求。

二、整体知识框架

本课程围绕“策略开发—编译集成—运行调试—问题复盘”的闭环展开。下图展示了Android SELinux的核心组成与数据流关系:策略源文件经编译生成二进制策略,加载到内核后由AVC(Access Vector Cache)执行访问判定,拒绝事件写入dmesg与audit日志,最终反馈给开发者进行策略修正。

Android SELinux 策略开发与调试知识框架 策略源文件 .te 类型强制规则 .fc 文件上下文 .if 接口定义 file_contexts 编译与集成 checkpolicy / sepolicy m4 宏展开 policy.conf 生成 sepolicy 二进制 内核加载与执行 securityfs 加载 AVC 缓存判定 allow / deny 决策 enforcing / permissive 调试与反馈 dmesg | grep avc audit2allow 生成规则 sesearch 查询策略 setenforce 0/1 切换模式 策略修正反馈 核心闭环:策略编写 → 编译集成 → 内核执行 → 日志调试 → 策略修正

三、开发调试工具链概览

Android SELinux开发调试依赖一套相对固定的工具链。下表列出最常用的工具及其用途,建议在环境搭建阶段逐一确认可用性。

工具/命令 所在位置 主要用途
checkpolicy host 工具链 将 policy.conf 编译为二进制策略
sepolicy system/sepolicy Android策略源目录与构建入口
audit2allow host 工具链 根据avc拒绝日志生成allow规则
sesearch host 工具链 查询已有策略中的allow/neverallow规则
setenforce 设备 shell 切换 enforcing/permissive 模式
getenforce 设备 shell 查看当前SELinux运行模式
ls -Z / ps -Z 设备 shell 查看文件与进程的安全上下文

四、典型场景:一个拒绝日志的完整处理

假设新增一个系统服务进程 my_service,启动后无法读取配置文件,dmesg中出现如下拒绝日志:

avc: denied { read } for pid=1234 comm="my_service"
  name="config.xml" dev="sda1" ino=4567
  scontext=u:r:my_service:s0
  tcontext=u:object_r:system_file:s0
  tclass=file permissive=0

处理流程为:先用 audit2allow 生成候选规则,再人工审查是否符合最小权限原则,最后将规则写入对应的 .te 文件并重新编译刷机验证。

adb shell dmesg | grep avc > avc.log
audit2allow -i avc.log
# 输出示例:
# allow my_service system_file:file read;
提示:audit2allow 生成的是“能消除拒绝”的规则,不等于“应该授予”的规则。必须结合业务语义判断,避免过度授权。

五、常见误区与复盘

  • 误区一:把SELinux当成DAC的替代品。两者是叠加关系,SELinux在DAC检查之后生效,DAC不通过时根本不会进入SELinux判定。
  • 误区二:遇到拒绝就关SELinux。将设备设为permissive或disabled会掩盖真实问题,且无法通过CTS/GMS认证。
  • 误区三:直接复制audit2allow输出。未经审查的规则可能引入neverallow冲突,导致编译失败或安全漏洞。
  • 误区四:忽略neverallow检查。neverallow是策略的“红线”,任何allow规则都不得与其冲突,编译阶段会强制校验。
重要:Android 5.0及以上版本要求SELinux处于enforcing模式,否则设备无法通过兼容性测试。开发阶段可临时permissive,但发布版本必须enforcing。

六、学习目标

完成本章学习后,您应当能够:

  1. 说明SELinux在Android安全体系中的位置及其与DAC的关系。
  2. 描述策略从源文件到内核执行的完整数据流。
  3. 列举常用开发调试工具及其适用场景。
  4. 识别SELinux策略开发中的常见误区,并建立“最小权限+人工审查”的正确意识。