16、Android安全策略配置与优化指南

tree

于 2025-12-11 10:29:50 发布

阅读量7

点赞数

CC 4.0 BY-SA版权

分类专栏：深入探索Android的SE 文章标签： Android安全策略 SELinux sepolicy

本文链接：https://blog.youkuaiyun.com/tree/article/details/155830049

深入探索Android的SE 专栏收录该内容

17 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

Android安全策略配置与优化指南

在Android系统中，安全策略的配置对于保障系统的安全性和稳定性至关重要。本文将详细介绍一系列Android安全策略的配置和优化步骤，包括不同服务和应用的权限设置、文件标签处理以及策略的测试和实施。

1. 各服务和应用的策略配置

installd ：添加的domain.te规则用于处理installd。
keystore
- 规则： allow keystore app_data_file:file write; 和 allow keystore log_device:chr_file { write open };
- 问题处理：对于app_data_file的拒绝访问问题，由于MLS支持在应用域中被激活，可在设备特定的seapp_contexts文件中添加相关声明，如 user=_app domain=untrusted_app type=app_data_file 和 user=_app seinfo=platform domain=platform_app type=app_data_file 。在Android 4.3中，对数据上下文的更改需要进行工厂重置，而4.4版本增加了智能重新标记功能。
mediaserver
- 规则： allow mediaserver adbd:binder { transfer call }; 、 allow mediaserver init:binder { transfer call }; 和 allow mediaserver log_device:chr_file { write open };
- 处理方式：日志设备的问题已在domain.te规则中处理，由于init和adbd的问题是由不适当的进程域触发的，可跳过处理。重要的是不要盲目添加允许规则，大多数现有域的工作可以通过小的标签更改或少量规则来处理。
netd
- 规则： allow netd kernel:system module_request; 和 allow netd log_device:chr_file { write open };
- 处理方式：日志设备的拒绝访问问题已由domain.te处理。但在授予加载系统模块的能力时需要谨慎，因为如果域或模块二进制文件本身受到损害，可能会通过可加载模块将恶意软件注入内核。在设备UDOO的sepolicy的netd.te文件中添加 allow netd self:capability sys_module; 。
rild ：规则 allow rild log_device:chr_file { write open }; 已由domain.te规则处理，无需额外操作。
servicemanager
- 规则： allow servicemanager init:binder transfer; 和 allow servicemanager log_device:chr_file { write open };
- 处理方式：日志设备的问题已在domain.te中处理，由于init的问题是由不适当的进程域触发的，可跳过处理。
surfaceflinger
- 规则： allow surfaceflinger init:binder transfer; 和 allow surfaceflinger log_device:chr_file { write open };
- 处理方式：日志设备的问题已在domain.te中处理，由于init的问题是由不适当的进程域触发的，可跳过处理。
system_server
- 规则：包含多个规则，如 allow system_server adbd:binder { transfer call }; 等。
- 处理方式：仅处理Dalvik缓存的拒绝访问问题。在domain.te中添加 allow domain dalvikcache_data_file:file r_file_perms; ，在system_server.te中添加 allow system_server dalvikcache_data_file:file { write setattr }; 。
toolbox
- 规则： allow toolbox sysfs:file write;
- 处理方式：对于 /sys/module/usbtouchscreen/parameters/calibration 的写入拒绝问题，在file.te中添加 type sysfs_touchscreen_calibration, fs_type, sysfs_type, mlstrustedobject; ，在file_contexts中添加 /sys/module/usbtouchscreen/parameters/calibration—u:object_r:sysfs_touchscreen_calibration:s0 ，在toolbox.te中添加 allow toolbox sysfs_touchscreen_calibration:file w_file_perms; 。
untrusted_app
- 规则：包含多个规则，如 allow untrusted_app adb_device:chr_file getattr; 等。
- 处理方式：需要正确标记 /dev/.coldboot_done 、 /dev/rfkill 和 /dev/mxs_viim 。 /dev/rfkill 应按照4.3策略进行标记， /dev/mxs_viim 可暂时标记为gpu_device， /dev/.coldboot_done 无需标记，当从应用中删除MLS支持时，相关拒绝问题应会消失。
vold ：规则 allow vold log_device:chr_file { write open }; 已由domain.te规则处理，无需额外操作。
watchdogd
- 规则： allow watchdogd device:chr_file { read write create unlink open };
- 处理方式：在watchdogd.te中添加 allow watchdogd device:chr_file create_file_perms; 会导致基础策略中的neverallow规则违反，需要修改基础sepolicy中的neverallow规则为 neverallow { domain -init -ueventd -recovery -watchdogd } device:chr_file { open read write }; 。
wpa
- 规则： allow wpa device:chr_file { read open }; 、 allow wpa log_device:chr_file { write open }; 、 allow wpa system_data_file:dir { write remove_name add_name setattr }; 和 allow wpa system_data_file:sock_file { write create unlink setattr };
- 处理方式：日志设备的问题已在domain.te中处理。对于系统数据访问的拒绝问题，在wpa.te中添加 allow wpa system_data_file:dir rw_dir_perms; 和 allow wpa system_data_file:sock_file create_file_perms; 。

