Android seLinux导致的APP访问设备权限问题

目录

1. 确认 seLinux导致权限问题

1.1 标志性log 格式：

1.2 举例：

1.3 方法1：adb在线修改

1.4 方法2： 从kernel中彻底关闭 （用于开机初始化时的seLinux权限问题，要重编bootimage）

2. 在sepolicy中添加相应权限

2.1 修改依据

2.2 修改步骤：

2.3 按如下格式在该文件中添加： 

2.4 举例

3. 添加权限后的neverallowed冲突

3.1 编译报错：

3.2 原因：

3.3 解决方法：3.4 举例

---

android KK 4.4 版本后，Google 默认启用了SELinux,即均为Enforcing模式；如果当某个操作不被SEAndroid允许时， 会把SELinux 审查异常打印在kernel log 或者 android log(L 版本)中，对应的关键字是: “avc: denied” 或者”avc: denied”。例如对文件进行write，该如何排查出信息，可以在sepolicy中，添加上相应的allow语句，将权限开放出去；当然还有其他方法。

1. 确认 seLinux导致权限问题

1.1 标志性log 格式：

avc: denied  { 操作权限 }  for pid=7201 comm=“进程名”  scontext=u:r:源类型:s0  tcontext=u:r:目标类型:s0  tclass=访问类别  permissive=0

1.2 举例：

Kenel log：

avc: denied { execheap } for pid=7201 comm="com.baidu.input" scontext=u:r:untrusted_app:s0tcontext=u:r:untrusted_app:s0tclass=processpermissive=0

Logcat log：

com.baidu.input: type=1400audit(0.0:29): avc: denied { execheap } for scontext=u:r:untrusted_app:s0tcontext=u:r:untrusted_app:s0tclass=processpermissive=0

1.3 方法1：adb在线修改

关闭 seLinux：

打开seLinux：

Enforcing：seLinux已经打开；        

Permissive：seLinux已经关闭；

1.4 方法2： 从kernel中彻底关闭 （用于开机初始化时的seLinux权限问题，要重编bootimage）

修改LINUX/android/kernel/arch/arm64/configs/XXXdefconfig文件（找相应config文件）
去掉CONFIG_SECURITY_SELINUX=y 的配置项

 

2. 在sepolicy中添加相应权限

2.1 修改依据

log 信息:

avc: denied  { 操作权限  }  for pid=7201  comm=“进程名”  scontext=u:r:源类型:s0  tcontext=u:r:目标类型:s0  tclass=访问类别  permissive=0

2.2 修改步骤：

找相应的“源类型.te ”文件
有两个位置可能存在相应的te文件：
位置一：LINUX/android/external/sepolicy
位置二：LINUX/android/device/qcom/sepolicy/common 

2.3 按如下格式在该文件中添加： 

allow  源类型 目标类型:访问类别 {权限}；

2.4 举例

Kernel Log：

avc: denied { execheap } for pid=7201 comm="com.baidu.input" scontext=u:r:untrusted_app:s0tcontext=u:r:untrusted_app:s0tclass=processpermissive=0

修改：

在LINUX/android/external/sepolicy/untrusted_app.te 中添加：

allow untrusted_app untrusted_app:process { execheap };

备注:

在这个例子中，由于源类型和目标类型都是untreated_app, 所以也可以写成：

allow untrusted_app self:process { execheap };

3. 添加权限后的neverallowed冲突

3.1 编译报错：

libsepol.check_assertion_helper: neverallow on line xxx ofexternal/sepolicy/domain.te ……

3.2 原因：

新添加的sepolicy项目违反了domain.te 中规定的的总策略原则。所以该条权限策略不能添加，如果强行添加的话有CTS测试失败的风险。

3.3 解决方法：

1.从运行log中找到要访问的目标名称，一般是name字段后的名称
avc: denied { read write } for pid=303 comm="mediaserver" name="tfa9890"dev="tmpfs" ino=3880 scontext=u:r:mediaserver:s0tcontext=u:object_r:device:s0tclass=chr_file permissive=0

2.找到相应的*_contexts文件。

  一般有file_contexts, genfs_contexts,  property_contexts,  service_contexts 等文件

3.在contexts文件中指定要访问的目标为一个“源类型 ”有权限访问的“目标类型”
  如：在file_contexts中添加： /dev/tfa9890     u:object_r:audio_device:s0

3.4 举例

添加权限：

在mediaserver.te中添加allow mediaserver device:chr_file { read write open};

编译报错：

libsepol.check_assertion_helper: neverallow on line 258 ofexternal/sepolicy/domain.te (or line 5252 of policy.conf) violated byallow mediaserver device:chr_file { read write open};

违反了domain.te 258的：

neverallow {domain –unconfineddomain –ueventd } device:chr_file { open read write}

运行Log：

avc: denied { read write } for pid=303 comm="mediaserver"name="tfa9890" dev="tmpfs" ino=3880 scontext=u:r:mediaserver:s0 tcontext=u:object_r:device:s0tclass=chr_file permissive=0

修改步骤：
1.目标名称是： tfa9890, 其在系统中的路径是： /dev/tfa9890,  是audio相关的设备文件
2.源类型是mediaserver, 在mediaserver.te 文件中发现其具有 audio_device 目标类型的权限
3.所以在file_contexts 中添加 “/dev/tfa9890        u:object_r:audio_device:s0” 可以解决问