SELinux 被设置为“默认拒绝”模式,这表示,对于在内核中存在钩子的每一次访问,都必须获得政策的明确许可。这意味着政策文件中包含规则、类型、类、权限等方面的大量信息。关于 SELinux 的完整注意事项不在本文档的讨论范围之内,现在您必须要了解的是在启动新的 Android 设备时如何编写政策规则。目前有大量关于 SELinux 的信息可供您参考。关于建议的资源,请参阅支持文档。
关键文件
如需启用 SELinux,请集成最新的 Android 内核,然后整合 system/sepolicy 目录中的文件。这些文件在编译后会包含 SELinux 内核安全政策,并涵盖上游 Android 操作系统。
通常情况下,您不能直接修改 system/sepolicy
文件,但您可以添加或修改自己的设备专用政策文件(位于 /device/manufacturer/device-name/sepolicy
目录中)。在 Android 8.0 及更高版本中,您对这些文件所做的更改只会影响供应商目录中的政策。如需详细了解 Android 8.0 及更高版本中的公共 sepolicy 分离,请参阅在 Android 8.0 及更高版本中自定义 SEPolicy。无论是哪个 Android 版本,您都仍需要修改以下文件:
政策文件
以 *.te
结尾的文件是 SELinux 政策源代码文件,用于定义域及其标签。您可能需要在 /device/manufacturer/device-name/sepolicy
中创建新的政策文件,但您应尽可能尝试更新现有文件。
上下文的描述文件
您可以在上下文的描述文件中为您的对象指定标签。
file_contexts
用于为文件分配标签,并且可供多种用户空间组件使用。在创建新政策时,请创建或更新该文件,以便为文件分配新标签。如需应用新的file_contexts
,请重新构建文件系统映像,或对要重新添加标签的文件运行restorecon
。在升级时,对file_contexts
所做的更改会在升级过程中自动应用于系统和用户数据分区。此外,您还可以通过以下方式使这些更改在升级过程中自动应用于其他分区:在以允许读写的方式装载相应分区后,将restorecon_recursive
调用添加到 init.board.rc 文件中。genfs_contexts
用于为不支持扩展属性的文件系统(例如,proc
或vfat
)分配标签。此配置会作为内核政策的一部分进行加载,但更改可能对内核 inode 无效。要全面应用更改,您需要重新启动设备,或卸载并重新装载文件系统。 此外,通过使用context=mount
选项,您还可以为装载的特定系统文件(例如vfat
)分配特定标签。property_contexts
用于为 Android 系统属性分配标签,以便控制哪些进程可以设置这些属性。在启动期间,init
进程会读取此配置。service_contexts
用于为 Android binder 服务分配标签,以便控制哪些进程可以为相应服务添加(注册)和查找(查询)binder 引用。在启动期间,servicemanager
进程会读取此配置。seapp_contexts
用于为应用进程和/data/data
目录分配标签。在每次应用启动时,zygote
进程都会读取此配置;在启动期间,installd
会读取此配置。mac_permissions.xml
用于根据应用签名和应用软件包名称(后者可选)为应用分配seinfo
标记。随后,分配的seinfo
标记可在seapp_contexts
文件中用作密钥,以便为带有该seinfo
标记的所有应用分配特定标签。在启动期间,system_server
会读取此配置。keystore2_key_contexts
用于为密钥库 2.0 命名空间分配标签。 这些命名空间由 keystore2 守护程序强制执行。密钥库始终都提供基于 UID/AID 的命名空间。密钥库 2.0 还会强制执行 sepolicy 定义的命名空间。如需详细了解此文件的格式和规范,请点击此处。
BoardConfig.mk makefile
修改或添加政策文件和上下文的描述文件后,请更新您的 /device/manufacturer/device-name/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
重新进行构建后,您的设备会启用 SELinux。现在,您可以根据您向 Android 操作系统添加的内容自定义 SELinux 政策(如自定义中所述),也可以验证现有设置(如验证中所述)。
在新政策文件和 BoardConfig.mk 更新部署到位后,新政策设置会自动内置到最终的内核政策文件中。如需详细了解如何在设备上构建 sepolicy,请参阅构建 sepolicy。
实现
如需开始使用 SELinux,请执行以下操作:
- 在内核中启用 SELinux:
CONFIG_SECURITY_SELINUX=y
- 更改 kernel_cmdline 或 bootconfig 参数,以便:
BOARD_KERNEL_CMDLINE := androidboot.selinux=permissive
或BOARD_BOOTCONFIG := androidboot.selinux=permissive
这仅适用于初始制定设备政策的情况。在拥有初始引导程序政策后,请移除此参数,以便将设备恢复强制模式,否则设备将无法通过 CTS 验证。 - 以宽容模式启动系统,看看在启动时会遇到哪些拒绝事件:
在 Ubuntu 14.04 或更高版本中,请运行以下命令:adb shell su -c dmesg | grep denied | audit2allow -p out/target/product/BOARD/root/sepolicy
在 Ubuntu 12.04 中,请运行以下命令:adb pull /sys/fs/selinux/policy adb logcat -b all | audit2allow -p policy
- 评估警告输出,此类警告类似于
init: Warning! Service name needs a SELinux domain defined; please fix!
。如需查看相关说明和工具,请参阅验证。 - 标识设备以及需要添加标签的其他新文件。
- 为您的对象使用现有标签或新标签。查看
*_contexts
文件,了解之前是如何为内容添加标签的,然后根据对标签含义的了解分配一个新标签。这个标签最好是能够融入到政策中的现有标签,但有时也需要使用新标签,而且还需要提供关于访问该标签的规则。将您的标签添加到相应的上下文的描述文件中。 - 标识应该拥有自己的安全域的域/进程。您可能需要为每一项分别编写一个全新的政策。例如,从
init
衍生的所有服务都应该有自己的安全域。以下命令有助于查看保持运行的服务(不过所有服务都需要如此处理):
adb shell su -c ps -Z | grep init
adb shell su -c dmesg | grep 'avc: '
- 查看
init.device.rc
以发现没有域类型的域。请在开发过程早期为其提供相应的域,以避免向init
添加规则或将init
访问权限与其自身政策中的访问权限混淆。 - 设置
BOARD_CONFIG.mk
以使用BOARD_SEPOLICY_*
变量。如需详细了解如何进行此项设置,请参阅system/sepolicy
中的 README。 - 检查 init.device.rc 和 fstab.device 文件,确保每一次使用
mount
都对应一个添加了适当标签的文件系统,或者指定了context= mount
选项。 - 查看每个拒绝事件,并创建 SELinux 政策以妥善处理每个拒绝事件。请参阅自定义中的示例。
建议从 AOSP 中的政策入手,然后在这些政策的基础上创建自己的自定义政策。如需详细了解政策策略以及其中一些步骤,请参阅编写 SELinux 政策。
用例
下面列举了一些在开发软件以及制定关联的 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
标签的文件运行这些命令。