Android的安全问题 - 在 Android 源码的 system/sepolicy 目录中，区分 public、private 和 vendor的目的

参考：Google文档 在 Android 8.0 及更高版本中自定义 SEPolicy

在 Android 源码的 system/sepolicy 目录中，区分 public、private 和 vendor 是为了模块化 SELinux 策略，并明确不同部分的访问权限和接口边界。这种设计主要基于以下原因：

1. public 目录

• 目的：定义 公开的 SELinux 策略接口，供其他模块（如厂商代码或第三方组件）直接调用。
• 特点：
  • 包含策略中允许外部访问的类型（type）、属性（attribute）和接口（interface）。
  • 例如，hal_foo_client 可能被声明为 public，允许厂商实现的 HAL 服务与之交互。
  • 这些策略是稳定的，Google 会保证其兼容性，避免在 Android 版本升级时破坏依赖它的代码。

2. private 目录

• 目的：定义 系统内部使用的私有策略，禁止外部模块直接依赖。
• 特点：
  • 包含仅限 AOSP 系统核心组件（如 system_server、zygote）使用的类型和规则。
  • 例如，system_app 的某些权限可能被标记为 private，禁止厂商应用直接访问。
  • Google 可能在不同版本中随时修改这些策略，无需考虑兼容性。

3. vendor 目录

• 目的：为 厂商（OEM/SoC 供应商） 提供扩展策略的入口。
• 特点：
  • 包含厂商自定义的 SELinux 策略（如设备特定的硬件 HAL、内核模块等）。
  • 允许厂商在 vendor 分区添加自己的策略文件（如 vendor/foo/sepolicy），并通过 vendor 目录下的规则与 AOSP 策略交互。
  • Google 通过 vendor 目录明确划分策略边界，避免厂商直接修改 AOSP 核心策略。

为什么需要这种划分？

1. 兼容性控制

   • public 策略是稳定的，确保厂商代码在 Android 版本升级后仍能正常工作。
   • private 策略可以灵活调整，不影响外部模块。

2. 安全边界

   • 防止厂商或第三方滥用系统权限（例如，禁止厂商应用访问 private 的系统服务）。

3. 模块化设计

   • 分离核心策略（AOSP）和厂商扩展策略，降低耦合性。

实际示例

• public/foo.te
  定义 hal_foo_service 类型，并允许厂商 HAL 进程通过 hal_foo_client 访问它。
• private/system_server.te
  限制只有 system_server 可以访问某些敏感资源（如 user_data_file）。
• vendor/hal_foo.te
  厂商在此文件中为自家 HAL 实现添加自定义规则。

总结

这种划分是 Android 保护核心系统安全、维护兼容性，同时允许厂商灵活定制的重要设计。开发者需遵守以下原则：

• 如果需要扩展策略，优先使用 public 接口。
• 避免直接依赖 private 内容。
• 厂商自定义策略应放在 vendor 目录或设备特定的 sepolicy 路径。