当前位置：首页 > news >正文

SELinux 入门指南

news 2025/8/10 8:06:08

SELinux(Security-Enhanced Linux)是 Linux 内核的一个安全模块，它提供了一种强制访问控制（Mandatory Access Control, MAC）机制。与传统的 Linux 自主访问控制（Discretionary Access Control, DAC）不同，SELinux 不依赖于文件的所有者和权限来控制访问，而是通过一套预先定义的策略，强制性地对所有进程和资源（如文件、目录、端口等）进行访问控制。即使是 root 用户，其行为也会受到 SELinux 策略的限制，这大大增强了系统的安全性。

1. SELinux 原理介绍

SELinux 的核心是基于 "域-类型"（Domain-Type）模型的强制访问控制。

主体（Subject）和客体（Object）：

主体通常是指一个正在运行的进程，它试图访问某些资源。

客体是指被访问的资源，如文件、目录、网络端口等。

安全上下文（Security Context）：

这是 SELinux 工作的基石。每个主体和客体都有一个唯一的安全上下文标签。

一个完整的安全上下文通常由四个部分组成：user:role:type:sensitivity。

在 Android 中，最重要的是 type，它决定了进程可以访问哪些资源，以及资源可以被哪些进程访问。通常以 _t 结尾，例如 untrusted_app_t、system_server_t。

策略（Policy）和规则（Rule）：

策略是 SELinux 的核心，它定义了系统中的所有访问控制规则。

规则的形式通常为：allow <source_type> <target_type>:<class> <permissions>;

source_type：请求访问的主体的类型。

target_type：被访问的客体的类型。

class：客体的类别，如 file, dir, socket 等。

permissions：允许的操作，如 read, write, execute 等。

简而言之，当一个进程（主体）试图对一个资源（客体）执行某个操作时，SELinux 会首先检查它们各自的安全上下文。然后，它会在策略中查找是否存在一条允许 source_type 对 target_type 执行该 class 的 permission 的规则。如果找不到，访问就会被拒绝。

2. SELinux 的运行模式

SELinux 有三种主要运行模式，你可以通过adb shell getenforce 命令查看当前模式，并使用 adb shell setenforce 命令临时切换。

强制模式（enforcing）：

这是最严格的模式。SELinux 策略被严格执行，任何违反策略的访问都会被拒绝并记录到日志中。

在生产环境中，系统通常运行在强制模式下以确保最大安全性。

宽容模式（permissive）：

SELinux 策略不会被强制执行。所有违反策略的访问都会被允许，但会像在强制模式下一样，将拒绝信息记录到日志中。

这个模式非常适合开发和调试，你可以通过日志来发现策略中存在的缺陷，而不会导致系统功能异常。

禁用模式（disabled）：

SELinux 完全不工作。不进行任何访问控制，也不记录任何日志。

不建议在任何情况下使用此模式，因为它会极大地降低系统的安全性。

Android 高通平台上的 SELinux 示例方法

在 Android 系统中，SELinux 是其安全模型的重要组成部分。对于高通（Qualcomm）平台，SELinux 的应用尤为关键。以下是一些常见场景及其 SELinux 策略的示例：

示例 1: 访问自定义设备节点

假设你开发了一个自定义的驱动程序，并在 /dev/my_device 创建了一个设备节点。现在，一个名为 my_service 的服务进程需要访问它。

定义设备节点的类型：在策略文件中（通常是 .te 文件，如 vendor/qcom/proprietary/common/sepolicy/my_service.te），你需要为这个设备节点定义一个类型。

代码段

# 定义设备节点 my_device 的类型为 my_device_dev

type my_device_dev, dev_type;

设置文件上下文：接下来，你需要告诉系统，/dev/my_device 这个路径下的文件应该被打上 my_device_dev 的标签。这通常在 file_contexts 文件中完成。

代码段

# file_contexts 文件

/dev/my_device u:object_r:my_device_dev:s0

