Android/SELinux 添加 AVC 权限
背景
在Android应用层中编写c/c++应用时，发现接口调用出现问题，logcat才知道是因为：权限不够。
type=1400 audit(0.0:4): avc: denied { create } for scontext=u:r:bootanim:s0 tcontext=u:r:bootanim:s0 tclass=netlink_socket permissive=0
参考：
- https://blog.csdn.net/qq_27256793/article/details/105245908
- https://blog.csdn.net/m0_46211029/article/details/105157587
介绍
安全增强型 Linux（Security-Enhanced Linux）简称 SELinux，它是 Linux 的一个安全子系统。SELinux 主要作用是最大限度地减小系统中服务进程可访问的资源（最小权限原则）。对资源的访问控制分为两类: DAC和MAC
SELinux工作模式
SELinux 有三种工作模式，分别为:
- enforcing: 强制模式, 执行SELinux规则, 违反的行为会被阻止
- permissive: 宽容模式, 执行SELinux规则, 违反的行不会被阻止
- disabled: 关闭SELinux
avc denied
在Android系统开发中, 可能会遇到SELinux的权限不足而引起的各种问题；可以尝试将SELinux工作模式临时改为宽容模式看问题是否解决, 来判定是否是SELinux引起的问题
标志性 log: avc: denied { 操作权限 } for pid=7201 comm=“进程名” scontext=u:r:源类型:s0 tcontext=u:r:目标类型:s0 tclass=访问类型 permissive=0
- 源类型：授予访问的类型，通常是进程的域类型
- 目标类型：客体的类型，它被授权可以访问的类型
- 访问类型
- 操作权限：表示主体对客体访问时允许的操作类型（也叫做访问向量）。
举例
打开三方apk出问题，其中错误log如下：
03-28 10:18:07.990 11883 11883 W re-initialized>: type=1400 audit(0.0:2918):
avc: denied { read } for name="u:object_r:mtk_amslog_prop:s0"
dev="tmpfs" ino=7544 scontext=u:r:system_app:s0
tcontext=u:object_r:mtk_amslog_prop:s0
tclass=file permissive=0
解释：
- read：表示没有 read 权限
- system_app：system_app 中缺少权限
- mtk_amslog_prop：mtk_amslog_prop 文件系统缺少权限
- file：file 类型的文件
- 分析：adb shell setenforce 0。设置SELinux 成为permissive模式。若apk可正常使用，则进行规避此权限问题
修改selinux规则
type=1400 audit(0.0:4): avc: denied { create } for
scontext=u:r:bootanim:s0
tcontext=u:r:bootanim:s0
tclass=netlink_socket
permissive=0
type=1400 audit(0.0:41): avc: denied { read } for
name="u:object_r:media_prop:s0"
dev="tmpfs" ino=11511
scontext=u:r:mediacodec:s0
tcontext=u:object_r:media_prop:s0
tclass=file
permissive=0
| 节点 | 寻找点 | 结果 |
|---|---|---|
| 缺少的权限 | denied { 权限 } |
create |
| 谁（哪个进程）缺少权限 | scontext=u:r:进程:s0 |
bootanim |
| 对哪个节点缺少权限 | tcontext=u:r:节点:s0； |
bootanim 或 self |
| 缺少要访问的对象 | tclass=被访问对象 |
netlink_socket |
技巧：
- 如果
tcontext中的节点与scontext中的进程名相同，则可以写成self - 因为有时候avc denied 的log不是一次性显示所有问题，要等解决一个权限问题后，才会显示另外一个权限问题，比如显示缺失某个目录的read权限。所以建议是先参考其他可能出现访问权限的问题的有关接口关键字，进行多次添加。
- 要加入的权限很多时，可以用中括号，比如：
allow untrusted_app vfat:dir { search write }
由于，scontext对应的是我们要修改的文件（这里是bootanim），根据type=1400 audit(0.0:4): avc: denied { create } for scontext=u:r:bootanim:s0 tcontext=u:r:bootanim:s0 tclass=netlink_socket permissive=0的提示；因此，需要在bootanim.te最后面中添加所对应的权限是：
# file : bootanim.te
allow bootanim self:netlink_socket {create};
再看一个例子：
# type=1400 audit(0.0:41): avc: denied { read } for
# name="u:object_r:media_prop:s0"
# dev="tmpfs" ino=11511
# scontext=u:r:mediacodec:s0
# tcontext=u:object_r:media_prop:s0
# tclass=file permissive=0
# file: mediacodec.te
allow mediacodec media_prop:file {read}
修改系统selinux模式
临时修改
adb shell setenforce 0 #设置SELinux 成为permissive模式
adb shell setenforce 1 #设置SELinux 成为enforcing模式
adb shell getenforce #获取SELinux状态(permissive,enforcing,disabled)
永久修改
安卓7
路径：system/core/init/init.cpp
static selinux_enforcing_status selinux_status_from_cmdline() {
selinux_enforcing_status status = SELINUX_ENFORCING; // 强制模式, 执行SELinux规则, 违反的行为会被阻止
//selinux_enforcing_status status = SELINUX_PERMISSIVE;// 宽容模式， 执行SELinux规则, 违反的行不会被阻止
import_kernel_cmdline(false, [&](const std::string& key, const std::string& value, bool in_qemu) {
if (key == "androidboot.selinux" && value == "permissive") {
status = SELINUX_PERMISSIVE;
}
});
return status;
}
安卓9/10
路径：system/core/init/selinux.cpp
EnforcingStatus StatusFromCmdline() {
// EnforcingStatus status = SELINUX_ENFORCING;// 强制模式, 执行SELinux规则, 违反的行为会被阻止
EnforcingStatus status = SELINUX_PERMISSIVE; // 宽容模式， 执行SELinux规则, 违反的行不会被阻止
import_kernel_cmdline(false,
[&](const std::string& key, const std::string& value, bool in_qemu) {
if (key == "androidboot.selinux" && value == "permissive") {
status = SELINUX_PERMISSIVE;
}
});
return status;
}
附录A：在permissive模式下，有些app仍然无法访问具体节点
敏感权限的特征：log中带有c512,c768字样
试着在untrusted_app.te 中添加了allow untrusted_app audio_device:chr_file { open write read };还是报如下权限错误：
[ 141.935275] type=1400 audit(1546939304.786:43): avc: denied { write } for
pid=1836 comm="Thread-4"
name="pcmC0D1c"
dev="tmpfs"
ino=11947
scontext=u:r:untrusted_app:s0:c512,c768
tcontext=u:object_r:audio_device:s0
tclass=chr_file
permissive=1
先确认需要访问的节点是否为audio_device，这个节点属于敏感权限，可以的话请修改访问的目录和文件，缩小audio_device的范围
方法为：
1、确定访问的节点位置，通过源码或者log确定到底访问的哪一个具体的节点, 例如 /dev/pcmc00xx
2、在相应的te文件中新声明一个节点名称, 如 file.te: type test_audio_device, dev_type;
3、在file_context中将具体节点绑定新的节点名称, 如: file_context: /dev/pcmc00xx test_audio_device
4、增加或修改需要的权限: allow untrusted_app test_audio_device:chr_file { open write read };
如果不过GMS认证,敏感权限(c512,c768)可以直接把对象关联mlstrustedobject, 但不推荐这样修改,会造成严重的安全问题。 例如: typeattribute audio_device mlstrustedobject;
附录B：DAC和MAC有什么区别？
DAC
DAC（Discretionary Access Control，自主访问控制）
- DAC是传统的Linux的访问控制方式，DAC可以对文件、文件夹、共享资源等进行访问控制。
- 在DAC这种模型中，文件客体的所有者（或者管理员）负责管理访问控制。
- DAC使用了ACL（Access Control List，访问控制列表）来给非管理者用户提供不同的权限，而root用户对文件系统有完全自由的控制权。
MAC
MAC（Mandatory Access Control，强制访问控制）
- SELinux在内核中使用MAC检查操作是否允许。
- 在MAC这种模型中，系统管理员管理负责访问控制，用户不能直接改变强制访问控制属性。
- MAC可以定义所有的进程（称为主体）对系统的其他部分（文件、设备、socket、端口和其它进程等，称为客体）进行操作的权限或许可。
DAC和MAC的其它区别
① DAC的主体是真实有效的用户和组ID，MAC的主体是安全上下文，两者的UID是各自独立的。
② DAC的访问控制模式是rwxrwxrwx，MAC的访问控制模式是user:role:type。
附录C：高通平台修改selinux权限路径
Android 7 ：device/qcom/sepolicy/common/
Android 9：其中的某一个
device/qcom/sepolicy/vendor/common/device/sprd/sharkl3/common/sepolicy/
Android 10：其中的某一个
device/qcom/sepolicy/vendor/common/device/qcom/sepolicy/legacy/vendor/common/device/sprd/sharkl3/common/sepolicy/