16、Android安全策略配置与实施指南

Android安全策略配置与实施指南

在Android系统中，安全策略的配置和实施对于保障系统的安全性和稳定性至关重要。下面将详细介绍不同组件的安全策略配置及相关问题的解决方法。

1. 各组件安全策略配置

1. installd ：添加的domain.te规则用于处理installd。
2. keystore
   • 规则： allow keystore app_data_file:file write; 和 allow keystore log_device:chr_file { write open };
   • 问题处理：日志设备由domain.te规则处理。对于app_data_file的拒绝访问问题，发现MLS支持在应用域中被激活。由于MLS对应用数据的分离在4.3版本中不起作用，可在设备特定的seapp_contexts文件中声明 user=_app domain=untrusted_app type=app_data_file 和 user=_app seinfo=platform domain=platform_app type=app_data_file 来禁用。在4.3版本中，对数据上下文的任何更改都需要恢复出厂设置，而4.4版本增加了智能重新标记功能。
3. 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的问题，因为它们是由不正确的进程域触发的。重要的是不要盲目添加允许规则，大多数现有域的工作可以通过小的标签更改或少量规则来处理。
4. netd
   • 规则： allow netd kernel:system module_request; 和 allow netd log_device:chr_file { write open };
   • 问题处理：日志设备拒绝访问问题由domain.te解决。在授予netd加载系统模块的能力时要非常小心，因为如果该域或模块二进制文件本身被破坏，可能会通过可加载模块将恶意软件注入内核。但netd需要可加载内核模块支持来支持某些卡，可在设备UDOO sepolicy的netd.te文件中添加 allow netd self:capability sys_module; 。
5. rild ：规则 allow rild log_device:chr_file { write open }; 由domain.te规则处理，无需额外操作。
6. servicemanager
   • 规则： allow servicemanager init:binder transfer; 和 allow servicemanager log_device:chr_file { write open };
   • 问题处理：日志设备问题在domain.te中已处理，跳过init的问题，因为其问题是由不正确的进程域触发的。
7. surfaceflinger
   • 规则： allow surfaceflinger init:binder transfer; 和 allow surfaceflinger log_device:chr_file { write open };
   • 问题处理：日志设备问题在domain.te中已处理，跳过init的问题，因为其问题是由不正确的进程域触发的。
8. system_server
   • 规则：包含 allow system_server adbd:binder { transfer call }; 等多个规则。
   • 问题处理：日志设备由domain.te处理，init和adbd有问题，仅处理Dalvik缓存拒绝访问问题。在domain.te中添加 allow domain dalvikcache_data_file:file r_file_perms; ，在system_server.te中添加 allow system_server dalvikcache_data_file:file { write setattr }; 。
9. toolbox
   • 规则： allow toolbox sysfs:file write;
   • 问题处理：通常不应该向sysfs写入数据。对于 /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; 。
10. untrusted_app
    • 规则：有多个规则，如 allow untrusted_app adb_device:chr_file getattr; 等。
    • 问题处理：untrusted_app有很多拒绝访问问题，考虑到域标签问题，暂不处理大部分问题，但要注意错误标记和未标记的目标文件。对于chr_file设备的拒绝访问问题，需要正确标记 /dev/.coldboot_done 、 /dev/rfkill 和 /dev/mxs_viim 。 /dev/rfkill 应按照4.3策略进行标记， /dev/mxs_viim 可标记为gpu_device， /dev/.coldboot_done 无需标记，当从应用中移除MLS支持时，该拒绝访问问题应会消失。
11. vold ：规则 allow vold log_device:chr_file { write open }; 由domain.te规则处理。
12. watchdogd
    • 规则： allow watchdogd device:chr_file { read write create unlink open };
    • 问题处理：添加规则 allow watchdogd device:chr_file create_file_perms; 会导致基础策略中的neverallow规则违反。需要修改基础sepolicy，将 neverallow { domain -init -ueventd -recovery } device:chr_file { open read write }; 改为 neverallow { domain -init -ueventd -recovery -watchdogd } device:chr_file { open read write }; 。
13. wpa
    • 规则：包含 allow wpa device:chr_file { read open }; 等多个规则。
    • 问题处理：日志设备由domain.te处理，系统数据访问需要进一步调查。对于系统数据文件的拒绝访问问题，在wpa.te中添加 allow wpa system_data_file:dir rw_dir_perms; 和 allow wpa system_data_file:sock_file create_file_perms; 。

