How to analyze SELinux problems and add sepolicy correctly

The first step is to determine if the issue is related to SELinux, comand:adb Shell Setenforce 0 (This step requires root) to turn off the selinux mechanism of the phone, if the problem can be reproduced, then this issue is not related to SELinux, or related but also with Other mechanisms, such as those related to Linux autonomic access control (DAC). After you close selinux, use adb shell getenforce to confirm that SELinux is properly closed: [email protected]:~/desktop/workspace/u50plustmo$ adb Shell Getenfo RCE Enforcing//indicates that the SELINUX mechanism is enabled [email protected]:~/desktop/workspace/u50plustmo$ adb shell Setenforce 0 [email protected ]:~/desktop/workspace/u50plustmo$ adb shell Getenforce Permissive//indicates that the SELINUX mechanism is off

Permissive Mode logs log only through the Audit System, but does not actually intercept access. Enforcing Mode also really intercepts access while printing LOG.


The second step is to confirm that the SELINUX is relevant and then you can grab log to view the Avc:log in the log file.

Iconic log:avc:denied {operation permissions} for pid=7201 comm= "process name" SCONTEXT=U:R: Source Type: S0 tcontext=u:r: Target type: s0 tclass= access Type permissive=0


In the corresponding source type. te file, add a line of statements in the following format: (Don't forget the semicolon) format: Allow source Type target type: Access type {operation permission};


As follows: 07-10 14:06:32.780 9043 9043 W com.filemanager:type=1400 Audit (0.0:104): avc:denied {read} for name= "U:object_r:cu Ref_set_prop:s0 "dev=" Tmpfs "ino=1334 scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:curef_set_prop:s0 Tclass=file permissive=0

You can get the following sepolicy: Add to Platform_app.te file allow Platform_app curef_set_prop:file {read};

It should be noted that the SELinux and Linux DAC mechanism will detect whether the process has permission to read and write the executable file, can not be detected through the SELinux permissions detected by the DAC permission, and the two detection is not in order, not only through the DAC detection will be the SEL Inux detection, even if not through the DAC detection, will also perform SELINUX detection, so in the analysis of Android permissions issues must be taken into account in both respects.

I recently overlooked the Linux DAC mechanism (autonomous access control) at the outset when I was analyzing a permissions problem. So the analysis of the problem should also pay attention to the corner of thinking, the best way to break the corner of thinking is to find someone to discuss. Brainstorming tends to get good results.

How to analyze SELinux problems and add sepolicy correctly