System 应用访问 Vendor 库的详细方案

• 系统签名 (System Signature)
• 自定义 SELinux 策略 (Custom SELinux Policy)
• 使用 VNDK (Vendor Native Development Kit)

本文首发地址：https://h89.cn/archives/367.html

system 应用访问 vendor 库的方案有以下几种：系统签名、自定义 SELinux 策略和使用 VNDK。

好的，我们来详细介绍一下前面提到的三种主要的 system 应用访问 vendor 库的方案：系统签名、自定义 SELinux 策略和使用 VNDK。

系统签名 (System Signature)

原理：

在 Android 系统中，应用程序可以使用不同的证书进行签名。系统签名是指使用与构建 Android 操作系统时相同的密钥对应用程序进行签名。拥有系统签名的应用程序被视为受信任的系统组件，因此通常会被授予比普通第三方应用更高的权限。这些权限可以包括访问受保护的系统资源、调用特权 API，以及在某些情况下，绕过一些针对普通应用的隔离限制，例如访问 vendor 分区的库。

详细配置方法：

要在编译 system 应用时使用系统签名，您需要在 Android 源码环境下进行操作，并修改应用的构建配置文件。

• Android.mk (旧的构建系统):

    LOCAL_PATH := $(call my-dir)
    include $(CLEAR_VARS)
    LOCAL_MODULE_TAGS := optional  # 或 user/release 等
    LOCAL_SRC_FILES := $(call all-subdir-java-files) # 应用的 Java 源代码
    LOCAL_PACKAGE_NAME := YourSystemApp # 你的应用包名
    LOCAL_CERTIFICATE := platform       # 指定使用平台签名
    LOCAL_PRIVILEGED_MODULE := true    # 将应用标记为特权应用 (通常与系统签名一起使用，授予更多权限)
    # 可选的其他配置，如依赖的库等
    include $(BUILD_PACKAGE)

  • LOCAL_CERTIFICATE := platform 是关键指令，它指示构建系统使用平台签名密钥对该应用进行签名。
  • LOCAL_PRIVILEGED_MODULE := true 通常与系统签名一起使用，将应用安装到 /system/priv-app 目录下，使其能够访问特权权限。

• Android.bp (Soong 构建系统 - 较新的 Android 版本):

    android_app {
        name: "YourSystemApp",             # 应用模块名
        srcs: ["src/**/*.java"],           # 应用的 Java 源代码
        platform_apis: true,             # 允许访问平台私有 API (如果需要)
        certificate: "platform",          # 指定使用平台签名
        privileged: true,                # 标记为特权应用
        system_ext_specific: true,       # 如果应用属于 system_ext 分区
        product_specific: true,          # 如果应用属于 product 分区
        // vendor_specific: true,         # 注意：system 应用通常不应直接属于 vendor 分区
        // ... 其他依赖和配置
    }

  • certificate: "platform" 指示使用平台签名。
  • privileged: true 同样用于标记为特权应用。
  • system_ext_specific: true 和 product_specific: true 用于指定应用构建到哪个分区，system 应用通常会位于 system 或 system_ext 分区。

优点：

• 符合 Android 安全模型： 系统签名是 Android 区分受信任系统组件和普通应用的主要机制。
• 权限授予： 拥有系统签名的应用通常会被自动授予许多系统级权限，这可能包括访问某些 vendor 库所需的权限。
• 相对简单： 相较于自定义 SELinux 策略，配置系统签名通常更直接。

缺点：

• 需要源码环境： 必须在 Android 源码环境下编译应用才能使用平台签名。
• 密钥管理： 系统签名密钥是高度敏感的，必须妥善保管。泄露会导致严重的安全风险。
• 过度授权风险： 拥有系统签名的应用权限较高，如果应用存在安全漏洞，可能会对系统造成更大的影响。
• 不适用于第三方应用： 这种方法仅适用于作为系统镜像一部分构建的应用，不适用于普通的第三方开发者。

自定义 SELinux 策略 (Custom SELinux Policy)

原理：

SELinux 是 Android 的强制访问控制 (MAC) 系统，它通过安全策略规则来限制进程对系统资源的访问。每个进程和文件都有一个安全上下文（Security Context），SELinux 策略定义了不同安全上下文之间的交互规则。默认情况下，system 应用的上下文和 vendor 库的上下文可能不允许直接访问。通过自定义 SELinux 策略，可以显式地允许特定的 system 应用访问特定的 vendor 库。

详细配置方法：

1. 确定安全上下文 (Security Contexts):

   • 使用 adb shell ps -Z | grep <your_system_app_process_name> 查找你的 system 应用进程的 SELinux 上下文。输出类似于 u:r:system_app:s0:cxxx,cxxx <PID> <UID> ... <your_system_app_process_name>，你需要记录 u:r:system_app:s0 部分（实际名称可能不同）。
   • 使用 adb shell ls -Z <path_to_vendor_library> 查找 vendor 库文件的 SELinux 上下文。输出类似于 -rwxr-xr-x u:object_r:vendor_lib_file:s0 <user> <group> ... <path_to_vendor_library>，你需要记录 u:object_r:vendor_lib_file:s0 部分（实际名称和类型可能不同）。