为服务进程定义访问权限：最后，你需要为 my_service 进程定义一个 domain（域），并授予它访问 my_device_dev 类型的权限。

代码段

# my_service.te 文件

# 定义 my_service 进程的 domain

type my_service_t, domain;

# 授予 my_service_t 对 my_device_dev 的读写权限

allow my_service_t my_device_dev:chr_file { read write };

示例 2: 访问自定义属性文件

如果你的服务需要通过 sysfs（/sys）来控制硬件，例如通过 /sys/class/my_hw/status 文件读取状态。

定义 sysfs 文件的类型： sysfs 文件也有自己的类型。

代码段

# 在 sysfs_entry.te 中定义

type my_hw_status_sysfs, sysfs_type, fs_type;

设置文件上下文：在 file_contexts 中指定这个 sysfs 文件的类型。

代码段

# file_contexts 文件

/sys/class/my_hw/status u:object_r:my_hw_status_sysfs:s0

为服务进程授予权限：给 my_service 进程授予读取 my_hw_status_sysfs 类型的权限。

代码段

# my_service.te 文件

allow my_service_t my_hw_status_sysfs:file { read };

调试手段与日志分析

调试 SELinux 问题是开发过程中不可或缺的一部分。当出现 Permission denied 错误时，往往就是 SELinux 策略阻止了访问。

日志打印

SELinux 的拒绝信息（denials）会被内核记录到 dmesg 和 auditd 日志中。你可以通过以下命令查看这些日志。

查看内核日志：在 adb shell 中使用 dmesg 命令。拒绝信息通常包含 avc: denied 关键词。

Shell

adb shell "dmesg | grep 'avc: denied'"

一条典型的拒绝日志如下：

avc: denied { read } for pid=1234 comm="my_service" name="my_device" dev="tmpfs" ino=12345 scontext=u:r:my_service_t:s0 tcontext=u:object_r:my_device_dev:s0 tclass=chr_file permissive=0

日志解读：

denied { read }：被拒绝的操作是 read。

pid=1234 comm="my_service"：请求访问的进程 ID 和名称。

scontext=u:r:my_service_t:s0：主体的安全上下文。

tcontext=u:object_r:my_device_dev:s0：客体（被访问资源）的安全上下文。

tclass=chr_file：客体的类别，这里是字符设备文件。

permissive=0：表示当前处于强制模式。如果是 permissive=1，则表示处于宽容模式，此次访问被允许，但仍有日志记录。

调试工具

audit2allow：这是一个强大的工具，它可以根据日志中的拒绝信息自动生成 SELinux 策略规则。

首先，在宽容模式下复现问题，确保日志中记录了所有拒绝信息。

将 dmesg 日志导出到文件中。

Shell

adb shell "dmesg | grep 'avc: denied'" > avc.log

使用 audit2allow 工具生成规则。

Shell

audit2allow -i avc.log -M my_service_policy

这个命令会生成两个文件：my_service_policy.te 和 my_service_policy.cil。my_service_policy.te 文件中包含了建议添加的规则，你可以将其合并到你的策略文件中。

seinfo 和 sesearch：

seinfo 可以用来查看当前加载的 SELinux 策略信息，例如所有类型、属性等。

sesearch 允许你查询策略中是否存在特定的规则，是分析现有策略的利器。

2 neverallow 策略简介

2.1 neverallow 是一种特殊的 SELinux 策略，顾名思义，它永远不允许某些特定的访问。它的存在是为了强化系统的安全，防止策略编写者无意中授予过于宽泛或危险的权限。

与普通的 allow 规则不同，neverallow 规则一旦被定义，就无法通过任何方式（包括添加 allow 规则）来覆盖。如果你的策略中任何一条 allow 规则与 neverallow 规则冲突，SELinux 策略编译器（sepolicy-compile）就会报错，导致编译失败。

neverallow 的典型用途：

