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

目录

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

          1. 概述

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

          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_sdl
          u: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:s0
          private/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_sdl
          u:object_r:sdl_device:s0 /dev/moto_sdl
          

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

          4.2 运行不生效

          参考该博客