实现 SELinux

SELinux 设为了“默认拒绝”模式,也就是说,对于在内核中存在钩子的每一次访问,都必须获得政策的明确许可。这意味着政策文件中包含规则、类型、类、权限等方面的大量信息。关于 SELinux 的完整注意事项不在本文档的讨论范围之内,现在您必须要了解的是在启动新的 Android 设备时如何编写政策规则。目前有大量关于 SELinux 的信息可供您参考。关于建议的资源,请参阅支持文档

步骤总结

下面简要总结了在 Android 设备上实现 SELinux 时需要执行的步骤:

  1. 在内核和配置中添加 SELinux 支持。
  2. 为通过 init 启动的每项服务(进程或守护进程)分配专用的域。
  3. 通过以下方式标识这些服务:
    • 查看 init.<device>.rc 文件并找到所有服务。
    • 检查 dmesg 输出中以下形式的警告:“init: Warning! Service name needs a SELinux domain defined; please fix!”(init:警告!服务名称需要一个已定义的 SELinux 域;请更正!)。
    • 检查 ps -Z | grep init 输出,看看哪些服务正在 init 域中运行。
  4. 为所有新进程、驱动程序、套接字等添加标签。需要为所有对象添加适当的标签,以确保它们能够与您应用的政策正确交互。请参阅 AOSP 中使用的标签,以便在创建标签名称时参考。
  5. 制定全面涵盖所有标签的安全政策,并将权限限定到其绝对最低级别。

原始设备制造商 (OEM) 最好从 AOSP 中的政策入手,然后在这些政策的基础上创建自己的自定义政策。

关键文件

SELinux for Android 随附了立即启用 SELinux 所需的一切。您只需集成最新的 Android 内核,然后整合 system/sepolicy 目录中的文件即可:

https://android.googlesource.com/kernel/common/

https://android.googlesource.com/platform/system/sepolicy/

这些文件在编译后会包含 SELinux 内核安全政策,并涵盖上游 Android 操作系统。您应该不需要直接修改 system/sepolicy 中的文件,而只需添加您自己的设备专用政策文件(位于 /device/manufacturer/device-name/sepolicy 目录中)即可。

要实现 SELinux,您必须创建或修改以下文件:

  • 新的 SELinux 政策源代码 (*.te) 文件 - 位于 /device/manufacturer/device-name/sepolicy 目录中。这些文件用于定义域及其标签。在编译到单个 SELinux 内核政策文件时,新的政策文件会与现有的政策文件组合在一起。

    重要提示:请勿更改 Android 开放源代码项目提供的 app.te 文件,否则可能会破坏所有第三方应用。

  • 更新后的 BoardConfig.mk Makefile - 位于包含 sepolicy 子目录的目录中。如果初始实现中没有 sepolicy 子目录,那么在该子目录创建之后,必须更新 BoardConfig.mk makefile,以引用该子目录。
  • file_contexts - 位于 sepolicy 子目录中。该文件用于为文件分配标签,并且可供多种用户空间组件使用。在创建新政策时,请创建或更新该文件,以便为文件分配新标签。要应用新的 file_contexts,您必须重新构建文件系统映像,或对要重新添加标签的文件运行 restorecon。在升级时,对 file_contexts 所做的更改会在升级过程中自动应用于系统和用户数据分区。此外,还可以通过以下方式使这些更改在升级过程中自动应用于其他分区:在以允许读写的方式装载相应分区后,将 restorecon_recursive 调用添加到 init.board.rc 文件中。
  • genfs_contexts - 位于 sepolicy 子目录中。该文件用于为不支持扩展属性的文件系统(例如,proc 或 vfat)分配标签。此配置会作为内核政策的一部分进行加载,但更改可能对核心内 inode 无效。要全面应用更改,需要重新启动设备,或卸载后重新装载文件系统。此外,通过使用 context=mount 选项,还可以为装载的特定系统文件(例如 vfat)分配特定标签。
  • property_contexts - 位于 sepolicy 子目录中。该文件用于为 Android 系统属性分配标签,以便控制哪些进程可以设置这些属性。在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,init 进程都会读取此配置。
  • service_contexts - 位于 sepolicy 子目录中。该文件用于为 Android Binder 服务分配标签,以便控制哪些进行可以为相应服务添加(注册)和查找(查询)Binder 引用。在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,servicemanager 进程都会读取此配置。
  • seapp_contexts - 位于 sepolicy 子目录中。该文件用于为应用进程和 /data/data 目录分配标签。在每次应用启动时,Zygote 进程都会读取此配置;在启动期间以及 selinux.reload_policy 属性每次被设为 1 时,installd 都会读取此配置。
  • mac_permissions.xml - 位于 sepolicy 子目录中。该文件用于根据应用签名和应用软件包名称(后者可选)为应用分配 seinfo 标记。然后,分配的 seinfo 标记可在 seapp_contexts 文件中用作密钥,以便为带有该 seinfo 标记的所有应用分配特定标签。在启动期间,system_server 会读取此配置。

