标签:
一、案例
我们举个案例,比如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权限了。
Android6.0 selinux没有对某个文件的权限(又neverAllow)处理方法
标签:
原文地址:http://www.cnblogs.com/changyuet/p/5580401.html