Manage SELinux File Contexts for Apache in Linux

Introduction

In this lab, you will learn how to manage SELinux file contexts to ensure services like the Apache web server can access necessary files. You will explore how Security-Enhanced Linux (SELinux) applies security labels, known as contexts, to files and how mismatched contexts can lead to access denial errors, even when standard file permissions appear correct. This hands-on experience is designed to build your practical skills in troubleshooting common security issues in a Linux environment.

Throughout the steps, you will install Apache, verify SELinux is in enforcing mode, and observe the default context of a correctly placed web page. You will then intentionally trigger a "Forbidden" error by moving a file with an incorrect context into the web root directory. To resolve this, you will use the chcon command to relabel the file, demonstrating a fundamental method for fixing SELinux context-related problems and restoring service functionality.

Install Apache and Verify SELinux is Enforcing

In this step, you will begin by ensuring your environment is correctly configured. This involves verifying that Security-Enhanced Linux (SELinux), a critical security module in the Linux kernel, is running in enforcing mode. Then, you will install the Apache web server, which will be used throughout this lab to demonstrate how SELinux contexts work.

First, let's check the status of SELinux. You can do this with the sestatus command, which provides a detailed overview, or the getenforce command for a direct answer.

Run getenforce to see the current mode:

getenforce

The command should return Enforcing, which means SELinux is actively protecting your system.

Enforcing

If it returns Permissive, SELinux is logging warnings but not blocking actions. If it returns Disabled, SELinux is completely turned off. For this lab, it must be Enforcing. Your lab environment is pre-configured to be in Enforcing mode.

Next, you will install the Apache web server, known by its package name httpd on CentOS/RHEL systems. Use the yum package manager to install it. The -y flag automatically answers "yes" to any confirmation prompts.

sudo yum -y install httpd

You will see output as yum resolves dependencies and installs the packages. A successful installation will end with a "Complete!" message.

...
Installed:
  httpd-2.4.x-xx.el8.x86_64
  ...
Complete!

After the installation is complete, you need to start the Apache service to make it run. Use systemctl to manage the service.

sudo systemctl start httpd

To confirm that the Apache service is running correctly, check its status:

sudo systemctl status httpd

The output should show that the service is active (running).

● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: active (running) since ...
   ...

Press q to exit the status view and return to the command prompt. Your environment is now ready for the next steps.

Create a Web Page and Verify its Default SELinux Context

In this step, you will create a simple web page and serve it using the Apache server you just installed. This process will demonstrate how SELinux automatically assigns the correct security context to files created in specific, policy-defined directories, allowing services to access them without issue.

The default directory for web content on Apache is /var/www/html. Any file placed here should be accessible via a web browser if its permissions and SELinux context are correct.

Let's create a simple index.html file directly inside /var/www/html. Since this directory is owned by the root user, you must use sudo to write to it. A standard sudo echo command with redirection (>) won't work because the redirection is handled by your current shell, which lacks permission. To solve this, you can run the command within a root shell using sudo sh -c '...'.

Execute the following command to create the file:

sudo sh -c 'echo "Welcome to Apache on LabEx" > /var/www/html/index.html'

Now, let's verify that the web server can access and serve this new page. You can use curl, a command-line tool for transferring data with URLs, to request the page from localhost.

curl http://localhost

You should see the content of your index.html file printed to the terminal, confirming that Apache is working and can read the file.

Welcome to Apache on LabEx

So, why did this work seamlessly? The answer lies in the file's SELinux context. When you create a file, SELinux assigns it a context based on the parent directory's policy. Let's inspect the context of the index.html file you just created using the ls -Z command. The -Z option shows the SELinux security context.

ls -Z /var/www/html/index.html

The output will look similar to this:

system_u:object_r:httpd_sys_content_t:s0 /var/www/html/index.html

The most important part of this output is the context label: system_u:object_r:httpd_sys_content_t:s0. This label is composed of four parts: user:role:type:level. For this lab, we are focused on the type, which is httpd_sys_content_t.

The SELinux policy for Apache (httpd) explicitly allows processes running with the httpd_t type to access files labeled with the httpd_sys_content_t type. Because you created the file directly in /var/www/html, it inherited the correct default context, and everything worked as expected.

