Android SElinux权限添加，NeverAllow，未生效等全解（超详细）

目录

• 1. 概述
• 2. 定位所需权限
• 3. 配置所需权限
• • 3.1 配置想要使用当前操作的对象
  • • 3.2 编译并替换
    • 4. 常见的异常
    • • 4.1 编译neverallow
      • • 4.1.1 自定义权限
        • 4.2 运行不生效

          1. 概述

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

          2. 定位所需权限

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

          如下是一条报错

          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

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

          3. 配置所需权限

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

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

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

          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

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

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

          3.2 编译并替换

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

          4. 常见的异常

          4.1 编译neverallow

            这种报错出现的原因往往是由于当前我么添加的SElinux权限违反谷歌规定的Neverallow规则。  这时有两种解决方式，一种是暴力型，一种是规范型。  暴力性的话我们就根据报错中的提示，将对应的neverallow规则注释掉即可。  ！！！！！！！！切记，这种操作可能会影响各类认证（CTS、VTS）以及其它未知风险！！！  接下来讲一下如何规范的处理。  出现这种情况往往是因为我们申请权限时，我们放大了我们所需的权限。  举个例子：我们现在需要的一种操作是：能够让我们的app 能够 读写 Led灯的驱动文件节点。 但是我们在申请权限时对应的命令往往会是如下命令：         allow untrusted_app devices:file {open read write};  我们按照字面意思理解一下，就是所有未被信任的app都拥有对所有设备节点（devices：file）的文件的读写权限。显然这样是不安全的。  那我们该如何解决呢？那就需要自定义一个权限。比如我们可以将我们需要操作的Led驱动文件节点自定义为一个单独的权限。然后我们只申请这一个权限。  接下来我们来介绍如何进行操作。

          4.1.1 自定义权限

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

          sdm660_64:/ # ls -Z /dev/moto_sdlu:object_r:device:s0 /dev/moto_sdl

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

          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:s0private/file_contexts:73:/dev(/.*)?             u:object_r:device:s0

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

          sdm660_64:/ # ls -Z /dev/moto_sdlu:object_r:sdl_device:s0 /dev/moto_sdl

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

          4.2 运行不生效

          参考该博客