鸿蒙OS到底有没有 SELinux

在 HarmonyOS NEXT 的系统目录（如 /system/etc）下，依然保留了熟悉的 SELinux 配置文件，系统的「开放源代码许可」中也包含了 libselinux。这常常让人产生疑问：既然底座已切换为自研微内核，为什么还会存在典型的 Linux 安全模块痕迹？

解答这个问题的关键在于区分"策略配置"与"执行引擎"。配置文件的存在，是建立系统生态时为了二进制兼容所作的务实让步；但在内核层面，负责执行这套策略的早已不再是 Linux 的底层机制。这篇文章将梳理其中的技术演进逻辑。

HarmonyOS NEXT 的 /system/etc/selinux 目录真实存在，libselinux 也在许可列表里。但这套配置背后执行权限校验的不是 Linux 内核的 LSM 钩子，而是微内核基于 IPC 消息拦截的新引擎。原因很直接：NEXT 为了让底层 Native 组件和驱动低成本迁移，模拟出了 Linux 风格的 /proc 和 /sys 虚拟接口；既然给老代码留了这些入口，就必须用最成熟的 MAC 策略框架来给它们上锁——SELinux 的策略语言和工具链无需重造。但配置文件以下的一切，早已不是那套 Linux 机制。

为什么 /proc 和 /sys 要存在

NEXT 的内核换成了自研微内核。但在建立整个生态的过程中，如果要求开发者把海量的 Native 服务（C/C++ 编写的底层进程）全部推倒重来、重新学习一套完全陌生的接口，迁移代价和学习曲线将是不可接受的。业界过去习惯的行为模式通常包括：