限制特权进程的行为：例如，防止像 init 这样的高权限进程访问普通应用程序的数据。

防止跨域访问：确保不同安全域（如 system、vendor、app）之间的隔离。

禁止危险操作：例如，阻止任何非 init 进程创建 dev_t 类型的文件。

2.2 如何规避 neverallow 策略

因为 neverallow 无法被直接覆盖，所以“规避”它并不是指“绕过”它的限制，而是指通过修改你的策略设计来避免触发 neverallow 规则。

这里有几种常见的方法：

方法一：使用特定属性（attribute）

neverallow 规则通常是针对一个**属性（attribute）**而不是一个具体的类型。例如，一个 neverallow 规则可能禁止所有具有 untrusted_app 属性的类型访问 system_data 目录。

代码段

# 这是一个 hypothetical (假设的) neverallow 规则

neverallow untrusted_app system_data_file:dir { read write };

如果你有一个自定义的 app 类型 my_app_t，并且它被赋予了 untrusted_app 属性，那么它就无法访问 system_data_file。

规避方法：

不要将你的类型与受限属性关联。如果你的 my_app_t 不需要 untrusted_app 的所有权限，你可以不把它定义为 untrusted_app。

创建新的、更细粒度的属性。如果你需要访问某些受限资源，可以考虑创建一个新的属性，并让 neverallow 规则只针对旧的、宽泛的属性。但这需要修改 AOSP 的核心策略，通常不推荐。

方法二：修改你的代码逻辑

很多时候，触发 neverallow 是因为你的代码试图以一种不安全的方式访问资源。

规避方法：

不要直接访问受限资源。如果你的进程需要访问一个被 neverallow 规则禁止的资源，你应该重新设计你的代码。例如，通过调用一个有权限的**服务（service）**来间接操作，而不是直接访问。

使用 SELinux 允许的接口。Android 提供了 binder、hwservice 等多种 IPC（进程间通信）机制。你应该通过这些机制调用有权限的服务，让服务来完成操作，而不是自己去突破限制。

方法三：修改 SELinux 策略，但要谨慎

这是最后的手段，通常只在特殊情况下才需要。修改 neverallow 规则本身可能会削弱系统的安全性。

规避方法：

在 OEM 策略中添加例外。在某些高通平台，允许在 vendor/qcom/proprietary/common/sepolicy 目录下添加一些 OEM 特有的策略。如果 AOSP 的 neverallow 规则对你的特定功能造成了不合理的限制，并且你确定该操作是安全的，你可以考虑在 OEM 策略中添加更细粒度的 neverallow 规则或调整现有规则。但这需要非常小心，并进行充分的安全审计。

3. system_app 添加 per-property 属性的注意事项

在 Android 系统中，system_app 是一种特殊的应用程序，它们通常具有比普通应用更高的权限。为 system_app 添加 per-property 属性（即每个属性都有独立的 SELinux 类型）是常见的需求，尤其是在需要和自定义服务通信时。

示例：system_app 和自定义属性

假设你有一个 system_app，其进程类型是 system_app_t，你需要让它能设置一个自定义的系统属性 vendor.my.custom.prop。

定义属性类型：在你的策略文件（如 vendor/qcom/proprietary/common/sepolicy/vendor.te）中，首先定义这个属性的类型。

代码段

# 定义自定义属性的类型

type my_custom_prop, property_type;

设置属性上下文：在 property_contexts 文件中，将你的属性和类型关联起来。

代码段

# property_contexts 文件

vendor.my.custom.prop u:object_r:my_custom_prop:s0

授予 system_app 设置权限：现在，你需要允许 system_app_t 类型的进程设置这个属性。

代码段

# system_app.te (或者你的自定义策略文件)

# 允许 system_app_t 对 my_custom_prop 类型进行 set 权限

allow system_app_t my_custom_prop:property_service set;

注意事项：