接下来,只需在 sepolicy 子目录和各个政策文件创建之后,更新 BoardConfig.mk Makefile(位于包含 sepolicy 子目录的目录中)以引用该子目录和这些政策文件即可,如下所示。BOARD_SEPOLICY 变量及其含义记录在 system/sepolicy/README 文件中。

BOARD_SEPOLICY_DIRS += \
        <root>/device/manufacturer/device-name/sepolicy

BOARD_SEPOLICY_UNION += \
        genfs_contexts \
        file_contexts \
        sepolicy.te

注意:从 M 版开始已不再需要 BOARD_SEPOLICY_UNION,因为 BOARD_SEPOLICY_DIRS 变量中包含的任何目录内的所有政策文件都会与基本政策自动合并。

设备在重新编译后会启用 SELinux。现在,您可以根据自己向 Android 操作系统添加的内容自定义自己的 SELinux 政策(如自定义中所述),也可以验证您的现有设置(如验证中所述)。

在新政策文件和 BoardConfig.mk 更新部署到位后,新政策设置会立即自动内置到最终的内核政策文件中。

用例

下面列举了一些在开发软件以及制定关联的 SELinux 政策时需要注意的具体漏洞:

符号链接 - 由于符号链接以文件形式显示,因此通常也是作为文件被读取。这可能会导致漏洞。例如,某些特权组件(例如 init)会更改某些文件的权限,有时会使之极度开放。

这样一来,攻击者便可以将这些文件替换成指向其控制的代码的符号链接,从而重写任意文件。但如果您知道自己的应用绝不会遍历符号链接,则可以通过 SELinux 来禁止您的应用遍历符号链接。

系统文件 - 以应该只有系统服务器可以修改的一系列系统文件为例。由于 netd、init 和 vold 是以 Root 身份运行的,因此它们也可以访问这些系统文件。这样一来,如果 netd 遭到入侵,它将可以入侵这些文件,并可能会入侵系统服务器本身。

借助 SELinux,您可以将这些文件标识为系统服务器数据文件。这样一来,系统服务器就是唯一对这些文件具有读写权限的域。即使 netd 遭到入侵,它也无法将域切换到系统服务器域并访问这些系统文件,就算它是以 Root 身份运行的也是如此。

应用数据 - 另一个示例是必须以 Root 身份运行但不应获得应用数据访问权限的一系列函数。这非常有用,因为可以做出广泛的声明,例如禁止与应用数据无关的特定域访问互联网。

setattr - 对于 chmod、chown 等命令,您可以标识关联域可以在哪些文件中进行 setattr 操作。这样一来,便可以禁止对这些文件之外的任何文件进行此类更改,即使以 Root 身份进行也不例外。因此,应用可以对带 app_data_files 标签的文件运行 chmod 和 chown 命令,但不能对带 shell_data_files 或 system_data_files 标签的文件运行这些命令。

详细步骤

下面详细介绍了 Android 建议您如何采用并自定义 SELinux 来保护设备:

  1. 在内核中启用 SELinux: CONFIG_SECURITY_SELINUX=y
  2. 更改 kernel_cmdline 参数,以便:
    BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
    这仅适用于初始制定设备政策的情况。在拥有初始引导程序政策后,请移除此参数,以便将设备恢复强制模式,否则设备将无法通过 CTS 验证。
  3. 以宽容模式启动系统,看看在启动时会遇到哪些拒绝事件:
    在 Ubuntu 14.04 或更高版本中:
    adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/board/root/sepolicy
    在 Ubuntu 12.04 中: adb shell su -c dmesg | grep denied | audit2allow
  4. 评估输出。如需查看相关说明和工具,请参阅验证
  5. 标识设备以及需要添加标签的其他新文件。
  6. 为您的对象使用现有标签或新标签。查看 *_contexts 文件,了解之前是如何为内容添加标签的,然后根据对标签含义的了解分配一个新标签。这最好是一个能够融入到政策中的现有标签,但有时需要使用新标签,并且还需要关于访问该标签的规则。
  7. 标识应该拥有自己的安全域的域/进程。可能需要为其中每个域/进程从头开始编写政策。例如,从 init 衍生的所有服务都应该有自己的安全域。可以通过以下命令查看保持运行的服务(不过所有服务都需要如此处理):
    $ adb shell su -c ps -Z | grep init
    $ adb shell su -c dmesg | grep 'avc: '
  8. 查看 init.<device>.rc,以找出所有没有类型的服务。应提早为此类服务提供域,以避免向 init 添加规则或将 init 访问权限与其自身政策中的访问权限混淆。
  9. BOARD_CONFIG.mk 设为使用 BOARD_SEPOLICY_* 变量。如需关于如何进行此项设置的详细信息,请参阅 system/sepolicy 中的 README。
  10. 检查 init.<device>.rc 和 fstab.<device> 文件,确保每一次使用“mount”都对应一个添加了适当标签的文件系统,或者指定了 context= mount 选项。
  11. 查看每个拒绝事件,并创建 SELinux 政策来妥善处理每个拒绝事件。请参阅自定义中的示例。