• 通过 cat /proc/meminfo 查系统内存
• 通过 /sys/class/power_supply/*/capacity 查电量
• 通过 /proc/net/ 读取网络状态

微内核本身不产生这些路径。真正的内核信息全部封装在 IPC 服务里。但为了让这些组件无需大规模改写就能运行，NEXT 提供了一个虚拟文件系统代理：客户端看到的是熟悉的路径，背后对接的是微内核的服务接口。

这是工程上最务实的选择，和 Fuchsia 提供 POSIX 兼容层的逻辑一样。2024 年发表在 OSDI'24 的论文《Microkernel Goes General》给出了一个侧面数据：手机场景下需要正确运行的驱动超过 700 个，而路由器只需不到 20 个；华为估算如果从头重写这批驱动需要超过 5,000 人年。这直接解释了为什么 HM 要提供 Linux 驱动容器（Driver Container）来复用现有驱动，而不是推倒重来。

代价是：引入了这些接口，就必须对它们做精细的权限隔离，否则任意进程都能通过 /proc 读到全系统状态。

为什么 SELinux 配置在这里

在 Linux 生态里，对 /proc 和 /sys 施加强制访问控制（MAC，Mandatory Access Control）最成熟的方案就是 SELinux。它的策略描述语言（.te 文件）、编译工具链（checkpolicy）和审计工具已经经过几十年打磨，华为的安全工程师也都熟悉这套流程。

从工程成本看，重新发明一套描述语言来定义"谁能访问谁"是纯粹的浪费。所以 NEXT 做了一个清醒的选择：

复用 SELinux 的策略描述标准（配置文件、语法、工具链），但替换掉执行引擎。

这就是为什么你能在 /system/etc/selinux 找到：

• file_contexts
  ：定义文件系统路径的安全标签
• service_contexts
  ：定义系统服务（Ability）的标签
• 编译后的二进制策略文件（policy）

以及为什么 libselinux 会出现在开放源代码许可里——华为用了这个库来加载和解析策略文件，而不是让 Linux 内核来执行它。

真正的区别：引擎换了

Linux 的做法：LSM 钩子

传统 Linux 中，SELinux 作为 LSM（Linux Security Module） 插件运行。内核源码的关键路径里——vfs_read、vfs_write、socket_create——硬编码了大量 security_* 函数钩子。进程调用 open() 时，当前调用栈直接触发 SELinux 检查，在内核态同步查表，失败则拒绝系统调用。

这套机制深度耦合在宏内核里：安全模块和文件系统、网络栈、进程管理共享同一个地址空间。

NEXT 的做法：IPC 拦截

微内核的设计哲学是极致精简——内核只做最不可能出错的那几件事（IPC、调度、内存管理），把其余的逻辑推到用户态。

权限校验也是这样处理的：

1. 进程 A 发起 Linux 系统调用（如 open()）
2. HM 的 ABI-compliant shim（ABI 兼容垫片）在内核空间拦截，将 syscall 重定向为一条 IPC 消息
3. IPC 路径上的访问控制服务决定是否允许该请求
4. 结果返回给调用方

其中一个关键细节：根据 OSDI'24 论文，ABI shim 实际上运行在 IC0（与核心内核同处内核空间，无地址空间切换开销），这是 HM 为了性能做的务实折衷——兼容层本身是受信任的基础设施，不需要和其他用户态服务一样被完全隔离。

同样值得关注的是 IPC 频率的量级。论文实测数据：智能手机场景下 IPC 平均频率约 41,000 次/秒，是路由器场景（600 次/秒）的约 70 倍。这解释了为什么把所有安全决策都放到用户态 Server 处理在手机上是一个严重的性能挑战，也是 HM 在架构上花了大量精力优化 IPC 路径的根本原因。

架构对比图

左侧：Linux 的 SELinux 拦截点在内核系统调用路径上，决策与执行发生在同一个内核地址空间。右侧：NEXT 的拦截点在 IPC 消息分发路径上，策略决策由用户态 Security Server 完成，配置文件格式相同，执行引擎完全不同。

访问控制的两个层次，别混淆

如果只看 SELinux，会低估 NEXT 安全架构的真实设计意图。这里需要区分两个经常被混淆的概念。

Address Token：内核对象的高性能共管机制

OSDI'24 论文里华为提出了 Address Token（地址令牌）这个概念，但它针对的不是应用层权限——而是内核内部的性能问题。

传统微内核用 Capability（能力令牌）管理内核对象（如页表）：OS 服务每次访问都要通过内核查表，有不小的开销。HM 的方案是把内核对象所在的物理页直接映射到 OS 服务的地址空间里，用这个映射地址作为令牌，让 OS 服务可以直接读写，绕过内核介入。论文实测，匿名内存页错误处理速度因此从比 Linux 慢 3.4 倍降到接近 Linux 水平。

这是一个内核工程内部的性能优化，和应用申请相机权限是不同的事情。

应用层权限：AccessToken

HarmonyOS NEXT 的框架层有另一套针对应用的权限机制，通常被称为 AccessToken（访问令牌管理）。当一个应用申请相机、位置等权限时，系统校验的是应用的 AccessToken，而不是 SELinux 标签。SELinux 在这里只处理更底层的系统组件之间的 MAC 隔离。

这个分层才是完整图景。

硬件地基与 TEE OS 的边界

在讨论系统安全架构时，TEE（可信执行环境）经常与 ARM 被结合在一起。理清硬件基础设施与操作系统实现之间的分工，有助于提供更准确的技术认知：

• ARM TrustZone（硬件层）：提供 CPU 级别的物理隔离，将算力状态划分为 Normal World 和 Secure World。它提供的是底层的内存保护机制和 SMC（Secure Monitor Call）指令切换，相当于构建了物理上的保险箱。
• TEE 规范与 OS（软件层）：TEE 是一套由 GlobalPlatform 制定的行业规范。但在硬件保险箱里具体运行什么系统，完全由底层软件开发商自己编写和实现。
• HM 的安全实现：HarmonyOS NEXT 在 Secure World 里运行的是基于其微内核架构的 iTrustee OS。

微内核架构凭借极小的可信计算基（TCB），天然适合作为极高安全场景的底座。根据 OSDI'24 论文，HM 微内核本身通过了 CC EAL 6+（Common Criteria 评估保证级别 6+）认证，同时满足车规级 ASIL-D 功能安全要求。这是目前商用通用操作系统中极少能达成的认证高度，构成了其在智能汽车或金融级密码处理等场景下的核心信任层。

总结

看到 鸿蒙OS里有SELinux 并不奇怪。这是工程上有意为之的：

1. 为了二进制兼容，NEXT 模拟出了 Linux 风格的 /proc 和 /sys 虚拟接口
2. 为了给这些接口加锁，复用了 SELinux 成熟的策略描述标准和工具链
3. 但执行引擎换掉了：从 Linux 内核的 LSM 钩子，变成了微内核用户态安全服务 + IPC 消息拦截

配置文件的存在是"表象层"的兼容性决策，执行引擎是"动力层"的架构演进。两件事不矛盾。

真正值得关注的问题不是"配置文件在不在"，而是：在高频 IPC 环境下（手机场景 41k 次/秒），把策略决策移到用户态之后，整体性能代价有多大？

OSDI'24 论文给出了实测结果：通过 Differentiated Isolation Classes（IC0/IC1/IC2）和 Address Token 等机制，HM 在手机上实现了比 Linux 快 17% 的应用启动时间，减少 10% 的掉帧率。这些数字来自华为自测，独立复现尚无公开数据，但至少说明这个架构在几千万台生产设备上是可行的。

参考来源

• Haibo Chen et al., Microkernel Goes General: Performance and Compatibility in the HongMeng Production Microkernel, OSDI'24, July 2024. https://www.usenix.org/conference/osdi24/presentation/chen-haibo