neverallow 检查：即使是 system_app_t，也可能会受到一些 neverallow 规则的限制。例如，可能存在 neverallow system_app_t property_type:property_service set; 这样的规则，禁止 system_app 设置某些核心系统属性。在添加新的 allow 规则之前，最好检查一下是否存在相关的 neverallow 限制。

权限最小化原则：永远遵循最小权限原则。只授予 system_app 必要的权限，不要为了方便而授予过于宽泛的权限，例如 allow system_app_t property_type:property_service *;。

区分 system_app 和 vendor 进程：system_app 运行在 system 分区，而 vendor 进程运行在 vendor 分区。两者有不同的 SELinux 域，不能混用。确保你的 system_app 策略只影响 system_app_t 域，而不会影响到 vendor 域。

SELinux 策略隔离：Android GSI (Generic System Image) 要求 vendor 策略和 system 策略隔离。因此，你不能在 system 分区的策略中直接引用 vendor 策略中定义的类型，反之亦然。你需要通过 vendor_init_t 等中间类型或特定的属性来桥接这两个分区。

总之，neverallow 策略是 SELinux 安全模型的重要保障。理解它的原理并采取正确的策略设计，而不是试图绕过它，才能确保你所构建的 Android 系统既安全又稳定。

3、SELinux 策略修改示例与规范

在 Android 高通平台上的 SELinux 策略修改，旨在实现对工厂端回读信息的支持。这些修改涉及多个核心 SELinux 策略文件，体现了在自定义系统功能时如何正确扩展策略。

下面是根据你的提交内容，对 SELinux 策略修改的详细分析、解释和注意事项。

3.1.策略文件修改分析

你的修改主要集中在 shell.te、property.te、property_contexts 和 init 相关的策略文件中。这些修改的核心目标是：

定义新的属性类型：为 xxx相关的持久化属性（如 sn, snPcba, product.model）创建了新的 SELinux 类型。

允许 shell 和 init 访问这些属性：授予 shell 和 vendor_init 域的进程读写这些新定义属性的权限。

允许 shell 访问特定文件：为 shell 域添加了对特定文件（如 em_bluetooth_prop 和 mnt_vendor_file）的读取权限。

Vendor分区属性在BoradConfig.mk中添加 BUILD_BROKEN_VENDOR_PROPERTY_NAMESPACE 标记，这通常用于绕过对 vendor 属性命名空间的严格检查。

3.2 SELinux 策略修改示例详解

以下是根据你提供的 diff 内容，对每个重要修改点的具体分析。

示例 1：在 shell.te 中添加文件访问权限

Diff

--- a/LA.QSSI.12.0.r1/LINUX/android/system/sepolicy/prebuilts/api/32.0/private/shell.te+++ b/LA.QSSI.12.0.r1/LINUX/android/system/sepolicy/prebuilts/api/32.0/private/shell.te@@ -48,6 +48,9 @@ allow shell perfetto:process signal;

allow shell self:udp_socket { ioctl getopt setopt };

allow shell self:tcp_socket { ioctl getopt setopt };

allow shell mnt_vendor_file:dir { read getattr search open };+allow shell xx_bluetooth_prop:file { read open getattr map };+allow shell sysfs:file { open read getattr map };+allow shell mnt_vendor_file:file { open read getattr map};

修改目的：允许 shell 进程读取 xx_bluetooth_prop 类型的文件，以及 sysfs 和 mnt_vendor_file 类型的文件。

规范分析：这是一个典型的权限扩展。当你需要通过 adb shell 或其他 shell 脚本访问特定文件时，必须显式地在 shell.te 中添加相应的 allow 规则。这里的 xxx_bluetooth_prop 显然是一个自定义类型，需要在 file_contexts 中进行定义和关联。

示例 2：定义和设置新的 property 属性

Diff

--- a/LINUX/android/device/qcom/sepolicy_vndr/generic/vendor/common/property.te+++ b/LA.VENDOR.12.2.r1/LINUX/android/device/qcom/sepolicy_vndr/generic/vendor/common/property.te@@ -80,6 +80,9 @@ vendor_internal_prop(vendor_sensors_prop);

