Android SElinux权限添加，NeverAllow，未生效等全解（超详细）_android selinux解决neverallow报错

1. 概述

我以我自己的方式来理解SELinux
SELinux有如下四个重要参数：
  操作权限
  想要使用改操作的对象类型
  操作的原始拥有者
  操作要操作的文件类型
1
2
3
4
5
6

2. 定位所需权限

首先我们进入adb ， adb root，setenforce 0
然后抓取log（adb shell dmesg > log.txt），检索关键字avc
1
2

如下是一条报错

avc: denied { search }      //{}中的是缺少的操作权限
for name="leds" dev="sysfs" ino=27484 
scontext=u:r:untrusted_app  //scontext=u:r: 之后的内容是想要使用当前操作的对象
:s0:c141,c256,c512,c768 
tcontext=u:object_r:sysfs_leds//object_r: 之后是当前操作的原始拥有者
:s0 tclass=dir // 操作要操作的文件类型
permissive=0 app=com.android.ledcontrol
1
2
3
4
5
6
7

现在我们知道了如上信息之后就可以进行下一步了。

3. 配置所需权限

咱们就以上述报错来进行对应配置
1

3.1 配置想要使用当前操作的对象

  首先定位到日志中的''scontext=u:r:untrusted_app''，这里意味着我们需要在“untrusted_app”对
应的.te文件中加入所需权限。我们可以到源码目录device/*/sepolicy中运行
“find . -name untrusted_app.te”
1
2
3

QiTianM437-A603:/work/FH16/device/qcom$ find . -name untrusted_app.te
./sepolicy/generic/vendor/test/untrusted_app.te
./sepolicy/legacy/vendor/common/untrusted_app.te
./sepolicy/legacy/vendor/sdm710/untrusted_app.te
./sepolicy/qva/vendor/common/untrusted_app.te
./sepolicy/qva/private/untrusted_app.te
1
2
3
4
5
6

  我们可以找到如上所示的对应文件。我们按照当前平台信息找到对应的te，就可以进行添加权限了。
    格式如下： 
1
2

allow [需要添加权限的对象] [权限拥有者]:[操作类型] {[权限类型]};
对应上述日志即：
allow untrusted_app sysfs_leds:dir {search};
1
2
3

3.2 编译并替换

  使用该命令进行编译：make selinux_policy
  		注：  此时编译可能会遇到neverallow的编译报错，详细解法可以看下一章内容。
  生成文件路径：$(OUT_TARGET)/vendor/etc/selinux/precompiled_sepolicy
  替换对应文件，重启即可。当然有时候可能你替换之后仍然无法完成你想要的操作。
你需要再去抓log看看是不是还有其它avc报错。
       注：  如已经按照上述操作添加过权限后，还是会有avc报错，这是可见下一章对应内容。
1
2
3
4
5
6

4. 常见的异常

4.1 编译neverallow

  这种报错出现的原因往往是由于当前我么添加的SElinux权限违反谷歌规定的Neverallow规则。
  这时有两种解决方式，一种是暴力型，一种是规范型。
  暴力性的话我们就根据报错中的提示，将对应的neverallow规则注释掉即可。
  ！！！！！！！！切记，这种操作可能会影响各类认证（CTS、VTS）以及其它未知风险！！！


  接下来讲一下如何规范的处理。
  出现这种情况往往是因为我们申请权限时，我们放大了我们所需的权限。
  举个例子：我们现在需要的一种操作是：能够让我们的app 能够 读写 Led灯的驱动文件节点。
 但是我们在申请权限时对应的命令往往会是如下命令：
         allow untrusted_app devices:file {open read write};
  我们按照字面意思理解一下，就是所有未被信任的app都拥有对所有设备节点（devices：file）的文件的读写权限。显然这样是不安全的。
  那我们该如何解决呢？那就需要自定义一个权限。比如我们可以将我们需要操作的Led驱动
文件节点自定义为一个单独的权限。然后我们只申请这一个权限。
  接下来我们来介绍如何进行操作。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

4.1.1 自定义权限

	首先我们需要确定当前我们所操作的文件的类型。
	比如我们需要操作的是/sys/class/leds/brightness文件。我们可以到当前目录下运行“ls -Z”
	结果如下：
1
2
3

sdm660_64:/ # ls -Z /dev/moto_sdl
u:object_r:device:s0 /dev/moto_sdl
1
2

我们可以去system/sepolicy/ 或者device/*/sepolicy 目录下检索关键字“u:object_r:device:s0”
1

QiTianM437-A603:/work/FH16/system/sepolicy$ grep -rns "u:object_r:device:s0"
prebuilts/api/33.0/private/file_contexts:73:/dev(/.*)?        u:object_r:device:s0
private/file_contexts:73:/dev(/.*)?             u:object_r:device:s0
1
2
3

  我们可以看到，在这里我们将所有/dev下的文件都定义为了device类型。因此我们在这两个文件下添加如下内容：
  /dev/moto_sdl           u:object_r:sdl_device:s0
  然后再在device.te中定义我们自定义权限的权限类型：
  type sdl_device, dev_type, mlstrustedobject
 如上我们便完成了权限的自定义过程。编译后我们再运行ls -Z，就会发现变为了：
1
2
3
4
5

sdm660_64:/ # ls -Z /dev/moto_sdl
u:object_r:sdl_device:s0 /dev/moto_sdl
1
2

然后重新按照第一步开始，重新配置一下，即可解决该问题。
1

4.2 运行不生效

参考该博客