標籤:
一、案例
我們舉個案例,比如recovery升級中,碰到這個的log
[html] view plain copy
- 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等。
[html] view plain copy
- 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的許可權。
[html] view plain copy
- ./domain.te:354:neverallow { domain -install_recovery -recovery } recovery_block_device:blk_file write;
於是我們再去查block_device 和 recover_block_device
[html] view plain copy
- type recovery_block_device, dev_type;
[html] view plain copy
- type block_device, dev_type;
這兩個的類型一致。
但我們再看file_contexts,看下檔案安全上下文
[html] view plain copy
- /dev/block(/.*)? u:object_r:block_device:s0
定義的dev/block下面的檔案都是block_device,而recover_block_device是沒有定義的。那我們也能不能定義我們要操作的檔案為recover_block_device類型。
答案肯定是可以的。
[html] view plain copy
- /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中加入下面許可權就可以了。
[html] view plain copy
- allow install_recovery recover_block_device:blk_file { open read write };
這樣install_recovery就有了目標檔案的open read write許可權了。
Android6.0 selinux沒有對某個檔案的許可權(又neverAllow)處理方法