vendor_restricted_prop(vendor_tee_listener_prop);

vendor_restricted_prop(vendor_km_strongbox_version_prop);

vendor_restricted_prop(vendor_display_prop);+vendor_restricted_prop(vendor_xxx_product_model_prop);+vendor_restricted_prop(vendor_xxx_snpcba_prop);+vendor_restricted_prop(vendor_xxxx_sn_prop);

vendor_internal_prop(vendor_usb_prop);

vendor_restricted_prop(vendor_radio_prop);

vendor_internal_prop(vendor_qteeconnector_opti_prop);

修改目的：为 xxx 相关的属性定义了新的类型，并将其声明为 vendor_restricted_prop。

规范分析：将自定义属性声明为 vendor_restricted_prop 是一种推荐做法。这意味着这些属性只能由特定的 vendor 进程读写，从而确保了属性的隔离和安全。

示例 3：在 init_shell.te 中授予属性读写权限

Diff

--- LINUX/android/device/qcom/sepolicy_vndr/generic/vendor/common/init_shell.te+++ LINUX/android/device/qcom/sepolicy_vndr/generic/vendor/common/init_shell.te@@ -122,6 +122,12 @@ get_prop(vendor_qti_init_shell, radio_control_prop)

set_prop(vendor_qti_init_shell, vendor_gpu_prop)

set_prop(vendor_qti_init_shell, vendor_sensors_prop)

set_prop(vendor_qti_init_shell, vendor_adsprpc_prop)+set_prop(vendor_qti_init_shell, vendor_xxx_product_model_prop)+get_prop(vendor_qti_init_shell, vendor_xxx_product_model_prop)+set_prop(vendor_qti_init_shell, vendor_xxx_snpcba_prop)+get_prop(vendor_qti_init_shell, vendor_xxx_snpcba_prop)+set_prop(vendor_qti_init_shell, vendor_xxx_sn_prop)+get_prop(vendor_qti_init_shell, vendor_emdoor_sn_prop)

修改目的：允许 vendor_qti_init_shell 进程读写新定义的 emdoor 属性。

规范分析：在 init 脚本中设置或获取属性是常见操作，因此需要在 init 进程对应的 SELinux 域中添加相应的权限。这里的 set_prop 和 get_prop 宏是标准的 SELinux 策略写法，用于简化对属性服务的访问规则定义。

示例 4：在 BoardConfig.mk 中规避命名空间检查

Diff

--- LINUX/android/device/qcom/neo/BoardConfig.mk+++ LINUX/android/device/qcom/neo/BoardConfig.mk@@ -117,7 +117,7 @@ BOARD_METADATAIMAGE_PARTITION_SIZE := 16777216

BOARD_DTBOIMG_PARTITION_SIZE := 0x1700000

BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE := ext4

BOARD_FLASH_BLOCK_SIZE := 131072 # (BOARD_KERNEL_PAGESIZE * 64)-+BUILD_BROKEN_VENDOR_PROPERTY_NAMESPACE := true # selinux name not to check

修改目的：由于你定义的属性 persist.xxx.* 不遵循标准的 vendor 属性命名规则（例如，必须以 vendor. 开头），这个标记用于暂时禁用策略编译器的严格检查。

规范分析：这种做法应该被视为临时解决方案，不推荐在长期项目中保留。标准的 vendor 属性应该以 vendor. 作为前缀，或者遵循 AOSP 规定的其他命名空间。使用这个标记虽然能解决编译问题，但可能会在未来的 Android 版本中遇到兼容性问题，并可能隐藏潜在的安全风险。

4、SELinux 最佳实践与注意事项

当你对 SELinux 策略进行修改时，应始终遵循以下原则：

4.1. 最小权限原则（Principle of Least Privilege）

