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 政策来妥善处理每个拒绝事件。请参阅自定义中的示例。