2. 第二遍策略检查

加载起草的策略后，设备在启动时仍有拒绝访问问题：
1. 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 init rootfs:file create_file_perms; ，但这会导致另一个neverallow规则失败，需要修改external/sepolicy domain.te，将 neverallow { domain -recovery} rootfs:file { create write setattr relabelto append unlink link rename }; 改为 neverallow { domain -recovery -init } rootfs:file { create write setattr relabelto append unlink link rename }; 。同时，对于 execute_no_trans 拒绝访问问题，需要为 /system/bin/magd 和 /system/bin/rfkill 创建各自的域和执行类型，并在相应的文件中添加规则。
2. 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，添加到BOARD_SEPOLICY_UNION中，内容如下：

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;`。对于shell对原始设备的访问拒绝问题，将 `/dev/ttymxc[0-9]*` 标记为tty_device，在文件上下文中添加 `/dev/ttymxc[0-9]*  u:object_r:tty_device:s0`。

3. 测试与实施

1. 现场试验
   • 步骤：
     • 重建源代码树。
     • 擦除数据文件系统。
     • 刷机。
     • 重新运行CTS，重复此过程直到所有拒绝访问问题都得到解决。
   • 建议：完成CTS和内部QA测试后，以宽松模式对设备进行现场试验。在此期间，收集日志并完善策略。如果域不稳定，可以在策略文件中将其声明为宽松模式，同时将设备置于强制模式，因为强制部分域总比不强制要好。
2. 进入强制模式
   • 方法：可以在启动时通过init.rc脚本设置强制模式，在 setcon u:r:init:s0 之后添加 setenforce 1 。编译到init.rc脚本后，只能通过后续构建和重新刷入boot.img来撤销。可以通过运行 getenforce 命令检查，也可以尝试从根串口控制台运行 reboot 命令来测试。

各组件安全策略配置流程图

graph TD;
    A[installd] --> B[keystore];
    B --> C[mediaserver];
    C --> D[netd];
    D --> E[rild];
    E --> F[servicemanager];
    F --> G[surfaceflinger];
    G --> H[system_server];
    H --> I[toolbox];
    I --> J[untrusted_app];
    J --> K[vold];
    K --> L[watchdogd];
    L --> M[wpa];
    M --> N[init];
    N --> O[shell];
    O --> P[现场试验];
    P --> Q[进入强制模式];

通过以上步骤和方法，可以有效地配置和实施Android系统的安全策略，提高系统的安全性和稳定性。在实际操作中，要谨慎处理每个步骤，确保策略的正确性和有效性。

Android安全策略配置与实施指南（续）

4. 关键组件问题深入分析

在上述各组件安全策略配置和第二遍策略检查过程中，涉及到的部分关键组件问题还需要进一步深入分析。

4.1 init组件的特殊情况

init组件在系统启动过程中起着核心作用，其安全策略配置不当可能会引发严重的安全问题。在处理init对rootfs的写和创建操作时，虽然可以通过修改neverallow规则来暂时解决问题，但需要注意的是，这种修改可能会导致CTS（Compatibility Test Suite）测试失败。正确的做法应该是从init组件本身的行为入手，尝试去除其不必要的写操作。

对于init执行无域转换的执行文件（execute_no_trans）问题，为 /system/bin/magd 和 /system/bin/rfkill 创建各自的域和执行类型是一个有效的解决办法。具体操作步骤如下：
1. 为magd创建规则
- 创建一个名为magd.te的文件，并将其添加到BOARD_SEPOLICY_UNION中。
- 在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`。

2. 为rfkill创建规则
   • 同样创建一个名为rfkill.te的文件，添加到BOARD_SEPOLICY_UNION中。
   • 在rfkill.te文件中添加类似magd.te的内容，将magd替换为rfkill。
   • 由于发现rfkill是从init_shell域使用exec加载的，还需要在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; 。

4.2 shell组件的权限控制

shell组件在系统中提供了用户与系统交互的接口，其权限控制也至关重要。对于shell的入口点拒绝访问问题，通过创建init_shell域来解决。具体步骤如下：
1. 创建init_shell.te文件，添加到BOARD_SEPOLICY_UNION中，内容如下：

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

