=====Investigate and Resolve SELinux Issues=====

  * Most access denials indicate that SELinux is working correctly by blocking improper actions.
  * Evaluating denied actions requires some familiarity with normal, expected service actions.
  * The most common SELinux issue is an incorrect context on new, copied, or moved files.
  * File contexts can be fixed when an existing policy references their location.
  * Optional Boolean policy features are documented in the _selinux man pages.
  * Implementing Boolean features generally requires setting additional non-SELinux configuration.
  * SELinux policies do not replace or circumvent file permissions or access control list restrictions.

Use tool from **setroubleshoot-server package** 

When Selinux denies an action an **Access Vector Cache (AVC)** is logged in **/var/log/audit/audit.log**  The SELinux troubleshooting service monitors for AVC events and sends an event summary to the /var/log/messages file.

The AVC summary includes an event unique identifier (UUID). Use the **sealert -l UUID command** to view comprehensive report details for the specific event. Use the **sealert -a /var/log/audit/audit.log** command to view all existing events.

Use the **ausearch** command to search for AVC events in the **/var/log/audit/audit.log log** file. Use the -m option to specify the AVC message type and the -ts option to provide a time hint, such as recent.

example
<code>[root@host ~]# ausearch -m AVC -ts recent </code>

You can also use the Selinux sectionb of the webconsole to diagnose and troubleshoot issues