First, case
Let's take a case, like the recovery upgrade, hit this log
[HTML]View PlainCopy  
 
  
  - 01-01 08:03:22.410000   217    217 w applypatch: type=1400 audit ( 0.0:16):  avc: denied { read } for name=" MMCBLK0P15 " dev=" TMPFS " < span class= "attribute" >ino=3364 scontext=u:r:install_recovery:s0 tcontext= U:object_r:block_device:s0 tclass=blk_file < span class= "attribute" >permissive=0&NBSP;&NBSP;     
Description Install_revovery does not have Block_device permissions.
In the native Domain.te file, it is clear that there is no read and write permission to Block_device in domain, except for recovery vold.
[HTML]View PlainCopy  
 
  
  - Neverallow {Domain-kernel-init-recovery-vold-uncrypt-emsd-rild-radio_config} block_device:blk_file {Open read WR ITE};
Second, Method 1 (subsequent CTS test will be problematic)
Then we how to be good, can in above this sentence Nevera the install_recovery also subtract, then add the corresponding allow in Install_recovery.te again, this time compiles will not error.
However, this method will not be able to follow the CTS test.
So we can't take this approach.
Third, Method 2
So we have to think of another way, we found that in Domain.te also has the following sentence, is allowed to Install_recovery to write Recover_block_device permission.
[HTML]View PlainCopy  
 
  
  - ./domain.te:354:neverallow {Domain-install_recovery-recovery} recovery_block_device:blk_file write;
So we'll check block_device and Recover_block_device.
[HTML]View PlainCopy  
 
  
  - Type Recovery_block_device, Dev_type;
[HTML]View PlainCopy  
 
  
  - Type Block_device, Dev_type;
The two are of the same type.
But let's see file_contexts, look at the file security context.
[HTML]View PlainCopy  
 
  
  - /dev/block (/.*)? U:object_r:block_device:s0
The Dev/block file below is defined as Block_device, and Recover_block_device is undefined. Then we can also define the file we want to manipulate as the Recover_block_device type.
The answer must be yes.
[HTML]View PlainCopy   
 
  
  - /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
We can also define our own files for the Recover_block_device type, feeling that this is reserved for Android to everyone.
Concrete implementation is not said, because the specific operation of what the file is not too clear, this is just a log.
Finally, we just have to add the following permissions in the Install_recovery.te.
[HTML]View PlainCopy  
 
  
  - Allow Install_recovery recover_block_device:blk_file {open Read write};
This install_recovery has the open Read Write permission for the target file.
Android6.0 SELinux does not have permission to a file (and Neverallow) processing method