15、安卓设备CTS测试与策略优化指南

最新推荐文章于 2025-10-25 15:28:45 发布

对方正在偷人346

最新推荐文章于 2025-10-25 15:28:45 发布

阅读量39

点赞数

CC 4.0 BY-SA版权

分类专栏：深入Android安全核心文章标签：安卓 CTS测试设备清理

本文链接：https://blog.youkuaiyun.com/grpc6streamer/article/details/153900377

深入Android安全核心专栏收录该内容

17 篇文章 ¥499.90

订阅专栏¥69.90

会员秒杀 ¥9.9 重磅福利

超级会员免费看

安卓设备CTS测试与策略优化指南

一、设备清理

当设备状态杂乱时，我们需要对其进行重新刷机，包括数据目录，以全新的状态开始。具体操作步骤如下：
1. 构建用户调试版本 ：为了进行CTS测试，我们需要构建用户调试（userdebug）版本，而非工程（eng）版本。在UDOO工作区执行以下命令：

$ . setup udoo-userdebug
$ make -j8 2>&1 | tee logz

刷机与擦除用户数据 ：假设SD卡已插入主机且用户数据未挂载，执行以下命令来刷机并擦除用户数据：

$ mkdir ~/userdata
$ sudo mount /dev/sdd4 ~/userdata
$ cd ~/userdata/
$ sudo rm -rf *
$ cd ..
$ sudo umount ~/userdata

二、CTS测试环境搭建

如果你的组织寻求安卓品牌认证，那么必须通过CTS测试。即使不追求品牌认证，运行这些测试也有助于确保设备与应用程序的兼容性。以下是CTS测试环境搭建的步骤：
1. 下载CTS二进制文件 ：从Google直接下载CTS二进制文件，你可以从以下链接获取更多信息和CTS二进制文件本身：
- https://source.android.com/compatibility/cts-intro.html
- https://source.android.com/compatibility/android-cts-manual.pdf
从下载页面下载CTS 4.3二进制文件，然后选择相应的CTS二进制文件。同时，兼容性定义文档（CDD）也值得一读，它涵盖了CTS的高级细节和兼容性要求。
2. 下载并解压CTS ：根据设备的安卓版本选择相应的CTS版本进行下载和解压。如果你不知道设备运行的安卓版本，可以使用以下命令检查：

$ getprop ro.build.version.release

然后执行以下命令下载并解压CTS：

$ mkdir ~/udoo-cts
$ cd ~/udoo-cts
$ wget https://dl.google.com/dl/android/cts/android-cts-4.3_r2-linux_x86-arm.zip
$ unzip android-cts-4.3_r2-linux_x86-arm.zip

三、运行CTS测试

CTS测试可以锻炼设备的许多组件，帮助测试系统的各个部分。一个良好的通用策略应该允许安卓系统正常运行并通过CTS测试。以下是运行CTS测试的步骤：
1. 设备设置 ：按照安卓CTS用户手册中的说明设置设备（见第3.3节，设置你的设备）。至少要确保媒体文件已复制且Wi-Fi已激活。
2. 启动测试 ：确保adb处于活动状态，然后启动测试：

$ ./cts-tradefed
cts-tf > run cts --plan CTS

测试可能需要数小时才能完成，请耐心等待。你可以使用以下命令检查测试状态：

cts-tf > l i

测试过程中，CTS会重启设备。如果重启后adb会话未恢复，adb可能无法执行任何测试。你可以在运行测试时使用 --disable-reboot 选项：

cts-tf > run cts --plan CTS --disable-reboot

四、收集测试结果

测试完成后，我们需要收集CTS测试结果和审计日志，以便后续分析。
1. CTS测试结果 ：每次运行CTS时，它都会创建一个测试结果目录。虽然CTS会显示目录名称，但不会显示其位置。该位置在CTS手册中有提及，通常位于解压后的CTS目录下的 repository/results ，例如 android-cts/repository/results 。测试目录中包含一个XML测试报告 testResult.xml ，可以在大多数Web浏览器中打开，它提供了测试的概述和所有执行测试的详细信息。
2. 审计日志 ：我们将使用审计日志来解决策略中的不足之处。由于这是一个用户调试版本，默认的adb终端是shell uid（非root），因此需要使用 adb root 以root身份启动adb。你可以使用以下命令拉取审计日志：

