More or less experience in the development of Android system related problems of some Selinux, where some summarize and organize, the source of most of the content network.
1, to understand the basic concepts of SELinux, a lot of this information online, with particular reference to:
http://jingpin.jikexueyuan.com/article/55398.html
http://blog.csdn.net/innost/article/details/19299937/
http://blog.csdn.net/luoshengyang/article/details/37613135
http://www.2cto.com/kf/201504/390742.html
http://www.th7.cn/system/lin/201512/147098.shtml
2, the acknowledgment status Selinux
2.1 can be turned off manually SELinux, confirm whether the problem is caused by the authority, the specific method:
See SELinux Status:
. 1) / usr / sbin / sestatus -v ## if SELinux Status parameter is the ON state to enabled
SELinux Status: enabled
2) getenforce ## can also check with the command
Close SELinux 2.2:
temporarily closed (not reboot):
the setenforce 0 ## disposed SELinux become permissive mode
## setenforce 1 be provided SELinux enforcing mode
3, grasping dmesg log, the system converts the lack of policy
log the dmesg:
the dmesg | grep rpcServer
[8.132704] the init: Starting-Service 'rpcServer' ...
[12.936186] type = 1400 Audit (1,449,623,772.120: 13 is): AVC: Read denied {174} for PID = COMM = "rpcServer" name = "mmcblk0p1" dev = "tmpfs" ino = 8105 scontext = u: r: rpcServer: s0 tcontext = u: object_r: block_device: s0 tclass = blk_file permissive = 0
example above this log, you need to be able to understand what it means: read permissions original process (scontext) needs of the target (tcontext) process tclass attributes
we can see the files related to the specific device attributes ls -Z, ps -Z, ls -l, etc.
4, how to add the required permissions (this can be divided into three classes to handle)
1) The first type is relatively simple, the conversion module corresponding to the missing policy (.te file) by other tools audit2allow
added to sepolicy / rpcServer.te:
allowrpcServer block_device: Read blk_file; respectively above allow scontext tcontext: tclass read
2) The second category, there are some policy add to the mix, the system will compile time error, because the conversion of our top policy are generally a process that has the permissions of the device's file so that this authority is too large, and google security policy (under external / sepolicy neverallow) want conflict. In this case, we need to find out which specific device file permissions of the original process what you really need, can be resolved
added:
first in sepolicy / file_contexts defined mmcblk0p1 device node: / dev / block / mmcblk0p1 u : object_r: rpc_block_device: s0
add the device node in sepolicy / rpcServer.te permissions: allow rpcServer rpc_block_device: blk_file read;
3）
Properties of the original process (root, radio, system, etc.) and the file does not match the target device, in which case we will map does not work. In this case, you need to modify the init.rc and ueventd.rc inside the appropriate attributes:
I check down here is an example of the problem:
vmodem Driver IS SO not of Able openthe Partitions NVM NVM default values are expected Issue IS with permissionmis-match.:
vmodem driver context is "radio" and block device nodes are "root"
Because mmcblk0p1 Nvm Calculate Static modem is used, rpcServer no authority to mount, first rpcServer and equipment mmcblk0p1 are set to the same set of radio properties:
ueventd.rc file in:
/ dev / Block / Radio Radio mmcblk0p1 0660
/ dev / vmodem 0660 Radio Radio
init.rc and init.ptest.rc files, system / bin / rpcServer the user, group attributes into the root Radio:
chown Radio Radio / SYS / class / Misc / vmodem / modem_state
-Service rpcServer / System / bin / rpcServer
Socket msmSock Stream 660. Radio System
Core class
User Radio
Group Radio
was then added to the kernel and rights rpcServer mmcblk0p1 device:
in sepolicy / file_contexts defined mmcblk0p1 device node: / dev / Block / mmcblk0p1
U: object_r: rpc_block_device: S0
in sepolicy / kernel.te: allowkernel rpc_block_device: blk_file Read;
the sepolicy / rpcServer.te: the allow
rpcServer rpc_block_device: Read blk_file;
Wherein solve the above two cases is the same routine, while the third requires specific analysis according to different platforms, the corresponding device and process attributes. The following is added in a local service, the reasons leading to selinux not run as follows:
1, in init.rc added:
service xxx /system/bin/xxx
class main
user root
Burn compiled boot the machine, we found the service xxx can not start, kernel log in the following prompt:
[20.076354s] [pid: 1, the CPU 7, the init] the init: A Service xxx does not have have SELinux Domain defined.
The prompt explanation is not defined SELinux domain, resulting in self-service xxx can not start. To solve this problem we modify or add sepolicy file as follows:
Modify seplicy / file_contexts file, add the following:
/ System / bin / xxx U: object_r: xxx_exec: S0
new xxx.te file, and add the following:
the need to increase domain authority for the implementation of the new process
type xxx , domain;
of the type xxx_exec, exec_type, file_type;
then enable this field
init_daemon_domain (xxx)
verify, modify SELinux issues that need full compilation in principle, in order to save time debugging can use the following methods
to compile bootimage
burn bootimage
execute adb remount
execute adb shell restorecon system / bin / xxx
restart the machine to see if the service is successful start xxx in the kernel log in