28、SELinux策略安全审计：策略规则安全审查，最小权限原则实施，策略漏洞扫描
说到SELinux策略审计，我脑子里第一个蹦出来的词就是「后怕」。
为什么？因为早期做Android系统开发时，我总觉得SELinux就是个麻烦精——动不动就avc denial，搞得我焦头烂额。后来有一次线上事故，某个第三方应用通过一个过于宽松的SELinux规则，直接读到了系统敏感文件。嗯，从那以后，我再也不敢轻视策略审计了。
策略规则安全审查——别让规则变成后门
说白了，策略规则审查就是拿着放大镜检查你写的每一条allow规则。我个人习惯是，每写完一条规则，先问自己三个问题：
- 这条规则真的需要吗？
- 权限范围能不能再缩小？
- 如果这条规则被滥用，后果是什么？
举个例子，我曾经在项目中看到过这样的规则：
allow appdomain system_file:file read;这条规则允许所有应用读取所有系统文件。你想想看，这等于把整个系统的敏感信息都暴露了。正确的做法应该是：
allow com.example.app system_data_file:file read;只允许特定应用读取特定类型的数据文件。
审查要点清单：
- 检查allow规则的源域和目标域是否过于宽泛
- 确认权限集是否最小（比如只需要read，就不要给write）
- 审查neverallow规则是否覆盖了所有关键路径
- 检查type_transition规则是否合理
最小权限原则实施——能不给的，坚决不给
最小权限原则，说白了就是「够用就好」。我在做系统启动优化时，发现很多厂商为了省事，直接给系统服务开了「绿灯」权限。这种做法，我称之为「懒人式安全」。
实施最小权限，我建议分三步走：
- 梳理权限清单：列出每个域实际需要的权限
- 逐条裁剪：去掉所有「可能用不到」的权限
- 回归验证：跑一遍完整功能测试，确认没有遗漏
我曾经遇到过一个案例：某个系统服务需要访问网络，开发人员直接给了netdomain的全部权限。我仔细一查，其实它只需要connect和sendto两个操作。裁剪后，攻击面直接缩小了80%。
我的小技巧：使用sesearch工具可以快速查看某个域的所有权限。命令如下：
sesearch --allow -s my_domain -t all -c all -p all然后逐条分析，哪些是真正需要的。
策略漏洞扫描——自动化检查不能少
手动审查总有遗漏，所以我们需要自动化工具来帮忙。我常用的扫描方法包括：
| 扫描类型 | 工具/方法 | 检查内容 |
|---|---|---|
| 静态分析 | sediff、sechecker | 策略版本差异、已知漏洞模式 |
| 动态分析 | audit2allow + 日志分析 | 运行时权限滥用检测 |
| 合规检查 | 自定义脚本 | 最小权限原则符合度 |
我记得有一次，用sechecker扫描一个第三方ROM的策略文件，发现了17条高危规则。其中有一条允许untrusted_app访问keystore_data——这要是被恶意利用，用户的密钥就全暴露了。
警告：不要完全依赖自动化工具。工具只能发现已知模式，真正的安全漏洞往往藏在「看起来合理」的规则组合中。我建议每季度做一次人工+自动的联合审计。
知识体系结构图
下面这张图，是我自己总结的SELinux策略安全审计的核心逻辑。你看一眼就能明白整个流程：
实战中的避坑指南
我曾经踩过一个坑，分享出来希望大家别重蹈覆辙。
有一次，我在审查一个系统服务的策略文件时，发现了一条allow system_server self:capability sys_admin;。当时觉得「嗯，系统服务嘛，需要管理员权限也正常」。结果后来安全团队扫描发现，这个权限被一个子进程继承了，导致子进程可以修改系统时间——这本来是不允许的。
从那以后，我给自己定了个规矩：任何capability权限，必须单独评估，并且确认不会被继承到子进程。
我的审计清单（简化版）：
- ✅ 所有allow规则都有明确注释说明用途
- ✅ 没有使用通配符
*或all作为权限 - ✅ 每个域只拥有完成功能所需的最小权限
- ✅ 关键路径（如init、zygote）有neverallow保护
- ✅ 第三方应用的策略独立且受限
最后说一句：SELinux策略审计不是一次性工作。随着系统版本迭代、功能增加，策略文件会越来越庞大。我建议每个大版本发布前，都做一次完整的策略安全审计。别等到出了安全问题再后悔——嗯，那滋味我尝过，不好受。
公众号:蓝海资料掘金营，微信deep3321