$ adb root
$ adb pull /data/misc/audit/audit.log
$ adb pull /data/misc/audit/audit.old

如果你遇到 /data/misc/audit/audit.log 不存在的错误，可以通过 adb root 命令以root身份运行adb。如果该命令挂起，可以前往设置，在开发者选项中禁用并重新启用USB调试，然后终止 adb-root 命令，通过运行 adb shell 验证你是否已获得root权限。

五、设备策略编写

将 audit.log 和 audit.old 通过 audit2allow 运行，以查看具体情况。 audit2allow 的输出按源域分组。我们将重点关注一些不寻常的情况。假设你在审计日志目录中，执行以下命令：

$ cat audit.* | audit2allow | less

任何策略工作都将在特定于设备的UDOO sepolicy目录中完成。

以下是一些常见域的策略分析和处理：
1. adbd域
- 异常分析 ：adbd域中的拒绝情况比较奇怪，例如对 /dev/ashmem 的执行操作通常仅在Dalvik JIT时需要。通过查看原始审计日志，发现编译器进程在 ashmem 上执行操作。此外， ps 命令不应在adbd上下文中运行，而应在shell上下文中运行。这可能是由于shell的标签不正确导致的。
- 解决方案 ：
- 检查文件上下文：

$ ls -Z /system/bin/sh
$ ls -Z /system/bin/mksh

    - 在`file_contexts`中添加自定义条目：

/system/bin/mksh—u:object_r:shell_exec:s0

    - 在`sepolicy.mk`中添加：

BOARD_SEPOLICY_UNION += file_contexts

    - 对于未标记的文件`/device`，在`file.te`中添加：

type udoo_device_file, file_type;

    - 在`domain.te`中添加：

allow domain udoo_device_file:dir getattr;

    - 在`file_contexts`中添加：

/device u:object_r:udoo_device_file:s0

    - 对于多次拉取审计日志导致的拒绝情况，在`adbd.te`中添加：

# dont audit adb pull and adb shell cat of audit logs
dontaudit adbd audit_log:file r_file_perms;
dontaudit shell audit_log:file r_file_perms;

    - 在`auditd.te`中添加：

# Make sure no one adds an allow to the audit logs
# from anything but system server (read only) and
# auditd, rw access.
neverallow { domain -system_server -auditd -init -kernel } audit_log:file ~getattr;
neverallow system_server audit_log:file ~r_file_perms;

bootanim域
- 异常分析 ： bootanim 域连接到init Unix域套接字并写入属性套接字，这是一个危险信号。此外， log_device 在新版本的安卓中已被弃用，被 logd 取代。
- 解决方案 ：
  - 在 bootanim.te 中添加：

unix_socket_connect(bootanim, property, init)

    - 在`domain.te`中添加：

allow domain udoo_device_file:dir getattr;
allow domain log_device:dir search;
allow domain log_device:chr_file rw_file_perms;

debuggerd域
- 异常分析 ： debuggerd 域对 system_data_file:sock_file 的写入操作比较奇怪，通常不希望允许跨域写入，但这种情况比较特殊。
- 解决方案 ：在 debuggerd.te 中添加：

allow debuggerd system_data_file:sock_file write;

dumpstate域
- 异常分析 ： dumpstate 域对 init:binder call 的拒绝情况很奇怪，因为init不使用binder。通过检查进程列表，发现 zygote 和 com.android.phone 不应以init身份运行，这可能是 app_process 文件的标签错误导致的。
- 解决方案 ：在 file_contexts 中添加：

/system/bin/app_process u:object_r:zygote_exec:s0

总结

通过以上步骤，我们完成了设备的清理、CTS测试环境的搭建、CTS测试的运行、测试结果的收集以及设备策略的编写和优化。在整个过程中，我们需要仔细分析审计日志，找出策略中的不足之处，并及时进行调整。同时，要注意不同域之间的交互和权限设置，确保设备的安全性和兼容性。

