SELinux for PostgreSQL

1. A Quick SELinux Refresher

Remember from our earlier lessons that SELinux (Security-Enhanced Linux) adds a layer of security on top of standard Linux file permissions. While file permissions control which users can access files, SELinux controls which processes can access files, ports, and other processes.

Every process and file on your system has an SELinux label, called a context. SELinux enforces a policy that defines how contexts can interact. For example, a process running with the httpd_t (web server) context is, by default, not allowed to access files labeled postgresql_data_t (PostgreSQL data files). This is a good thing! It means a compromised web server can't directly tamper with your database files.

However, this also means that misconfigurations can cause SELinux to block legitimate operations. The most common issues you'll face with PostgreSQL are:

1. Incorrect File Contexts: Files have the wrong SELinux label, often after being moved or restored from a backup.
2. Policy Restrictions: The default policy prevents a necessary action, like your Django web application connecting to the database over the network.

2. Is SELinux the Problem? Finding the Evidence

Your first step in troubleshooting is to determine if SELinux is the cause of an issue. A classic sign is a "Permission denied" error when standard file permissions (ls -l) look correct.

When SELinux blocks an action, it logs an AVC (Access Vector Cache) denial. You can find these logs using a few key commands.

As the article shows, the primary tool for this is ausearch. To find recent denials related to PostgreSQL, you would run:

sudo ausearch -m avc -ts recent | grep postgres

• -m avc: Searches for AVC (denial) messages.
• -ts recent: Limits the search to the near past (e.g., the last 10 minutes).
• | grep postgres: Filters the output to show only messages containing "postgres".

If this command returns any output, SELinux has recently blocked PostgreSQL from doing something. Another helpful tool you've seen before is sealert, which can give you human-readable reports and suggestions.

3. Hands-On: Fixing File Contexts

One of the most common times you'll encounter an SELinux issue is after restoring a database from a backup, just like we did in the last lesson. If you move or copy files, they might end up with the wrong SELinux context, and PostgreSQL will fail to start.

Let's simulate this scenario and fix it.

Your Task: A File Context Fire Drill

1. Check the Correct Context: First, let's see what the correct context for PostgreSQL configuration files should be.

   
   
   
   # The `-Z` flag shows SELinux contexts
   ls -lZ /var/lib/pgsql/data/postgresql.conf
   

   You should see a context ending in postgresql_conf_t.

2. Simulate the "Bad Restore": Now, let's intentionally change the context of the main configuration file to something incorrect, like the context for files in a user's home directory.

   
   
   
   # Stop postgresql first
   sudo systemctl stop postgresql
   
   
   
   
   # Use 'chcon' to change the context temporarily
   sudo chcon -t user_home_t /var/lib/pgsql/data/postgresql.conf
   
   
   
   
   # Verify the change
   ls -lZ /var/lib/pgsql/data/postgresql.conf
   

   The context should now end in user_home_t.

3. Trigger the Failure: Try to start PostgreSQL.

   sudo systemctl start postgresql
   

   It will fail. To see why, check the status:

   systemctl status postgresql
   

   The output will likely show a generic failure. Now, let's look for the real cause.

4. Find the Denial: Use ausearch to find the SELinux denial message.

   sudo ausearch -m avc -ts recent | grep postgres
   

   You should see a log entry indicating that the postgres process was denied read access to postgresql.conf because of a type mismatch.

5. Fix the Context: The best way to fix incorrect contexts is with restorecon. This command reads the default SELinux policy rules and restores the correct contexts for files and directories.

   
   
   
   # -R is for recursive, -v is for verbose (to see what it changes)
   sudo restorecon -Rv /var/lib/pgsql/data/
   

   You should see output indicating that postgresql.conf was relabeled from user_home_t back to postgresql_conf_t.

6. Verify the Fix: Start the PostgreSQL service again.

   sudo systemctl start postgresql
   sudo systemctl status postgresql
   

   It should now start successfully!

This exercise demonstrates the fundamental workflow for fixing label-related SELinux issues: identify the problem with ausearch, and fix it with restorecon.

4. Hands-On: Allowing Network Connections with Booleans

The second major issue you'll face is allowing your web application to communicate with your database. In our deployment stack (Nginx -> Gunicorn -> Django), the Gunicorn process is often run with the httpd_t context. By default, SELinux policy does not allow the httpd_t context to make network connections to a database.

This is where SELinux booleans come in. They are simple on/off switches that allow you to tweak parts of the security policy without writing custom rules.

Your Task: Open the Port for Your Web App

1. Check the Boolean: Let's see if your system currently allows web servers to connect to databases.

   getsebool httpd_can_network_connect_db
   

   The output will likely be httpd_can_network_connect_db --> off.

2. Enable the Boolean: To allow your Django application to connect to PostgreSQL, you need to turn this boolean on.

   
   
   
   # The -P flag makes the change persistent across reboots.
   sudo setsebool -P httpd_can_network_connect_db on
   

   The -P is important; without it, the setting would reset the next time you restart your server.

3. Verify the Change: Check the boolean's value again.

   getsebool httpd_can_network_connect_db
   

   It should now be httpd_can_network_connect_db --> on.

With this single command, you have adjusted the SELinux policy to permit one of the most common and necessary operations for a web stack.

Conclusion

Great job! You've successfully navigated the intersection of PostgreSQL and SELinux. While SELinux can seem daunting at first, you've now learned a repeatable, logical process for diagnosing and resolving the most common issues a web developer will face. This knowledge is invaluable for creating a secure and functional production environment on Fedora or any other RHEL-based distribution.

Key Takeaways:

• Incorrect file contexts are a common problem after moving files or restoring backups. Use ls -Z to check contexts and restorecon to fix them based on the system's default policy.
• SELinux booleans are on/off switches for policy rules. Use getsebool to check them and setsebool -P to change them permanently.
• The httpd_can_network_connect_db boolean is essential for allowing your web application (running under an httpd_t context) to connect to your PostgreSQL database.
• Always check the audit logs with ausearch -m avc -ts recent when you suspect an SELinux issue.

Preview of the Next Lesson:
Your database is now configured, secured with user roles, protected by SELinux, and you know how to back it up. The final step is to ensure those backups happen regularly without manual intervention. In our next lesson, we will learn how to automate periodic database backups using a systemd timer, a modern and powerful way to schedule tasks on your Fedora system.