解读

面试官抛出该题，表面问“是什么”，实则考察候选人能否把“Linux 安全模块”与“Android 多层沙箱”串成一条线，并落到实际攻防场景。国内厂商对 SELinux 策略拥有二次定制权（如 MIUI、ColorOS 均新增 2k+ 条自有规则），因此回答必须体现“Google 强制 + 厂商扩展”的双轨现实，并给出可量化的调试/审计手段，否则会被认为“只背概念，不会解线上 case”。

知识点

1. SELinux 本质：Linux Security Module（LSM）框架下的强制访问控制（MAC）实现，以“标签-策略-内核强制”三元组取代传统 UID/GID 自主访问控制（DAC）。
2. Android 演进：4.3 引入 permissive，5.0 强制 enforcing，8.0 拆分 system/venodr policy，10+ 新增 apex 分区策略可热更新，12+ 对应用数据目录启用 MLS 多级安全。
3. 标签体系：
   • 主体标签：zygote、system_server、hal_camera_default、priv_app、untrusted_app(29)、untrusted_app_30 等。
   • 客体标签：system_file、vendor_file、app_data_file、proc_net、sysfs_usb_supply……
4. 策略源：
   • Google 基线：system/sepolicy/{public,private,mapping}，CTS 必须通过 neverallow 约束。
   • 芯片/ODM 扩展：device/xxx/sepolicy/vendor，在 vendor_init 阶段被 init 加载到内核。
5. 核心规则格式：allow source target:class permission；neverallow 用于 CTS 合规；type_transition 实现动态类型转换（如 init 创建 socket 时自动打标签）。
6. 国内调试工具：
   • adb shell dmesg | grep avc: 快速定位拒绝。
   • audit2allow -p out/target/product/xxx/obj/ETC/sepolicy_intermediates/policy.conf < avc_log 自动生成补丁。
   • setenforce 0/1：临时切换，用于 CTS 前自检，但出厂必须 1，否则 GMS 授权会被 Google 拒绝。
7. 与沙箱协同：
   • 第一层：Linux UID/GID + 多用户 UID 隔离（app_99999）。
   • 第二层：SELinux MAC，即使 root 提权，若上下文为 u:r:su:s0，仍无法读写 system_data_file。
   • 第三层：Keystore/TEE 加密，保证即便 SELinux 被攻破，密钥仍不可导出。
8. 性能影响：策略膨胀 5k→20k 条，冷启动平均增加 2–3 ms，国内厂商通过 sepolicy-split 和 CIL 编译缓存优化，将 init 加载时间控制在 80 ms 以内。

答案

SELinux（Security-Enhanced Linux）是 Android 5.0 起强制启用的 Linux 安全模块，通过给进程与文件打“标签”，并依据预编译策略决定“谁（主体）能对什么（客体）做何种操作”，实现比传统 UID/GID 更细粒度的强制访问控制（MAC）。
在 Android 安全体系里，它承担三大角色：

1. 纵深防御核心：即使应用利用内核漏洞获得 root，若其 SELinux 上下文不在策略白名单，仍无法访问 /data/system、/vendor/firmware 等关键资源，把“提权”转化为“受限 root”。
2. 供应链合规基线：Google 通过 CTS 的 neverallow 规则（如 neverallow untrusted_app sysfs:file write）强制厂商不得开放高权接口，国内上架 Google Play 或海外运营商入库必须通过该检查。
3. 可审计与热修复：Android 10+ 支持 apex 分区策略独立升级，厂商可通过 OTA 下发 sepolicy 补丁，在不整包升级的情况下修复 avc 拒绝，满足国内监管“漏洞 30 天闭环”要求。
   因此，SELinux 是 Android“最小权限原则”落地的事实标准，把 Linux 的“一切皆文件”转化为“一切皆标签”，并与应用沙箱、Keystore 形成互补，构成覆盖内核层到应用层的立体防护网。

拓展思考

1. 折叠屏/车载多用户场景：车载 IVI 与仪表共享内核，需为 instrument_cluster 与 infotainment_app 设置 MLS 范围，防止高安全级进程读取低安全级数据，如何编写 type_transition 并保证 neverallow 不冲突？
2. 国内“漏洞双清单”制度：若 SELinux 策略补丁涉及 system_ext 分区，OTA 升级后需重新计算 dm-verity hash，如何在不触发 eio 的情况下完成“差分 + 签名 + 回滚保护”？
3. 性能敏感场景：游戏手机 144 Hz 高刷，surfaceflinger 频繁访问 /dev/ashmem，avc 审计造成额外 0.8 ms 帧抖动，怎样通过 ioctl 白名单 + dontaudit 规则把开销降到 0.2 ms 以内且不影响 CTS？