Understanding and Using SEBOOL Settings in Tech Support

What Are SEBOOLs?

SELinux (Security-Enhanced Linux) operates using a set of rules called the Mandatory Access Control (MAC) policy. Within this framework, sebool stands for SELinux Boolean. These are simple true/false switches that control granular aspects of the security policy. Instead of modifying complex binary policy modules, administrators can enable or disable these booleans to adjust behavior.

For example, by default, the Apache web server (httpd) cannot read files labeled with the user_home_t context, which typically protects user home directories. If you need your web server to serve content from a user's home directory, you do not need to rewrite the entire SELinux policy. You simply enable the boolean httpd_read_user_home. This approach is safer and more maintainable than disabling SELinux entirely or creating custom policies for every minor exception.

Locating and Interpreting Alerts

When an application is blocked by SELinux, the system generates an alert known as an AVC (Access Vector Cache) denial. These logs are critical for diagnosing why a service is failing. The primary location for these alerts is the audit log, typically found at /var/log/audit/audit.log.

To find relevant entries, use the ausearch command filtered by the application name. For instance:

ausearch -m avc -ts recent

This output will show the process ID, the target file, and the specific permission denied (such as read, write, or execute). Often, the system will also provide a hint suggesting which boolean might resolve the issue. Look for lines containing suggestion in the audit log. A typical message might state: "Suggestion: if you want to allow httpd to read user home directories, then you must tell SELinux about this by enabling the 'httpd_read_user_home' boolean."

If you are dealing with network-related issues, such as those described in our guide on Troubleshooting kex_exchange_identification Error in Linux SSH Connection, similar AVC denials may appear when SSH attempts to bind to non-standard ports or connect to external services restricted by policy.

Managing Booleans with semanage

The standard tool for viewing and modifying SELinux booleans is semanage. Before making changes, it is best practice to view the current state of all booleans to understand the baseline configuration.

semanage boolean -l | grep httpd

This command lists all booleans related to the HTTPD service, showing their current state (on/off) and whether they are persistent across reboots. To change a boolean, use the -m (modify) flag. There are two modes of operation: permanent and transient.

For a permanent change that survives a reboot, use the --set option combined with the --persistent flag:

sudo semanage boolean -m --set httpd_read_user_home on --persistent

Alternatively, you can use the setsebool command, which is simpler but requires careful handling of persistence. By default, setsebool only changes the running state. To make it persistent, you must add the -P flag:

sudo setsebool -P httpd_read_user_home on

If you forget the -P flag, the setting will revert to its previous state after the next system restart. Always verify the change with getsebool to ensure the new value is active and persistent.

Best Practices for Boolean Usage

• Use Specific Booleans: Avoid broad booleans like httpd_unified if a narrower one exists. Granularity reduces the attack surface.
• Check Dependencies: Some booleans depend on others. Enabling one might automatically enable another. Use semanage boolean -l to see dependencies.
• Document Changes: Keep a record of which booleans you have enabled. This helps during audits and troubleshooting later.

Understanding the relationship between process contexts and file contexts is essential. As detailed in Understanding SELinux Security Context Labels for a Process, knowing how labels interact helps predict which booleans will actually resolve a given denial.

Troubleshooting Common Issues

Even with correct boolean settings, issues may persist due to incorrect file labeling or service restart requirements. After changing a boolean, some services require a restart to pick up the new policy. For systemd services, use:

sudo systemctl restart httpd

If the issue remains, check the audit log again. It is possible that the boolean did not cover the specific action causing the denial. In such cases, you may need to create a custom policy module using audit2allow. However, this should be a last resort, as custom modules bypass the standardized boolean management system.

Another common pitfall involves unprivileged users attempting to load kernel modules or modify driver states. As noted in our analysis of Unprivileged Users and INMOD Driver Use in Linux: Not Recommended, certain low-level operations are strictly prohibited regardless of boolean settings. SELinux enforces these restrictions at the kernel level, so no boolean can override them safely.

Frequently Asked Questions

How do I list all SELinux booleans?

Use the command semanage boolean -l to display a comprehensive list of all available booleans, their current status, and their persistence settings. You can pipe this through grep to filter for specific services like httpd or ftpd.

What is the difference between setsebool and semanage boolean?

setsebool is a legacy command that modifies the runtime state of booleans. While it can be made persistent with the -P flag, semanage boolean is the preferred modern tool because it explicitly manages the persistent configuration stored in the SELinux policy database, ensuring clarity and reliability.

Why does my service still fail after enabling a boolean?

Enabling a boolean allows the policy to permit the action, but it does not automatically restart the service. You must restart the affected service using systemctl restart [service_name] so it re-initializes with the updated security context. Additionally, verify that the file contexts are correctly labeled.

Can I disable SELinux completely instead of using booleans?

While possible, disabling SELinux removes all mandatory access controls, significantly increasing the risk of system compromise. It is strongly recommended to use booleans or custom policies to grant necessary permissions rather than turning off the security framework entirely.

How do I find out which process was killed by OOM killer?

If you suspect memory issues alongside SELinux problems, check the kernel ring buffer using dmesg | grep -i oom. For a deeper dive into identifying the specific process, refer to our guide on How to find out exactly which process was killed by OOM killer? to correlate resource usage with access denials.