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

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

在对 UDOO 设备进行开发和优化时，为确保设备的稳定性、兼容性和安全性，我们需要对设备进行清理、设置兼容性测试套件（CTS）、运行测试并根据测试结果优化设备策略。下面将为你详细介绍具体的操作步骤和相关技术细节。

1. 清理设备

当 UDOO 设备变得杂乱时，我们需要对其进行重新刷机，包括数据目录，以全新的状态开始。我们的目标是仅保留代码和初始化脚本的更改，去除额外的安全增强型策略（SELinux Policy，sepolicy），这样可以更好地编写合适的策略并应用所学的技术和工具。
具体操作步骤如下：
1. 从 UDOO 工作区执行以下命令，构建 userdebug 版本：

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

2. 假设 SD 卡已插入主机且用户数据未挂载，执行以下命令刷机、从 SD 卡启动并清除用户数据：

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

2. 设置 CTS

如果你的组织希望获得 Android 品牌授权，必须通过 CTS 测试。即使不追求品牌授权，运行这些测试也有助于确保设备与应用程序的兼容性。我们将 CTS 测试视为一种检查系统、发现影响 UDOO 设备正常运行的策略问题的方法。
设置 CTS 的步骤如下：
1. 从 CTS 下载页面 下载与你的 Android 版本匹配的 CTS 二进制文件。如果你不确定设备运行的 Android 版本，可以通过以下命令查看：

$ getprop ro.build.version.release

2. 创建并进入存储 CTS 文件的目录，下载并解压 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

3. 运行 CTS

CTS 测试会对设备的多个组件进行检查，有助于测试系统的各个部分。一个良好的通用策略应该允许 Android 正常运行并通过 CTS 测试。
运行 CTS 的步骤如下：
1. 按照 Android CTS 用户手册的说明设置设备（见第 3.3 节“设置你的设备”）。至少要复制媒体文件并开启 Wi - Fi。
2. 确保 adb 处于活动状态，启动测试：

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

测试过程可能需要数小时，请耐心等待。你可以通过以下命令检查测试状态：

cts - tf > l i

测试结果示例如下：
| Command Id | Exec Time | Device State |
| — | — | — |
| 1 | 8m:22 | 0123456789ABCDEF running cts on build 4.3_r2 |

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

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

4. 收集测试结果

测试完成后，我们需要收集 CTS 测试结果和审计日志，以便分析和优化策略。
- CTS 测试结果 ：每次运行 CTS 时，会创建一个测试结果目录。目录名称在测试输出中显示，但位置需参考 CTS 手册，通常位于 android - cts/repository/results 下。测试目录中包含一个 XML 测试报告 testResult.xml ，可以在大多数 Web 浏览器中打开查看测试概述和详细信息。
- 审计日志 ：我们将使用审计日志来发现和解决策略中的不足。由于这是一个 userdebug 版本，默认的 adb 终端是 shell 用户 ID（非 root），需要使用 adb root 以 root 权限启动 adb。如果遇到 /data/misc/audit/audit.log 不存在的错误，可以通过以下步骤解决：
1. 运行 adb root 。
2. 如果该命令卡住，进入设备设置，在开发者选项中禁用并重新启用 USB 调试。
3. 终止 adb - root 命令，运行 adb shell 验证是否已获得 root 权限。

5. 编写设备策略

将 audit.log 和 audit.old 文件通过 audit2allow 工具进行分析，以了解策略中的问题。假设你已进入审计日志目录，可以执行以下命令查看分析结果：

$ cat audit.* | audit2allow | less

所有的策略编写工作将在特定于 UDOO 设备的 sepolicy 目录中进行。以下是几个关键域的策略分析和处理方法：
- adbd 域
1. 异常情况 ： adbd 域的拒绝情况较为奇怪，例如对 /dev/ashmem 的执行操作以及对输入设备的写入操作。通过检查进程列表发现， ps 命令不应在 adbd 上下文中运行，而应在 shell 上下文中运行。
2. 解决方法
- 查看文件上下文：

$ adb shell
root@udoo:/ # ls -Z /system/bin/sh
lrwxr - xr - x root shell u:object_r:system_file:s0 sh -> mksh
root@udoo:/ # ls -Z /system/bin/mksh
- rwxr - xr - x root shell u:object_r:system_file:s0 mksh

    - 修改 `file_contexts` 文件：

$ cat file_contexts | grep shell_exec
/system/bin/sh—u:object_r:shell_exec:s0

在 file_contexts 中添加 /system/bin/mksh—u:object_r:shell_exec:s0 ，并在 sepolicy.mk 中添加 BOARD_SEPOLICY_UNION += file_contexts 。
- 处理未标记文件：
对于未标记的 /device 目录，通过以下步骤处理：

root@udoo:/ # mount | grep device
/dev/block/mmcblk0p7 /device ext4 
ro,seclabel,nosuid,nodev,relatime,user_xattr,barrier = 1,data = ordered 0 0

在 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 。如果该目录不为空，需要手动运行 restorecon -R 对现有文件进行标记。
- 处理审计日志访问问题：
在 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;

