14、Android安全策略构建与管理全解析

Android安全策略构建与管理全解析

1. 策略构建控制

在构建Android安全策略时， sepolicy 语句会调用 build_policy 函数，此函数在 Android.mk 文件中用于构建 sepolicy 、 file_contexts 、 seapp_contexts 、 property_contexts 和 mac_permissions.xml ，十分关键。该函数会输出策略文件的完整解析路径列表，其输入为可变参数的文件名列表，还支持正则表达式。

1.1 构建策略时可设置的变量

在设备的 Makefile 中，可设置以下 make 变量来控制策略构建：
| 变量名 | 作用 |
| ---- | ---- |
| BOARD_SEPOLICY_DIRS | 潜在策略文件的搜索路径 |
| BOARD_SEPOLICY_UNION | 要追加到同名所有文件的策略文件名 |
| BOARD_SEPOLICY_REPLACE | 用于覆盖基础 external/sepolicy 策略文件的策略文件 |
| BOARD_SEPOLICY_IGNORE | 根据仓库相对路径，从构建中移除特定策略文件 |

1.2 以UDOO为例的策略编写步骤

1. 创建目录：

$ mkdir <PATH>

2. 修改 BoardConfig.mk ：

$ vim BoardConfig.mk

3. 添加搜索路径：

BOARD_SEPOLICY_DIRS += device/fsl/udoo/sepolicy

这里要注意使用 += 而非 := ，避免覆盖上级设置。

4. 创建并移动 file_contexts 文件：在 device/fsl/udoo/sepolicy 目录下创建新的 file_contexts 文件，并将标签更改移动到该目录。
5. 合并文件：在 BoardConfig.mk 中添加以下语句，将自定义的 file_contexts 文件与 external/sepolicy 中的文件合并：

BOARD_SEPOLICY_UNION += file_contexts

同样，也可对其他策略文件甚至自定义文件进行此操作，例如添加 watchdog.te 和 custom.te ：

BOARD_SEPOLICY_UNION += file_contexts watchdog.te custom.te

6. 覆盖文件：若要覆盖 external/sepolicy 中的 watchdog.te 文件，可在 BoardConfig.mk 中添加：

BOARD_SEPOLICY_REPLACE := watchdog.te

需注意，不能替换基础策略中不存在的文件，且同一文件不能同时出现在 UNION 和 REPLACE 中。

1.3 设备层次构建示例

假设有两个虚拟设备 X 和 Y ，都从设备 A 继承 BoardConfigCommon.mk 。各设备的配置如下：
- 设备 A 的 BoardConfigCommon.mk ：

BOARD_SEPOLICY_DIRS += device/OEM/A
BOARD_SEPOLICY_UNION += file_contexts custom.te

• 设备 X 的 BoardConfig.mk ：

BOARD_SEPOLICY_DIRS += device/OEM/X
BOARD_SEPOLICY_UNION += file_contexts custom.te

• 设备 Y 的 BoardConfig.mk ：

BOARD_SEPOLICY_DIRS += device/OEM/Y
BOARD_SEPOLICY_UNION += file_contexts custom.te

