Android的root与selinux

在Linux中，拥有root的权限等于拥有了无上权利，但是会被selinux限制。

在Android中，我们通过下面两个问题去简单理解下root的含义：

1.怎样的进程算是有了root的权限呢？

2.为什么在终端adb root或者su之后，不受到selinux限制

怎样的进程算是有了root权限呢？

adb shell默认执行cmd wifi get-ipreach-disconnect 的时候会出现如下错误

image.png

为什么执行adb root或者su之后就可以正常执行了？

image.png

可以看到在su之后，shell的执行权限会变为root，对应的代码如下

image.png

我们再来看看cmd wifi get-ipreach-disconnect 中进行权限检测的地方

image.png

那么代码里面是通过什么去判断这个进程是root进程呢？

通过uid是否为0去判断，从Process.java中的定义，我们可以看到uid为0表示root。

所以我们认为uid为0的进程就是root进程，具备root权限。

为什么在终端adb root或者su之后，不受到selinux限制？

Android11的设备有个ro.virtual_ab.enabled属性来标识是否开启的虚拟AB。

在默认adb shell下，无法获取到这个属性

image.png

但是在我们把selinux关闭，回到非su状态后再获取，发现能够获取到了，说明这个属性受到selinux的管控，shell这个domain默认无法获取selinux

image.png

但是在我们执行su后，即使重新开启selinux限制，仍旧可以获取到属性

image.png

不是说selinux是限制root权限的吗，那么这里为什么root之后不受到selinux权限的控制了？

我们来看看su或者adb root后domain的变换。

默认shell属于shell这个domain，所有在shell下执行的命令，都会以shell这个domain执行，所以会应用shell.te中定义的规则

image.png

但是在执行su之后，所以在shell执行的命令，都会以su这个domain执行。

image.png

但是我并没有看到su.te中对属性的相关授权配置，为什么su这个domain在这里就可以忽略selinux呢？

我们看到adb root或者su后, shell的domain会切换为su，su.te中通过permissive su，是的su这个domain可以不被selinux监管

所以在su后才能在selinux开启下顺利访问ro.virtual_ab.enabled。

image.png