企业官网建设流程全解析

Android SELinux实战：从avc denied日志到完整allow规则

1. 理解SELinux权限问题的本质

当你在Android系统开发中遇到"Permission denied"错误时，很可能正在面对SELinux的强制访问控制机制。与传统的Linux DAC（自主访问控制）不同，SELinux采用MAC（强制访问控制）模型，即使root用户也需要明确的权限声明。

关键概念速览：

• scontext：主体安全上下文（如发起操作的进程）
• tcontext：客体安全上下文（如被访问的文件、服务）
• tclass：客体类别（file, dir, service_manager等）
• avc denied：SELinux拒绝访问的标准日志前缀

典型avc日志结构示例：

avc: denied { read } for pid=1234 comm="demo" scontext=u:r:system_app:s0 tcontext=u:object_r:vendor_configs_file:s0 tclass=file permissive=0

2. 实战问题排查流程

2.1 获取完整avc日志

# 实时监控avc日志 adb logcat | grep "avc: denied" # 查看内核avc日志 adb shell dmesg | grep avc

2.2 日志关键字段解析

使用这个快速参考表理解日志含义：

2.3 使用audit2allow生成规则

# 将日志保存到文件 adb logcat -d > avc_log.txt # 生成初步规则 audit2allow -i avc_log.txt # 输出示例： # allow system_app vendor_file:file { read open };

3. 规则优化与安全实践

3.1 基础规则模板

# 标准allow语句结构 allow <scontext> <tcontext>:<tclass> { <permissions> }; # 实际案例： allow system_app hal_demo_hwservice:hwservice_manager find;

3.2 高级规则技巧

情形1：需要访问特定目录

# 允许递归访问目录 allow demo_app demo_data_file:dir r_dir_perms; allow demo_app demo_data_file:file rw_file_perms; # r_dir_perms包含的权限： { open getattr read search ioctl lock }

情形2：Binder通信权限

# 允许binder调用 binder_call(client_domain, server_domain) # 展开后实际包含： allow client_domain server_domain:binder { call transfer }; allow server_domain client_domain:binder transfer;

3.3 安全最佳实践

1. 最小权限原则：只授予必要权限
2. 类型细化：为不同资源创建独立类型
3. 属性继承：利用attribute简化规则
4. neverallow检查：确保不违反系统约束

4. 典型场景解决方案

4.1 系统服务注册问题

错误现象：

SELinux: avc: denied { add } for service=demo scontext=u:r:system_server:s0 tcontext=u:object_r:default_android_service:s0

解决方案：

1. 在service.te定义新类型：

type demo_service, service_manager_type;

2. 在service_contexts添加映射：

demo u:object_r:demo_service:s0

3. 在system_server.te添加权限：

allow system_server demo_service:service_manager add;

4.2 HAL服务访问问题

错误日志：

avc: denied { call } for scontext=u:r:system_app:s0 tcontext=u:r:hal_demo_default:s0 tclass=binder

解决方案：

1. 使用hal_client_domain宏：

hal_client_domain(system_app, hal_demo)

2. 添加binder调用权限：

binder_call(system_app, hal_demo_default)

4.3 文件访问问题

错误日志：

avc: denied { read } for path="/data/demo" scontext=u:r:demo_app:s0 tcontext=u:object_r:system_data_file:s0

解决方案：

1. 创建专用文件类型：

type demo_data_file, data_file_type;

2. 在file_contexts中标记：

/data/demo(/.*)? u:object_r:demo_data_file:s0

3. 添加访问权限：

allow demo_app demo_data_file:file { read write };

5. 编译与验证

5.1 策略编译命令

# 编译整个sepolicy make selinux_policy # 仅编译vendor策略 make vendor_sepolicy.cil

5.2 快速验证流程

1. 将设备切换到permissive模式：

adb shell setenforce 0

2. 推送编译后的策略文件：

adb push out/target/product/xxx/vendor/etc/selinux /vendor/etc/

3. 切换回enforcing模式测试：

adb shell setenforce 1

5.3 常见编译错误处理

错误1：违反neverallow规则

neverallow check failed: allow system_app vendor_file:file execute;

解决方案：

• 创建专用文件类型替代vendor_file
• 检查是否真的需要execute权限

错误2：未定义的类型

ERROR 'unknown type demo_type'

解决方案：

• 在相应te文件中添加类型定义
• 确保类型在正确分区定义（vendor/system）

6. 调试进阶技巧

6.1 自定义权限测试模块

# 在device/xxx/sepolicy/test目录创建： # demo_test.te type demo_test, domain; type demo_test_exec, exec_type, file_type; init_daemon_domain(demo_test) # 添加测试权限 allow demo_test target_type:file { read write };

6.2 使用sesearch查询规则

# 查询允许的规则 sesearch -A -s demo_domain -t target_type # 查询neverallow规则 sesearch --neverallow -A

6.3 实时权限监控

# 监控特定类型的权限检查 adb shell auditctl -w /path/to/file -p rwxa -k demo_monitor adb shell ausearch -k demo_monitor | audit2allow

掌握这些实战技巧后，你将能够高效解决Android开发中90%以上的SELinux权限问题。记住，每个allow规则的添加都应该有明确的业务需求支撑，保持策略的最小权限原则是确保系统安全的关键。