构建设备 X 和 Y 时的策略集如下：
- 设备 X 策略集：
- device/OEM/A/file_contexts
- device/OEM/A/custom.te
- device/OEM/X/file_contexts
- device/OEM/X/custome.te
- external/sepolicy/* （基础策略文件）
- 设备 Y 策略集：
- device/OEM/A/file_contexts
- device/OEM/A/custom.te
- device/OEM/Y/file_contexts
- device/OEM/Y/custom.te
- external/sepolicy/* （基础策略文件）

若不想让设备 Y 的策略集包含 device/OEM/A/custom.te ，可在设备 Y 的 BoardConfig.mk 中添加：

BOARD_SEPOLICY_IGNORE += device/OEM/A/custom.te

BOARD_SEPOLICY_IGNORE 还可与 BOARD_SEPOLICY_REPLACE 一起使用，但同一策略文件只能有一个 BOARD_SEPOLICY_REPLACE 语句生效。

1.4 build_policy 函数深入剖析

sepolicy_replace_paths 变量在 Makefile 评估时被无条件执行。其代码会检查 BOARD_SEPOLICY_REPLACE 中的文件是否也在 BOARD_SEPOLICY_UNION 中，若存在则报错；然后根据 BOARD_SEPOLICY_DIRS 扩展路径，过滤掉 BOARD_SEPOLICY_IGNORE 中的文件，确保只有一个替换文件候选，且该文件存在于 LOCAL_PATH 或基础策略中。代码如下：

sepolicy_replace_paths :=
$(foreach pf, $(BOARD_SEPOLICY_REPLACE), \
  $(if $(filter $(pf), $(BOARD_SEPOLICY_UNION)), \
    $(error Ambiguous request for sepolicy $(pf). Appears in both \
      BOARD_SEPOLICY_REPLACE and BOARD_SEPOLICY_UNION), \
  ) \
  $(eval _paths := $(filter-out $(BOARD_SEPOLICY_IGNORE), \
  $(wildcard $(addsuffix /$(pf), $(BOARD_SEPOLICY_DIRS))))) \
  $(eval _occurrences := $(words $(_paths))) \
  $(if $(filter 0,$(_occurrences)), \
    $(error No sepolicy file found for $(pf) in $(BOARD_SEPOLICY_DIRS)), \
  ) \
  $(if $(filter 1, $(_occurrences)), \
    $(eval sepolicy_replace_paths += $(_paths)), \
    $(error Multiple occurrences of replace file $(pf) in $(_paths)) \
  ) \
  $(if $(filter 0, $(words $(wildcard $(addsuffix /$(pf), 
$(LOCAL_PATH))))), \
    $(error Specified the sepolicy file $(pf) in BOARD_SEPOLICY_REPLACE, \
      but none found in $(LOCAL_PATH)), \
  ) \
)

build_policy 函数的参数是要扩展为 Android 根相对路径名的文件名。该函数会遍历所有传入的文件，分别针对 BOARD_SEPOLICY_DIRS 进行替换和合并操作，检查 sepolicy_replace_paths 避免文件同时出现在替换和合并位置，最后过滤掉 BOARD_SEPOLICY_IGNORE 中的路径。代码如下：

# Builds paths for all requested policy files w.r.t
# both BOARD_SEPOLICY_REPLACE and BOARD_SEPOLICY_UNION
# product variables.
# $(1): the set of policy name paths to build
build_policy = $(foreach type, $(1), \
  $(filter-out $(BOARD_SEPOLICY_IGNORE), \
    $(foreach expanded_type, $(notdir $(wildcard $(addsuffix /$(type), 
$(LOCAL_PATH)))), \
      $(if $(filter $(expanded_type), $(BOARD_SEPOLICY_REPLACE)), \
        $(wildcard $(addsuffix $(expanded_type), $(sort $(dir 
$(sepolicy_replace_paths))))), \
        $(LOCAL_PATH)/$(expanded_type) \
      ) \
    ) \
    $(foreach union_policy, $(wildcard $(addsuffix /$(type), 
$(BOARD_SEPOLICY_DIRS))), \
      $(if $(filter $(notdir $(union_policy)), $(BOARD_SEPOLICY_UNION)), \
        $(union_policy), \
      ) \
    ) \
  ) \
)

1.5 策略构建流程示意图

graph TD;
    A[输入文件名] --> B[遍历文件];
    B --> C[针对BOARD_SEPOLICY_DIRS扩展路径];
    C --> D[替换操作];
    C --> E[合并操作];
    D --> F[检查sepolicy_replace_paths];
    E --> F;
    F --> G[过滤BOARD_SEPOLICY_IGNORE];
    G --> H[输出路径列表];

2. 各文件构建过程

2.1 mac_permissions.xml 构建

mac_permissions.xml 构建较为复杂。它可使用所有 BOARD_SEPOLICY_* 变量，最终生成一个符合这些变量规则的 XML 文件。原始 XML 文件由 sepolicy/tools 中的 insertkeys.py 工具处理，该工具使用 keys.conf 将 XML 文件签名节中的标签与包含证书的 .pem 文件映射。构建过程如下：
1. 调用 build_policy 处理 keys.conf ，使用 m4 拼接结果，尊重 keys.conf 中的 m4 声明。
2. 将 m4 扩展后的 keys.conf 文件和 build_policy() 调用得到的所有 mac_permissions.xml 文件输入到 insertkeys.py 。
3. insertkeys.py 使用 keys.conf 将所有匹配的 signature=<TAG> 行替换为 .pem 文件中的十六进制编码 X509，合并 XML 文件，去除空格和注释以减小文件大小。此构建与 sepolicy 、 seapp_contexts 、 property_contexts 等主要文件无依赖关系。

2.2 seapp_contexts 构建

seapp_contexts 文件也受所有 BOARD_SEPOLICY_* 变量影响。构建过程如下：
1. 将 build_policy() 调用得到的所有 seapp_contexts 文件通过 m4 -s 处理，生成包含同步行的单个 seapp_contexts 文件。
2. 将该文件输入到 check_seapp 工具，该工具用 C 语言编写，在构建时编译为可执行文件，源文件位于 tools/check_seapp 。 check_seapp 会检查文件语法，验证键值对是否有效， levelFrom 是否为有效标识符，以及 type 和 domain 字段是否符合给定的 sepolicy 。此构建依赖于 sepolicy 进行严格的类型检查。

2.3 file_contexts 构建

file_contexts 文件同样受所有 BOARD_SEPOLICY_* 变量控制。构建过程如下：
1. 将结果集通过 m4 -s 处理。
2. 将单个输出文件输入到 checkfc 工具，该工具检查文件语法和语法，验证类型是否存在于构建的 sepolicy 中，因此依赖于 sepolicy 构建。

2.4 property_contexts 构建

property_contexts 构建过程与 file_contexts 类似，只是检查的是 property_contexts 文件，同样使用 checkfc 工具。

2.5 各文件构建依赖关系表格

文件	依赖文件	处理工具
mac_permissions.xml	无	insertkeys.py
seapp_contexts	sepolicy	check_seapp
file_contexts	sepolicy	checkfc
property_contexts	sepolicy	checkfc

3. NSA 研究文件及独立工具

3.1 NSA 研究文件

NSA 正在进行企业运营（eops）相关工作，但该功能尚未合并到主流 Android 中，且可能会有较大变化，因此暂不介绍。 selinux-network.sh 也属于此类，尚未被主流采用，可能会从 AOSP 中移除。

3.2 独立工具

有一些用于 Android 策略评估的独立工具，若运行这些工具出现段错误，可能需要应用 此线程 中的补丁。

3.2.1 sepolicy-check

该工具用于检查策略文件中是否存在给定的允许规则，基本语法如下：

sepolicy-check -s <domain> -t <type> -c <class> -p <permission> -P <policy_file>

例如，检查 system_app 是否可以对 system_data_file 类的文件进行写操作：

$ sepolicy-check -s system_app -t system_data_file -c file -p write -P $OUT/root/sepolicy

3.2.2 sepolicy-analyze

该工具可检查 SELinux 开发中的常见问题，捕捉新 SELinux 策略编写者的常见陷阱，可进行以下检查：
- 域等价检查 ：显示理论上应不同但在实现中收敛的域，这些域可能需要合并，但也可能表示策略设计存在问题。调用命令如下：

$ sepolicy-analyze -e -P $OUT/root/sepolicy

• 重复允许规则检查 ：检查特定类型上的允许规则是否也存在于该类型继承的属性上，特定类型上的允许规则可考虑移除。执行命令如下：

$ sepolicy-analyze -D -P $OUT/root/sepolicy

• 策略类型差异检查 ：查看文件内的类型差异，有助于识别可能合并的域。执行命令如下：

$ sepolicy-analyze -d -P $OUT/root/sepolicy

4. 进入强制模式及 SEPolicy 主版本更新

4.1 进入强制模式步骤

作为工程师，要对 Android 设备应用 SE for Android 控制以增强安全态势，可按以下步骤让 UDOO 进入强制模式：
1. 运行、评估和响应 CTS 的审计日志。
2. 为 UDOO 开发安全策略。
3. 切换到强制模式。

4.2 SEPolicy 主版本更新

自 4.3 版本发布以来，AOSP 主分支的 sepolicy 目录有很多变化。当前主分支的 external/sepolicy 项目处于 Git 提交 SHA b5ffb 。建议使用最新提交，若要精确遵循示例，可按以下步骤操作：
1. 克隆 external/sepolicy 项目：

$ git clone https://android.googlesource.com/platform/external/sepolicy
$ cd sepolicy

2. 切换到指定提交：

$ git checkout b5ffb

3. 替换 UDOO 4.3 的 sepolicy ：

$ cd ..
$ rm -rf udoo/external/sepolicy
$ cp -r sepolicy udoo/external/sepolicy

4. 可选操作：移除新复制的 sepolicy 中的 .git 文件夹：

$ rm –rf udoo/external/sepolicy/.git

5. 复制并恢复 audit.te 文件。
6. 从 NSA Bitbucket seandroid 仓库恢复 auditd 提交（提交 SHA 为 d270aa3 ）。
7. 从 udoo/build/core/Makefile 中移除所有对 setool 的引用，可使用以下命令定位：

$ grep -nw setool udoo/build/core/Makefile

4.3 SEPolicy 更新流程示意图

graph TD;
    A[克隆项目] --> B[切换提交];
    B --> C[替换sepolicy];
    C --> D[可选：移除.git文件夹];
    D --> E[复制并恢复audit.te];
    E --> F[恢复auditd提交];
    F --> G[移除setool引用];

通过以上操作，可有效控制 Android 设备的安全策略构建和管理，确保设备的安全性和稳定性。同时，利用独立工具可对策略进行有效评估和优化。

5. 策略构建与管理的综合应用案例

5.1 多设备定制策略构建案例

假设一家公司有多种不同型号的 Android 设备，分别为 Device A、Device B 和 Device C。每种设备有其独特的功能和安全需求，因此需要定制不同的安全策略。

5.1.1 基础配置

首先，所有设备都有一个公共的基础策略配置，存储在 external/sepolicy 目录中。同时，为每个设备创建独立的策略目录：

$ mkdir device/company/deviceA/sepolicy
$ mkdir device/company/deviceB/sepolicy
$ mkdir device/company/deviceC/sepolicy

5.1.2 设备 A 的策略配置

设备 A 有特殊的蓝牙功能，需要添加特定的策略规则。在 device/company/deviceA/BoardConfig.mk 中进行如下配置：

BOARD_SEPOLICY_DIRS += device/company/deviceA/sepolicy
BOARD_SEPOLICY_UNION += bluetooth.te

在 device/company/deviceA/sepolicy 目录下创建 bluetooth.te 文件，添加蓝牙相关的策略规则。

5.1.3 设备 B 的策略配置

设备 B 对文件访问有更严格的限制，需要覆盖基础策略中的某些规则。在 device/company/deviceB/BoardConfig.mk 中进行如下配置：

BOARD_SEPOLICY_DIRS += device/company/deviceB/sepolicy
BOARD_SEPOLICY_REPLACE := file_access.te

在 device/company/deviceB/sepolicy 目录下创建 file_access.te 文件，编写覆盖基础策略的规则。

5.1.4 设备 C 的策略配置

设备 C 不需要基础策略中的某些规则，需要忽略这些规则。在 device/company/deviceC/BoardConfig.mk 中进行如下配置：

BOARD_SEPOLICY_DIRS += device/company/deviceC/sepolicy
BOARD_SEPOLICY_IGNORE += unnecessary_rule.te

5.1.5 综合构建流程

通过以上配置，在构建每个设备的策略时， build_policy 函数会根据 BOARD_SEPOLICY_* 变量的设置，自动合并、替换或忽略相应的策略文件，生成适合每个设备的安全策略。

5.2 策略更新与维护案例

随着业务的发展和安全需求的变化，需要对设备的安全策略进行更新和维护。以下是一个更新策略的案例：

5.2.1 需求分析

发现基础策略中的某个规则存在安全漏洞，需要更新该规则。同时，新的设备功能需要添加新的策略规则。

5.2.2 更新基础策略

首先，更新 external/sepolicy 目录中的相关策略文件。然后，对于需要覆盖该规则的设备，在其 BoardConfig.mk 文件中更新 BOARD_SEPOLICY_REPLACE 变量：

BOARD_SEPOLICY_REPLACE := updated_rule.te

5.2.3 添加新规则

对于需要添加新规则的设备，在其策略目录下创建新的策略文件，并在 BoardConfig.mk 文件中更新 BOARD_SEPOLICY_UNION 变量：

BOARD_SEPOLICY_UNION += new_feature.te

5.2.4 测试与验证

更新策略后，使用 sepolicy-check 和 sepolicy-analyze 工具对策略进行测试和验证，确保新的策略符合安全需求，且没有引入新的问题。

5.3 策略构建与管理的最佳实践

5.3.1 模块化设计

将策略文件按照功能模块进行划分，例如将蓝牙、文件访问、网络等功能的策略分别存储在不同的文件中。这样可以提高策略的可维护性和可扩展性。

5.3.2 版本控制

使用版本控制系统（如 Git）对策略文件进行管理，记录每次更新的内容和时间，方便回溯和比较不同版本的策略。

5.3.3 定期审查

定期对策略进行审查，检查是否存在过时的规则或安全漏洞。根据业务需求和安全标准的变化，及时更新策略。

5.3.4 自动化构建

使用自动化构建工具（如 Make）对策略进行构建，确保每次构建的一致性和准确性。同时，可以结合持续集成/持续部署（CI/CD）流程，实现策略的自动更新和部署。

6. 总结与展望

6.1 总结

本文详细介绍了 Android 安全策略的构建和管理过程，包括策略构建控制、各文件的构建过程、NSA 研究文件及独立工具的使用，以及进入强制模式和 SEPolicy 主版本更新的步骤。通过合理使用 BOARD_SEPOLICY_* 变量，可以灵活定制不同设备的安全策略，满足多样化的安全需求。同时，利用独立工具可以对策略进行有效的评估和优化，确保策略的安全性和稳定性。

6.2 展望

随着 Android 系统的不断发展和安全威胁的日益复杂，安全策略的构建和管理将面临更多的挑战和机遇。未来，可能会出现以下发展趋势：

6.2.1 智能化策略管理

引入人工智能和机器学习技术，实现对安全策略的智能化管理。例如，通过分析大量的安全日志和攻击数据，自动生成和调整安全策略，提高策略的准确性和有效性。

6.2.2 跨平台策略集成

随着 Android 设备与其他平台（如物联网设备、云计算平台）的互联互通日益频繁，需要实现跨平台的安全策略集成。例如，确保 Android 设备与物联网设备之间的通信安全，以及在云计算环境中对 Android 应用的安全管理。

6.2.3 安全策略标准化

制定统一的安全策略标准和规范，促进不同厂商和开发者之间的策略互操作性和兼容性。这样可以降低安全策略的开发和维护成本，提高整个 Android 生态系统的安全性。

通过不断关注和研究这些发展趋势，我们可以更好地应对未来的安全挑战，保障 Android 设备和应用的安全运行。