| # Validation & Debugging |
| |
| ## Analyzing Denials (audit2allow) |
| **Never blindly copy `audit2allow` output into policy.** It suggests rules to make the denial go |
| away, not to make the system secure. |
| * **Generic Labels:** If a denial shows `tcontext=u:object_r:device:s0` (or `tmpfs`, |
| `system_data_file`), do not write an `allow` rule for `device`. The correct fix is to label the |
| specific file or node in `file_contexts`. |
| * **dac_override:** If a `dac_override` denial occurs, do NOT grant the capability. The proper |
| solution is to fix the underlying UNIX permissions (user/group/world) of the file or process. |
| |
| ## Permissive vs. Enforcing |
| * Run in permissive mode (`androidboot.selinux=permissive`) only during early device bring-up to |
| gather a comprehensive list of denials. |
| * Switch back to enforcing mode as early as possible to prevent permissive mode from masking |
| subsequent denials. |
| |
| ## Capturing Call Chains (simpleperf) |
| If `dmesg` logs are insufficient to locate the root cause of an AVC denial, capture the |
| kernel/userspace call chain using `simpleperf` (requires Linux >= 5.10): |
| ```shell |
| adb shell -t "cd /data/local/tmp && su root simpleperf record -a -g -e avc:selinux_audited" |
| # Trigger the denial, stop the record, then: |
| adb shell -t "cd /data/local/tmp && su root simpleperf report -g --full-callgraph" |
| ``` |