以下是一个mermaid流程图，展示了整个过程：

graph LR
    A[设备清理] --> B[CTS测试环境搭建]
    B --> C[运行CTS测试]
    C --> D[收集测试结果]
    D --> E[设备策略编写]

表格总结

步骤	操作内容
设备清理	构建用户调试版本，刷机并擦除用户数据
CTS测试环境搭建	下载并解压CTS二进制文件
运行CTS测试	设置设备，启动测试，检查测试状态
收集测试结果	收集CTS测试结果和审计日志
设备策略编写	分析审计日志，编写和优化设备策略

安卓设备CTS测试与策略优化指南

六、各域策略详细分析与优化

前面我们已经对一些常见域的策略进行了初步分析和处理，下面将更深入地探讨这些域的策略问题以及相应的优化措施。

adbd域深入分析
- 异常根源 ：adbd域出现诸多异常，如编译器进程在ashmem上执行操作、 ps 命令上下文错误等，主要原因是shell标签不正确，导致域转换失败。通过查看文件上下文，发现 /system/bin/sh 和 /system/bin/mksh 的标签未正确设置，影响了从adbd到shell域的转换。
- 优化措施总结
  - 标签修正 ：在 file_contexts 中添加 /system/bin/mksh—u:object_r:shell_exec:s0 ，确保mksh文件有正确的标签。
  - 策略合并 ：在 sepolicy.mk 中添加 BOARD_SEPOLICY_UNION += file_contexts ，将自定义的文件上下文合并到策略中。
  - 未标记文件处理 ：对于未标记的 /device 目录，在 file.te 、 domain.te 和 file_contexts 中添加相应规则，赋予其正确的类型和权限。
  - 审计日志保护 ：在 adbd.te 和 auditd.te 中添加规则，保护审计日志不被非法访问。
bootanim域深入分析
- 异常风险 ： bootanim 域连接到init Unix域套接字并写入属性套接字，这可能会带来安全风险，因为init域是系统的核心域，不应该被随意访问。此外， log_device 的使用在新版本安卓中已被弃用，可能会导致兼容性问题。
- 优化措施总结
  - 套接字连接规则 ：在 bootanim.te 中添加 unix_socket_connect(bootanim, property, init) ，明确 bootanim 与init的套接字连接规则。
  - 日志设备权限 ：在 domain.te 中添加规则，允许 bootanim 对相关日志设备和目录有适当的访问权限。
debuggerd域深入分析
- 异常特殊性 ： debuggerd 域对 system_data_file:sock_file 的写入操作虽然特殊，但也需要谨慎处理。跨域写入可能会破坏系统的安全性和稳定性，因此需要严格控制权限。
- 优化措施总结 ：在 debuggerd.te 中添加 allow debuggerd system_data_file:sock_file write; ，仅允许必要的写入操作，同时避免授予过多权限。
dumpstate域深入分析
- 异常原因 ： dumpstate 域对 init:binder call 的拒绝以及 zygote 和 com.android.phone 以init身份运行的问题，根源在于 app_process 文件的标签错误。这导致了进程的上下文不正确，影响了系统的正常运行。
- 优化措施总结 ：在 file_contexts 中添加 /system/bin/app_process u:object_r:zygote_exec:s0 ，修正 app_process 文件的标签，确保进程能正确进入相应的域。

七、策略编写与优化的注意事项

在进行设备策略编写和优化时，需要注意以下几点：
1. 策略文件的合并 ：每次创建或修改策略文件（如上下文文件或 .te 文件）时，不要忘记将它们添加到 BOARD_SEPOLICY_UNION 中，以确保这些策略能被正确合并和应用。
2. 权限的严格控制 ：在添加允许规则时，要谨慎考虑权限的授予范围，避免过度授权。例如，对于跨域操作，要确保只有必要的操作被允许。
3. 审计日志的分析 ：审计日志是发现策略问题的重要依据，要定期分析审计日志，及时发现并解决策略中的不足之处。
4. 兼容性问题 ：在处理旧版本安卓的遗留问题（如 log_device 的使用）时，要考虑到新版本的兼容性，尽量采用新的解决方案。

