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/