2. 编写 SELinux 策略规则 (.te 文件):

   • 在 Android 源码的设备特定 SELinux 策略目录中 (device/[manufacturer]/[device]/sepolicy 或其子目录，例如 system 或创建一个新的 vendor_access 目录），创建一个或修改 .te 文件。例如，创建一个名为 system_app.te 的文件（如果你的策略是针对特定的 system 应用）。

   • 添加 allow 规则，允许 system 应用域 (system_app 在这里是示例，替换为你的实际域) 访问 vendor 库文件类型 (vendor_lib_file 在这里是示例，替换为你的实际类型) 的特定操作：

       typeattribute system_app appdomain; # 如果你的应用域还没有类型属性，可以添加
     
       # 允许 system_app 域读取 vendor_lib_file 类型的文件
       allow system_app vendor_lib_file:file { read open getattr map };
     
       # 如果 vendor 库需要执行（例如，是可执行文件），可能需要 execute 权限
       allow system_app vendor_lib_file:file execute;
     
       # 如果 vendor 库是 vendor 服务，可能需要允许 Binder 通信
       # 假设 vendor 服务的类型是 vendor_service
       allow system_app vendor_service:binder { call transfer };

   • 你可能还需要添加 type 定义（如果 vendor_lib_file 不是已知的类型）或 typeattribute 关联。

3. 配置 Android.bp 或 Android.mk 以包含你的策略文件:

   • 在设备特定的 sepolicy 目录下的 Android.bp 或 Android.mk 文件中，确保你的 .te 文件被包含在编译过程中。

   • Android.bp 示例 (通常在 device/[manufacturer]/[device]/sepolicy/Android.bp):

       sepolicy_compile_dirs = [
           "system",
           "vendor",
           "private",
           // ... 其他目录
       ]
     
       sepolicy_rules = [
           "system_app.te",
           // ... 其他 .te 文件
       ]

4. 编译和部署 SELinux 策略:

   • 在 Android 源码根目录下编译 SELinux 策略：

       make sepolicy -j$(nproc)

   • 编译成功的 sepolicy 文件通常位于 out/target/product/[device]/root/sepolicy 或 out/target/product/[device]/system/etc/selinux/plat_sepolicy.cil。
   • 将新的 sepolicy 文件刷入设备。这通常需要重新刷写系统镜像。

优点：

• 细粒度控制： 可以精确控制哪些 system 应用可以访问哪些 vendor 资源以及如何访问。
• 安全性： 如果配置正确，SELinux 可以增强系统的安全性。

缺点：

• 复杂性： SELinux 策略的编写和调试非常复杂，需要深入理解 SELinux 的概念和语法。
• 维护困难： 随着系统和应用的变化，SELinux 策略可能需要更新和维护。
• 潜在风险： 配置错误的 SELinux 策略可能导致系统崩溃、功能异常或安全漏洞。
• 设备依赖： SELinux 策略通常是设备特定的。

使用 VNDK (Vendor Native Development Kit)

原理：

Project Treble 架构引入了 VNDK，旨在为 system 和 vendor 分区之间的原生库提供稳定的接口。VNDK 包含了一组可以在这两个分区之间安全共享的库。system 应用应该尽可能地链接到 VNDK 提供的库，而不是直接依赖 vendor 分区的私有库。

详细配置方法：

1. vendor 模块构建为 VNDK 库:

   • 在 vendor 模块的 Android.bp 文件中，需要将其标记为 VNDK 库。这通常通过设置 vendor: true 和指定 vndk: { ... } 属性来实现。例如：

       cc_library_shared {
           name: "vendor.example.mylib",
           srcs: ["src/mylib.c"],
           vendor: true,
           vndk: {
               enabled: true,
               support_system_process: true, # 如果需要 system 进程访问
           },
           // ... 其他配置
       }

   • enabled: true 表明这是一个 VNDK 库。
   • support_system_process: true 表明 system 进程可以链接到这个 VNDK 库。

2. system 应用链接到 VNDK 库:

   • 在 system 应用的 Android.bp 文件中，需要链接到相应的 VNDK 库。这通常通过在 shared_libs 属性中指定 VNDK 库的名称（通常带有 vndk- 前缀或特定的命名约定）。

       android_app {
           name: "YourSystemApp",
           srcs: ["src/**/*.java"],
           // ... 其他配置
           native_libs: [
               "libexample.so", // 如果你的应用直接使用了 .so 文件
           ],
           shared_libs: [
               "vndk-vendor.example.mylib", // 链接到 VNDK 版本的库
               // ... 其他共享库
           ],
           // ...
       }
     
       cc_binary { // 如果你的 system 应用包含原生代码
           name: "your_system_native_binary",
           srcs: ["src/main.c"],
           shared_libs: [
               "vndk-vendor.example.mylib",
               // ... 其他共享库
           ],
           // ...
       }

   • 构建系统会自动处理 VNDK 库的链接和依赖关系。

优点：

• 架构规范： 符合 Android 的模块化和分区架构设计。
• 接口稳定： VNDK 旨在提供 system 和 vendor 之间更稳定的接口，减少因 vendor 分区更新导致 system 应用不兼容的风险。
• 安全性： VNDK 库经过精心设计，可以在不同安全域之间安全地共享。

缺点：

• VNDK 覆盖有限： 并非所有的 vendor 库都有对应的 VNDK 版本。设备制造商需要投入精力将 vendor 库适配为 VNDK 库。
• 适配工作： 如果 system 应用需要的功能在 VNDK 中没有直接对应的库，可能需要设备制造商进行额外的适配和开发工作。
• 版本兼容性： 需要注意 VNDK 的版本兼容性，system 和 vendor 分区需要使用兼容的 VNDK 版本。

总结：

这三种方案各有优缺点，选择哪种取决于具体的场景、需求和 Android 系统的版本。在现代 Android 系统中，系统签名 是 system 应用获取必要权限的常用方法，而 VNDK 是推荐的跨分区库依赖的架构方案。自定义 SELinux 策略 作为一种更细粒度的权限控制手段，通常在需要更精确的安全管理时使用，但其复杂性也更高。

---

以上内容来自 豆包方案 + Gemini 总结，仅供参考。

---