八、常见问题及解决方案

在整个CTS测试和策略优化过程中，可能会遇到一些常见问题，以下是一些解决方案：
1. 审计日志拉取失败
- 问题描述 ：执行 adb pull /data/misc/audit/audit.log 时，可能会遇到 /data/misc/audit/audit.log 不存在的错误。
- 解决方案 ：通过 adb root 命令以root身份运行adb。如果该命令挂起，可以前往设置，在开发者选项中禁用并重新启用USB调试，然后终止 adb-root 命令，通过运行 adb shell 验证你是否已获得root权限。
2. CTS测试失败
- 问题描述 ：CTS测试可能会因为各种原因失败，如设备设置不正确、权限不足等。
- 解决方案 ：确保按照安卓CTS用户手册的要求设置设备，包括复制媒体文件、激活Wi-Fi等。同时，检查策略文件，确保设备有足够的权限执行测试。
3. 策略文件修改后未生效
- 问题描述 ：修改策略文件后，重新运行CTS测试，发现问题仍然存在。
- 解决方案 ：检查 BOARD_SEPOLICY_UNION 是否正确合并了修改后的策略文件。同时，确保设备已重新刷机，使新的策略生效。

九、策略优化效果评估

在完成策略优化后，我们需要评估优化效果，以确保设备的安全性和兼容性得到提升。评估指标可以包括：
1. CTS测试通过率 ：通过对比优化前后的CTS测试通过率，评估策略优化对设备兼容性的影响。
2. 审计日志中的拒绝次数 ：查看审计日志中拒绝操作的次数是否减少，以评估策略优化对设备安全性的提升。
3. 设备性能 ：观察设备在优化后的性能表现，如响应速度、稳定性等，确保策略优化不会对设备性能造成负面影响。

以下是一个表格，总结了各域策略优化的效果评估指标：
|域|评估指标|
|----|----|
|adbd|CTS测试中adbd相关测试的通过率，审计日志中adbd拒绝操作次数|
|bootanim|CTS测试中bootanim相关测试的通过率，bootanim与init交互的异常次数|
|debuggerd|CTS测试中debuggerd相关测试的通过率，debuggerd跨域写入操作的异常次数|
|dumpstate|CTS测试中dumpstate相关测试的通过率，dumpstate与init交互的异常次数|

十、总结与展望

通过对安卓设备进行CTS测试和策略优化，我们可以提高设备的安全性和兼容性。在整个过程中，我们需要仔细分析审计日志，找出策略中的不足之处，并及时进行调整。同时，要注意不同域之间的交互和权限设置，确保设备的安全性和兼容性。

未来，随着安卓系统的不断发展和更新，我们需要不断关注新的安全问题和兼容性要求，及时调整设备策略。同时，可以探索更自动化的策略优化方法，提高策略优化的效率和准确性。

以下是一个mermaid流程图，展示了策略优化的持续改进过程：

graph LR
    A[初始策略] --> B[运行CTS测试]
    B --> C{测试是否通过}
    C -- 否 --> D[分析审计日志]
    D --> E[优化策略]
    E --> B
    C -- 是 --> F[持续监控]
    F --> G{是否出现新问题}
    G -- 是 --> D
    G -- 否 --> F

最终总结

整个安卓设备CTS测试与策略优化过程是一个系统性的工作，涵盖了设备清理、测试环境搭建、测试运行、结果收集和策略编写等多个环节。通过严格按照步骤操作，仔细分析审计日志，我们可以有效地提高设备的安全性和兼容性。同时，要不断关注系统的变化，及时调整策略，以适应新的安全和兼容性要求。在实际操作中，要注意细节，严格控制权限，确保每一步都能达到预期的效果。希望本文提供的方法和建议能帮助你更好地完成安卓设备的CTS测试和策略优化工作。