2. 在file_contexts文件中添加 /system/bin/mksh u:object_r:shell_exec:s0; 。

对于shell对原始设备的访问拒绝问题，将 /dev/ttymxc[0-9]* 标记为tty_device，在文件上下文中添加 /dev/ttymxc[0-9]* u:object_r:tty_device:s0 ，这样可以确保shell对特定设备的访问权限得到正确控制。

5. 策略调整与优化的注意事项

在整个Android安全策略配置和实施过程中，进行策略调整和优化时需要遵循以下注意事项：

5.1 谨慎使用允许规则

在添加允许规则时，不能盲目进行。大多数情况下，通过小的标签更改或少量规则就可以解决问题。例如，在处理mediaserver、servicemanager、surfaceflinger等组件时，对于init和adbd相关的问题，由于是由不正确的进程域触发的，所以不应盲目添加允许规则，而应先检查进程域的配置。

5.2 处理neverallow规则

当遇到neverallow规则限制时，需要谨慎处理。如果直接修改neverallow规则，可能会带来安全风险，并且如前文所述，可能会导致CTS测试失败。因此，在修改neverallow规则之前，应尽量从组件本身的行为出发，尝试通过其他方式解决问题。例如，在处理init对rootfs的写操作时，优先考虑去除init不必要的写行为，而不是简单地修改neverallow规则。

5.3 关注MLS支持

MLS（Multi-Level Security）支持在应用域中的激活可能会导致一些拒绝访问问题。在4.3版本中，MLS对应用数据的分离功能可能无法正常工作，此时可以通过在设备特定的seapp_contexts文件中声明相关规则来禁用MLS支持。但需要注意的是，在4.3版本中对数据上下文的更改需要恢复出厂设置，而4.4版本增加了智能重新标记功能。

6. 总结与建议

通过对Android各组件安全策略的配置、第二遍策略检查、现场试验以及进入强制模式等一系列操作，可以有效地提高系统的安全性和稳定性。以下是一些总结和建议：

6.1 总结

• 全面检查与处理 ：对系统中各个组件的安全策略进行全面检查，针对不同的拒绝访问问题，采取相应的处理措施，如添加允许规则、修改标签、创建新的域等。
• 严格测试 ：在完成策略配置后，进行充分的测试，包括CTS测试和现场试验。通过不断收集日志和分析拒绝访问问题，逐步完善安全策略。
• 遵循最佳实践 ：在策略调整和优化过程中，遵循谨慎使用允许规则、合理处理neverallow规则、关注MLS支持等最佳实践，确保系统的安全性和兼容性。

6.2 建议

• 持续监控与更新 ：安全威胁是不断变化的，因此需要对系统进行持续监控，及时发现新的安全问题并更新安全策略。
• 加强培训与学习 ：参与安全策略配置和实施的人员应加强相关知识的学习和培训，了解最新的安全技术和最佳实践，提高应对安全问题的能力。
• 建立安全机制 ：建立完善的安全机制，如访问控制、审计日志等，以便及时发现和处理安全事件。

各组件问题处理流程总结表

组件	问题类型	处理方法	注意事项
init	对rootfs的写和创建操作	修改init.te规则，修改external/sepolicy domain.te的neverallow规则	可能导致CTS测试失败，优先考虑去除init不必要的写行为
init	执行无域转换的执行文件	为 /system/bin/magd 和 /system/bin/rfkill 创建各自的域和执行类型	按步骤创建相关文件和添加规则
shell	入口点拒绝访问	创建init_shell域，修改相关文件	按步骤操作确保规则正确添加
shell	对原始设备的访问拒绝	标记 /dev/ttymxc[0-9]* 为tty_device	在文件上下文中正确添加标记

安全策略实施整体流程图

graph TD;
    A[各组件安全策略配置] --> B[第二遍策略检查];
    B --> C[现场试验];
    C --> D{是否还有拒绝访问问题};
    D -- 是 --> A;
    D -- 否 --> E[进入强制模式];
    E --> F[持续监控与更新];

通过以上详细的安全策略配置和实施过程，以及对关键组件问题的深入分析和注意事项的总结，可以帮助开发者和安全人员更好地保障Android系统的安全性和稳定性。在实际操作中，要严格按照步骤进行，确保每个环节都正确无误。