Trigger an SELinux Denial by Moving a File with an Incorrect Context

In this step, you will see what happens when a file with an incorrect SELinux context is moved into the Apache web directory. This is a common scenario that can be confusing if you are not aware of how SELinux contexts work with file operations like mv. Unlike creating a file directly in a directory (which causes it to inherit the parent's default context), moving a file preserves its original context.

First, let's create a new web page, page2.html, in your current working directory, ~/project.

echo "This is Page 2" > page2.html

Now, check the SELinux context of this new file. Since it was created in your home project directory, it will receive a default context assigned to user files.

ls -Z page2.html

The output will show a context type of user_home_t or something similar, which is the default for files in a user's home directory.

system_u:object_r:user_home_t:s0 page2.html

Notice the type is user_home_t. This is different from the httpd_sys_content_t that Apache is allowed to access.

Next, move this file to the Apache web root using the mv command. You'll need sudo because the destination directory /var/www/html is owned by root.

sudo mv page2.html /var/www/html/

The mv command preserves the source file's SELinux context. Let's verify this by checking the context of the file in its new location.

ls -Z /var/www/html/page2.html

As you can see, the context has not changed. It is still user_home_t, even though the file is now in the /var/www/html directory.

system_u:object_r:user_home_t:s0 /var/www/html/page2.html

Now, try to access this new page using curl. SELinux will block the access due to the context mismatch.

curl http://localhost/page2.html

You will receive a "403 Forbidden" error from the server. This is not a traditional file permission issue; it is SELinux enforcing its security policy and denying the httpd process from reading a file with the user_home_t label.

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>403 Forbidden</title>
</head><body>
<h1>Forbidden</h1>
<p>You don't have permission to access /page2.html
on this server.</p>
</body></html>

This demonstrates a classic SELinux problem. In the next step, you will learn how to fix this by changing the file's context.

Correct the File Context with chcon and Verify Access

In this step, you will resolve the "403 Forbidden" error from the previous step by manually changing the SELinux context of the page2.html file. You will use the chcon (change context) command, a powerful tool for modifying the security context of files and directories.

The chcon command allows you to directly alter the user, role, type, or level of an SELinux context. For this exercise, you only need to change the type. The correct type for web content that Apache can read is httpd_sys_content_t.

To fix the issue, you will use chcon with the -t flag to specify the new type for page2.html. Since the file is located in /var/www/html, you will need to use sudo to modify its context.

Run the following command to update the SELinux type of page2.html:

sudo chcon -t httpd_sys_content_t /var/www/html/page2.html

Now that you've executed the command, let's verify that the context has been updated. Use ls -Z again to inspect the file's security context.

ls -Z /var/www/html/page2.html

The output should now show that the type has been changed from user_home_t to httpd_sys_content_t.

system_u:object_r:httpd_sys_content_t:s0 /var/www/html/page2.html

With the correct SELinux context in place, Apache should now be able to access and serve the file. Let's test this by making another request with curl.

curl http://localhost/page2.html

This time, the command should succeed, and you will see the content of your web page printed to the terminal.

This is Page 2

You have successfully diagnosed and resolved an SELinux-related access issue. You learned that moving files preserves their original context and that chcon can be used to manually adjust the context to align with the security policy, thereby granting access to services like Apache. It's important to note that changes made with chcon may not persist through a full filesystem relabeling; the restorecon command is typically used to apply the default, policy-defined context.

Summary

In this lab, you learned how to manage SELinux file contexts for the Apache web server. You began by verifying that SELinux was in Enforcing mode and then installed and started the httpd service. You observed that files created directly within the Apache web root (/var/www/html) are automatically assigned the correct httpd_sys_content_t context, which is required for Apache to access and serve them properly.

The core of the lab demonstrated the consequences of incorrect file contexts. By moving a file from a user's home directory (with a user_home_t context) into the web root, you triggered an SELinux denial, resulting in a "403 Forbidden" error. You then learned to resolve this access issue by using the chcon command to manually change the file's context to the correct httpd_sys_content_t type, successfully restoring access and reinforcing the principle that correct file contexts are critical for services to function under an enforcing SELinux policy.