如果 auditd.te 仍在 external/sepolicy 中，将其连同所有依赖类型移动到 device/fsl/udoo/sepolicy 目录。

以下是处理 adbd 域问题的流程图：

graph TD;
    A[发现 adbd 异常] --> B[检查进程上下文];
    B --> C[查看文件上下文];
    C --> D[修改 file_contexts];
    D --> E[处理未标记文件];
    E --> F[处理审计日志访问问题];

• bootanim 域
  1. 异常情况 ： bootanim 域连接到 init 的 Unix 域套接字并写入属性套接字，同时对已弃用的 log_device 进行操作。
  2. 解决方法 ：在 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;

通过以上步骤，我们完成了对 UDOO 设备的清理、CTS 测试设置与运行、结果收集以及设备策略的编写和优化，有助于确保设备的正常运行和兼容性。后续还将继续对其他域的策略进行分析和优化，以进一步提升设备的安全性和稳定性。

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

6. 其他关键域的策略分析与处理

• debuggerd域

  1. 异常情况 ： debuggerd 域存在对 system_data_file:sock_file 的写入拒绝情况。查看原始拒绝信息可知，拒绝发生在 ndebugsocket 上，并且这涉及到策略版本 23 不支持的命名类型转换。
  2. 解决方法 ：在 debuggerd.te 中添加 allow debuggerd system_data_file:sock_file write; 。由于该操作是跨域的，且未请求打开文件操作，所以不授予额外权限。
     以下是处理 debuggerd 域问题的操作步骤列表：
     - 分析原始拒绝信息，确定问题根源。
     - 在 debuggerd.te 文件中添加允许写入的规则。

• drmserver域

  • 异常情况 ： drmserver 域存在对 log_device:chr_file 的写入和打开拒绝情况。
  • 解决方法 ：该问题已由 domain.te 中的规则解决，无需额外操作。

域名称	异常情况	解决方法
debuggerd	对 system_data_file:sock_file 写入拒绝	在 debuggerd.te 中添加 allow debuggerd system_data_file:sock_file write;
drmserver	对 log_device:chr_file 写入和打开拒绝	由 domain.te 规则解决，无需额外操作

• dumpstate域
  1. 异常情况 ：
     • dumpstate 域对 init:binder 的调用拒绝情况较为奇怪，因为 init 通常不使用 binder 。通过检查进程列表发现， zygote 和 com.android.phone 不应以 init 身份运行，这可能是 app_process 文件的标签错误导致的。
     • 还存在对 init:process 的信号拒绝，以及对 log_device 、 node 、 self 和 system_data_file 等的相关操作拒绝。
  2. 解决方法 ：
     • 检查 app_process 文件的标签：

$ ls -laZ /system/bin/app_process
u:object_r:system_file:s0 app_process

    - 修改 `file_contexts` 文件：在 `file_contexts` 中添加 `/system/bin/app_process u:object_r:zygote_exec:s0`，以纠正标签错误。

以下是处理 dumpstate 域问题的流程图：

graph TD;
    A[发现 dumpstate 异常] --> B[检查进程列表];
    B --> C[检查 app_process 文件标签];
    C --> D[修改 file_contexts 文件];

7. 策略优化总结与注意事项

在整个 UDOO 设备策略优化过程中，我们通过对各个关键域的详细分析和处理，解决了许多潜在的策略问题，提高了设备的安全性和稳定性。以下是一些总结和注意事项：

• 策略文件的管理 ：在创建或修改策略文件（如上下文文件或 .te 文件）时，务必将其添加到 sepolicy.mk 中的 BOARD_SEPOLICY_UNION 中，确保新策略能够正确生效。
• 异常情况的处理 ：对于出现的异常拒绝情况，要仔细分析原始审计信息，找出问题根源，并采取针对性的解决措施。例如，对于未标记文件，要通过检查挂载表和相关配置文件，为其添加合适的类型和标签。
• 跨域操作的谨慎性 ：在处理跨域操作时，如 debuggerd 域的跨域写入，要谨慎授予权限，避免不必要的安全风险。

8. 持续优化建议

为了进一步提升 UDOO 设备的性能和安全性，建议进行持续的策略优化：

• 定期审计日志分析 ：定期收集和分析审计日志，及时发现新出现的策略问题，并进行相应的调整。
• 跟进 Android 版本更新 ：随着 Android 系统的不断更新，策略规则也可能发生变化。及时跟进更新，确保设备策略与最新版本兼容。
• 测试与验证 ：在每次修改策略后，进行全面的 CTS 测试和功能验证，确保修改不会引入新的问题。

通过以上持续优化措施，可以使 UDOO 设备始终保持良好的运行状态，为用户提供更稳定、安全的使用体验。

总之，通过对 UDOO 设备进行全面的清理、CTS 测试设置与运行、结果收集以及详细的策略分析和优化，我们能够有效解决设备中存在的策略问题，提升设备的兼容性、安全性和稳定性。在实际操作过程中，要严格按照操作步骤进行，并根据具体情况灵活调整策略，以达到最佳的优化效果。