安全与权限问题排查：从权限拒绝到 avc denied

前七章把四层安全讲完了。这一章把它们串成排障链：权限拒绝、AppOps 拦截、avc denied、 签名/白名单问题，按什么顺序查、看什么证据。

先记录调用方 UID、目标服务和完整异常，再依次核对权限授予、AppOps、签名/特权白名单与 SELinux avc。不同层的拒绝具有不同证据，不能看到 Permission denied 就直接修改 sepolicy。

先判断拒绝发生在哪一层

常见误解	正确理解
权限被拒就是没点允许	可能是保护级别、AppOps、SELinux、签名或白名单任一环节
avc denied 一定在 logcat	内核拒绝主要在 dmesg，logcat 可能看不到
改了权限就行	权限只是四层之一，要按层检查

核心结论

1. 排障顺序固定：身份 → 权限 → AppOps → SELinux → 签名/白名单。
2. 权限问题看 dumpsys package；AppOps 看 dumpsys appops；SELinux 看 avc 日志。
3. 服务端拒绝看 SecurityException 与调用方 UID。
4. 特权权限未生效查签名、目录、白名单三项。
5. 修复后必须回归：重复触发操作，确认拒绝消失。

五层检查链

逐步解释：

1. 身份：确认调用方 UID/PID 是否符合预期。
2. 权限：定义与授予状态。
3. AppOps：操作级开关。
4. SELinux：内核强制规则。
5. 签名/白名单：系统能力背书。

常用命令与证据

环境：开发设备或模拟器；avc 日志需要 root。

adb shell dumpsys package <包名> | grep -A30 "requested permissions"
adb shell dumpsys package <包名> | grep -A20 "runtime permissions"
adb shell dumpsys appops | grep <包名>
adb shell su 0 dmesg | grep -E "avc: denied" | tail -20
adb logcat -v threadtime | grep -E "SecurityException|Permission Denial"
adb shell dumpsys package <包名> | grep -E "signatures|priv|allowlist"

证据	含义	下一步
SecurityException	权限或身份拒绝	查 UID 与权限授予
appops ignore/deny	操作级拦截	调整 AppOps 模式
avc: denied	SELinux 拒绝	看 scontext/tcontext
无 signature/白名单	特权未背书	核对签名与 privapp 文件

常见场景与定位思路

场景一：运行时权限被拒

先看授予状态，再看 AppOps；如果都正常，查 SELinux。不要只看弹窗，权限链有四层。

场景二：系统应用特权权限没生效

对照“平台签名、priv-app 目录、privapp-permissions 白名单”三项。白名单缺失时 系统可能告警或拒绝授予。

场景三：自定义服务被 SecurityException 拒绝

看拒绝日志中的调用方 UID，对照服务端权限检查；确认客户端是否以正确身份调用， 服务端是否在入口校验。

场景四：avc denied

先读 scontext/tcontext/tclass，判断是否合法需求；合法则补策略并回归，否则改实现。 不要直接切 permissive。

常见误区

1. “权限被拒就是没允许”：先按五层定位。
2. “avc 在 logcat”：主要看 dmesg。
3. “改权限就能解决一切”：AppOps 与 SELinux 同样拦路。
4. “permissive 是临时修复”：它是排查手段，不是修复。

延伸问题

1. 如何把线上安全拒绝自动收集归类？
2. SecurityException 与 SELinux 拒绝如何区分？
3. 自定义权限的安全设计要点是什么？
4. 厂商定制如何保持安全基线？

源码入口

文件	关键位置	作用
PermissionManagerService.java	检查入口	权限判定
AppOpsService.java	模式管理	操作级开关
system/sepolicy/	策略	SELinux
Binder.java	getCallingUid()	身份校验

公共路径沿用本系列各章。行号以 r75 检索为准。

需要结合系统通用证据时，见 系统调试与排障。