2. 第二次策略检查

在加载起草的策略后，设备在启动时仍有拒绝访问的情况：
- init
- 原始拒绝信息： <5>type=1400 audit(4.380:3): avc: denied { create } for pid=2268 comm="init" name="tasks" scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file 和 <5>type=1400 audit(4.380:4): avc: denied { write } for pid=2268 comm="init" name="tasks" dev=rootfs ino=3080 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file
- 处理方式：这些问题发生在init将 / 重新挂载为只读之前，可以安全地允许这些操作。在init.te中添加 allow int rootfs:file create_file_perms; ，但这会导致另一个neverallow规则失败，需要修改external/sepolicy domain.te中的neverallow规则为 neverallow { domain -recovery -init } rootfs:file { create write setattr relabelto append unlink link rename }; 。同时，对于 execute_no_trans 拒绝问题，需要将magd和rfkill重新标记为自己的类型，并将它们放在自己的无限制域中。
- 创建magd.te文件，添加以下内容：

type magd, domain;
type magd_exec, exec_type, file_type;
permissive_or_unconfined(magd);

    - 更新file_contexts：`/system/bin/magd  u:object_r:magd_exec:s0`
    - 对rfkill进行类似操作，并在rfkill.te文件中添加 `domain_auto_trans(init_shell, rfkill_exec, rfkill)`，同时处理rfkill对 `/dev/rfkill` 的访问问题，在device.te中添加 `type rfkill_device, dev_type;`，在file_contexts中添加 `/dev/rfkill u:object_r:rfkill_device:s0`，在rfkill.te中添加 `allow rfkill rfkill_device:chr_file rw_file_perms;`。

shell
- 入口点拒绝问题： <5>type=1400 audit(4.460:5): avc: denied { entrypoint } for pid=2279 comm="init" path="/system/bin/mksh" dev=mmcblk0p5 ino=154 scontext=u:r:shell:s0 tcontext=u:object_r:system_file:s0 tclass=file
- 处理方式：创建init_shell.te文件，添加以下内容：

type init_shell, domain;
domain_auto_trans(init, shell_exec, init_shell);
permissive_or_unconfined(init_shell);

- 更新file_contexts：`/system/bin/mksh  u:object_r:shell_exec:s0;`
- 设备访问拒绝问题：`<5>type=1400 audit(6.510:7): avc: denied { read write } for pid=2279 comm="sh" name="ttymxc1" dev=tmpfs ino=122 scontext=u:r:shell:s0 tcontext=u:object_r:device:s0 tclass=chr_file` 和 `<5>type=1400 audit(7.339:8): avc: denied { getattr } for pid=2279 comm="sh" path="/dev/ttymxc1" dev=tmpfs ino=122 scontext=u:r:shell:s0 tcontext=u:object_r:device:s0 tclass=chr_file`
- 处理方式：将这些设备标记为tty_device，在文件上下文中添加 `/dev/ttymxc[0-9]*  u:object_r:tty_device:s0`。

3. 测试与实施

现场试验 ：重建源代码树，擦除数据文件系统，进行刷机并重新运行CTS测试，重复此过程直到所有拒绝访问问题都得到解决。完成CTS和内部QA测试后，建议在设备处于宽松模式下进行现场试验，在此期间收集日志并优化策略。如果域不稳定，可以在策略文件中将其声明为宽松模式，同时仍将设备置于强制模式，部分域的强制实施总比不实施要好。
进入强制模式 ：可以通过引导加载程序（此处不介绍）或在启动时的init.rc脚本中设置强制模式。在 setcon u:r:init:s0 之后添加 setenforce 1 。一旦此语句编译到init.rc脚本中，只能通过后续构建和重新刷入boot.img来撤销。可以通过运行 getenforce 命令来检查强制模式状态。

