Android6.0 selinux没有对某个文件的权限（又neverAllow）处理方法

一、案例

我们举个案例，比如recovery升级中，碰到这个的log

01-01 08:03:22.410000   217   217 W applypatch: type=1400 audit(0.0:16): avc: denied { read } for name="mmcblk0p15" dev="tmpfs" ino=3364 scontext=u:r:install_recovery:s0 tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0

说明install_revovery没有block_device的权限。

而在原生的domain.te文件中，明确domain中是没有对block_device的读写权限，除了recovery vold等。

neverallow { domain -kernel -init -recovery -vold -uncrypt -emsd -rild -radio_config} block_device:blk_file { open read write };

二、方法1（后续cts测试会有问题）

那我们如何是好呢，可以在上面这句nevera中把install_recovery也减去，然后再install_recovery.te中再加入相应的allow，这个时候编译就不会报错了。

但是这个方法，后续会在cts测试的时候过不了。

因此我们不能采取这种方法。

三、方法2

所以我们得想别的方法，我们发现在domain.te中同样有下面这么一句，是可以允许install_recovery去写recover_block_device的权限。

./domain.te:354:neverallow { domain -install_recovery -recovery } recovery_block_device:blk_file write;

于是我们再去查block_device 和 recover_block_device

type recovery_block_device, dev_type;

type block_device, dev_type;

这两个的类型一致。

但我们再看file_contexts，看下文件安全上下文

/dev/block(/.*)?u:object_r:block_device:s0

定义的dev/block下面的文件都是block_device，而recover_block_device是没有定义的。那我们也能不能定义我们要操作的文件为recover_block_device类型。

答案肯定是可以的。

/dev/block(/.*)?u:object_r:block_device:s0/dev/block/dm-[0-9]+u:object_r:dm_device:s0/dev/block/loop[0-9]*u:object_r:loop_device:s0/dev/block/vold/.+u:object_r:vold_device:s0/dev/block/ram[0-9]*u:object_r:ram_device:s0

我们也可以自己定义自己的文件为recover_block_device类型，感觉这是android给大家预留的。

具体实现就不说了，因为具体要操作什么文件不是太清楚，这只是一个log而已。

最后我们只要在install_recovery.te中加入下面权限就可以了。

allow install_recovery recover_block_device:blk_file { open read write };

这样install_recovery就有了目标文件的open read write权限了。