Cause One: Labeling Errors The core concept of SELinux is labeling, whether it is a file system, directory, file, file startup descriptor, port, message interface, or network interface, everything Labels are required and can only be performed in accordance with the permissions granted by the label. Even if the running Apache process is hacked and has uid=0 root privileges, it still cannot access files in a user's home directory. Because the Apache process labeled httpdt cannot access the content labeled userhome_t. Therefore, SELinux will pop up a warning if there is a problem with the annotation. How to deal with this class, you can refer to the use of the semanage fcontext and restorecon commands in the previous section of this site. Of course, you can also follow the prompts in the graphical SELinux debugging tool. Reason 2: Customized program running settings After years of development, SELinux has accumulated a large number of policy files, and records the default running requests for most applications, and can give appropriate minimum permissions to execute. However, if you have customized some running configurations or have special application requirements, you will need to adjust some SELinux settings. For most common customization requirements, SELinux is controlled by Boolean values. See the previous section on the use of the setsebool command. To see all the adjustable SELinux Boolean values, use the semanage boolean -l command. This can be solved with the graphical SELinux debugging tool or with the graphical system-config-selinux. Cause three: There is a problem with the SELinux policy or application configuration. If you have not specifically modified the configuration and still receive the SELinux warning, the reason may be in the SELinux policy or the application itself. It is recommended that you first submit an error report with the help of the SELinux Debugging Tool and then proceed as appropriate. If it has already been reported, it will usually be resolved in detail in the comments of the error report. At this point, if you want to ignore the SELinux warning and still run the application, there are several ways: Set SELinux to allow mode, only log warnings but not run: setenforce 0. Set a single annotation process to allow mode instead of the entire system, for example, just want to run Apache in allow mode: semange permissive -a httpd_tCreate and load a custom policy with reference to the SELinux debug tool recommendations. The specific process varies from case to case, and there are detailed instructions in the SELinux debugging tool. Reason 4: The program has been compromised SELinux is not an intrusion detection system, so the current SELinux debugging tool can not actively identify the intrusion attempt, but when you find that the warning content contains the following characteristics, it is likely that the corresponding process has been hacked: Try turning off SELinux (/etc/selinux) or setting a SELinux Boolean value. Try to load the kernel module, write to the kernel directory, or boot the image. Try to read the file identified by shadow_t, which usually contains encrypted account information. Try to overwrite the write to the log file. Try to connect to an unwanted random port or mail port. At this point, the four common warning reasons are introduced, and I hope that you can handle it safely and effectively the next time you encounter a SELinux warning. By the way, the localization of most SELinux debugging tools has been resolved, and the children's shoes in Jane will be able to see the warnings in Jane.