通过以上步骤，可以逐步优化Android系统的安全策略，提高系统的安全性和稳定性。在配置过程中，需要仔细处理每个服务和应用的权限设置，避免盲目添加规则，同时注意处理可能出现的neverallow规则违反问题。

Android安全策略配置与优化指南

4. 策略配置流程总结

为了更清晰地展示整个Android安全策略配置的过程，我们可以将其总结为以下流程图：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
    classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;

    A([开始]):::startend --> B(各服务和应用策略配置):::process
    B --> C{是否有拒绝访问情况}:::decision
    C -->|是| D(第二次策略检查):::process
    C -->|否| E(现场试验):::process
    D --> E
    E --> F{所有拒绝问题解决?}:::decision
    F -->|否| B
    F -->|是| G(进入强制模式):::process
    G --> H([结束]):::startend

这个流程图展示了从开始配置各服务和应用的策略，到检查是否有拒绝访问情况，再到进行现场试验和最终进入强制模式的整个过程。如果在现场试验中发现仍有拒绝问题，需要回到策略配置阶段继续优化。

5. 关键规则和文件修改总结

为了方便查阅和管理，我们将前面提到的关键规则和文件修改进行总结，如下表所示：
| 服务/应用 | 规则添加或修改 | 文件修改 |
| — | — | — |
| keystore | user=_app domain=untrusted_app type=app_data_file
user=_app seinfo=platform domain=platform_app type=app_data_file | seapp_contexts |
| netd | allow netd self:capability sys_module; | netd.te |
| system_server | allow domain dalvikcache_data_file:file r_file_perms;
allow system_server dalvikcache_data_file:file { write setattr }; | domain.te, system_server.te |
| toolbox | type sysfs_touchscreen_calibration, fs_type, sysfs_type, mlstrustedobject;
/sys/module/usbtouchscreen/parameters/calibration—u:object_r:sysfs_touchscreen_calibration:s0
allow toolbox sysfs_touchscreen_calibration:file w_file_perms; | file.te, file_contexts, toolbox.te |
| untrusted_app | 正确标记 /dev/.coldboot_done 、 /dev/rfkill 和 /dev/mxs_viim | file_contexts |
| watchdogd | neverallow { domain -init -ueventd -recovery -watchdogd } device:chr_file { open read write }; | 基础sepolicy |
| wpa | allow wpa system_data_file:dir rw_dir_perms;
allow wpa system_data_file:sock_file create_file_perms; | wpa.te |
| init | allow int rootfs:file create_file_perms;
neverallow { domain -recovery -init } rootfs:file { create write setattr relabelto append unlink link rename };
创建magd.te和rfkill.te文件并添加相关内容
更新file_contexts | init.te, external/sepolicy domain.te, magd.te, rfkill.te, file_contexts |
| shell | 创建init_shell.te文件并添加相关内容
更新file_contexts
/dev/ttymxc[0-9]* u:object_r:tty_device:s0 | init_shell.te, file_contexts |

6. 注意事项和建议

避免盲目添加规则 ：在配置安全策略时，要仔细分析每个拒绝访问问题的原因，避免盲目添加允许规则。大多数情况下，通过小的标签更改或少量规则就可以解决问题。
处理neverallow规则 ：当遇到neverallow规则违反的情况时，需要谨慎处理。修改neverallow规则可能会导致CTS测试失败，因此最好的方法是从根本上解决导致问题的行为。
持续优化 ：安全策略的配置是一个持续的过程，需要不断进行现场试验和日志收集，根据实际情况对策略进行优化。

7. 总结

通过对Android系统中各服务和应用的安全策略进行详细配置和优化，我们可以有效提高系统的安全性和稳定性。整个过程包括各服务和应用的策略配置、第二次策略检查、现场试验和进入强制模式等步骤。在配置过程中，需要注意避免盲目添加规则，正确处理neverallow规则违反问题，并持续进行优化。通过遵循这些步骤和建议，可以确保Android系统的安全策略能够适应不同的应用场景和安全需求。

总之，Android安全策略的配置是一个复杂但重要的任务，需要我们认真对待每一个细节，不断学习和实践，以保障系统的安全运行。