Manage SELinux Security

In this lab, we identify issues in system log files and adjust the SELinux configuration. By conducting the following steps:

From a web browser on the workstation machine, we try to view the http://serverb/lab.html web page, but we see the error message: You do not have permission to access this resource.

We'll start by viewing the contents of the /var/log/messages files and use the / key to search for the sealert string. With that search we find the following line:

SELinux is preventing /usr/sbin/httpd from getattr access on the 
file /lab-content/lab.html. For complete SELinux messages run: 
sealert -l 9d5d9667-033c-47a6-bd26-dd7653fba3cc

We'll run the suggested sealert command with the command sealert -l 9d5d9667-033c-47a6-bd26-dd7653fba3cc 

Note: the source context, the target objects, the policy, and the enforcing mode.

The Raw Audit Messages section of the sealert command contains information from the /var/log/audit/audit.log file. We'll search the audit.log file. 

The -m option searches on the message type. 

The ts option searches based on time. 

The following entry identifies the relevant process and file that cause the alert. 

The process is the httpd Apache web server, the file is /lab-content/lab.html, and the context is system_r:httpd_t

we'll use the ausearch -m AVC -ts recent command.

We'll begin by by comparing the SELinux context for the /lab-content and /var/www/html directories

Now, we'll create a file context rule that sets the default type to httpd_sys_content_ for the /lab-content directory and all the files under it.

Then, we'll correct the SELinux context for the files in the /lab-content directory with the command restorecon -R /lab-content/

Verify that the Apache server can now serve web content. Using the http://serverb/lab.html link, we get the following successful result.

We identified that SELinux prevented the Apache service from serving web content by denying the httpd process the getattr access to the /lab-content/lab.html file. This was observed by viewing the http://serverb/lab.html web page, which showed an error message indicating no permission to access the resource. 

By examining the contents of the /var/log/messages file and running the suggested sealert command, it was discovered that the source context was system_u:system_r:httpd_t:s0, the target context was unconfined_u:object_r:default_t:s0, the target object was /lab-content/lab.html, and the policy was the targeted policy in enforcing mode. 

To fix this issue, we needed to use the semanage fcontext command to change the label on /lab-content/lab.html. By doing so, the httpd process would be allowed to have the required access to the lab.html file.