只授予必要的权限：不要为了方便而使用过于宽泛的权限，例如 allow my_domain all_file_types:file *;。这会大大增加攻击面。

细化权限：精确到具体的操作。例如，如果只需要读取文件，就使用 read 和 getattr，而不是 read write。

4.2. neverallow 策略的应对

避免触发 neverallow：在编写新策略时，要先了解现有的 neverallow 规则，并确保你的 allow 规则不会与之冲突。例如，不要尝试让 untrusted_app 访问核心系统文件。

通过 IPC (Inter-Process Communication) 间接访问：如果一个进程需要访问被 neverallow 规则限制的资源，不要直接修改策略去绕过它。正确的做法是，让你的进程通过 Binder 或其他 IPC 机制，调用一个已经有权限的服务来完成这个操作。这是一种安全的设计模式。

4.3. 策略版本与兼容性

保持更新：SELinux 策略会随着 Android 版本不断演进，新的版本可能会引入新的 neverallow 规则或修改现有规则。当升级 Android 版本时，务必检查你的自定义策略是否仍然兼容。

vendor 和 system 策略隔离：在 Android 10 (Q) 及以后版本，Google 强制要求 vendor 策略和 system 策略必须严格隔离。这意味着 vendor 策略不能直接引用 system 策略中定义的类型。你提供的提交中，shell.te 和 vendor 策略都进行了修改，但它们是分开的，这符合隔离原则。

4. 4常见 AVC 错误解析

当 SELinux 拒绝你的访问时，它会在日志里留下一个详细的“案发现场报告”，也就是我们常说的 AVC（Access Vector Cache）报错。

以下是一些你可能会遇到的经典“案发现场”，以及我们的侦查和破案技巧。

AVC 错误示例 1：无法访问 /sys/ 下的属性文件

案发现场报告：

type=1400 audit(8445.739:50): avc: denied { write } for comm="init" name="brightness" dev="sysfs" ino=78557 scontext=u:r:init:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0

案情分析：

谁干的？ init 进程，身份是 init_t。

想干啥？ write（写入）brightness 文件。

被谁拦了？ SELinux 安检员。

为什么拦？ init_t 没有权限去 write 类型为 sysfs 的 file。

破案手法（解决方案）：在 init.te 文件中添加以下规则：

代码段

allow init sysfs:file { write };

AVC 错误示例 2：服务无法读取 sysfs 文件

案发现场报告：

type=1400 audit(8445.211:14): avc: denied { read } for comm="android.hardware" name="type" dev="sysfs" ino=81076 scontext=u:r:hal_health_default:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0

案情分析：

谁干的？ android.hardware 进程（可能是 HAL 服务），身份是 hal_health_default_t。

想干啥？ read（读取）type 文件。

被谁拦了？ SELinux 安检员。

为什么拦？ hal_health_default_t 没有权限去 read 类型为 sysfs 的 file。

破案手法（解决方案）： 在 system/sepolicy/vendor/hal_health_default.te 中添加以下规则：

代码段

allow hal_health_default sysfs:file { read };

AVC 错误示例 3：init 脚本无法写入 sysfs 文件

案发现场报告：

type=1400 audit(8440.707:12): avc: denied { write } for comm="sh" name="read_ahead_kb" dev="sysfs" ino=60930 scontext=u:r:vendor_qti_init_shell:s0 tcontext=u:object_r:sysfs:s0 tclass=file permissive=0

案情分析：

谁干的？ sh 进程（init 脚本），身份是 vendor_qti_init_shell_t。

想干啥？ write（写入）read_ahead_kb 文件。

被谁拦了？ SELinux 安检员。

为什么拦？ vendor_qti_init_shell_t 没有权限去 write 类型为 sysfs 的 file。

破案手法（解决方案）：在 vendor_qti_init_shell.te 中添加以下规则：

代码段

allow vendor_qti_init_shell sysfs:file { write };

5总结：