Right, so you’ve got SELinux running. Good for you. It’s standing between your system and the abyss like a particularly grumpy, rules-obsessed bouncer. But now you want to do something slightly out of the ordinary—let’s say, allow httpd to send email. The default policy says no. The old, terrifying way was to dive into the policy source code, which is written in a language only its mother and a few Red Hat engineers could love, recompile the entire policy, and load it back in. That’s a weekend project you didn’t sign up for.

Enter SELinux Booleans. This is the genius escape hatch. They’re basically policy-level toggles. Think of them as the “Are you sure?” dialogs for the SELinux policy, allowing you to change the behavior of running services on the fly, without a recompile, without a reboot. It’s SELinux’s way of admitting that while its policy is magnificent, it can’t possibly predict every single one of your bizarre, specific needs.

What a Boolean Actually Is

Don’t let the name fool you; it’s not a complex data type. It’s the simplest thing imaginable: a single bit. A 1 or a 0. on or off. true or false. Each Boolean controls a specific, often granular, set of access rules within the massive policy. For instance, the httpd_can_sendmail Boolean doesn’t just flip one rule. When you set it to on, it enables a whole pre-written cluster of rules that allows the httpd processes to connect to network ports and access files necessary for sending mail. It’s a policy bundle wrapped in a single toggle.

You can see the entire glorious list of these toggles on your system. It’s a long list, because SELinux is nothing if not thorough.

getsebool -a

This will spit out pages of lines like httpd_can_sendmail --> off. It’s your checklist of things SELinux is currently forbidding.

How to Flip the Switch (Temporarily and Permanently)

There are two ways to change a Boolean, and you absolutely must know the difference unless you enjoy sudden, confusing reversions of your hard work.

The first way is temporary. It uses the setsebool command and changes the running state in memory. It’s great for testing.

# Let httpd send mail, but only until the next reboot
sudo setsebool httpd_can_sendmail on

See? No output. SELinux doesn’t believe in congratulatory messages. It just does the thing. Now, go test your web application. If it works, fantastic. But if you reboot, this change vanishes, and you’re back to off. This is the “did I leave the stove on?” of SELinux configuration.

To make it stick, you need the -P flag, which stands for “Permanent.” This is the most common pitfall. New users set it temporarily, it works, they reboot, it breaks, and they blame SELinux for being incomprehensible. Don’t be that person.

# This makes the change survive a reboot AND applies it immediately.
sudo setsebool -P httpd_can_sendmail on

The -P flag works by writing the change to the configuration file on disk (typically /etc/selinux/targeted/modules/active/bool.local) and then committing it to the active policy. This is the one you’ll use 99% of the time.

The Devil’s in the Details: Understanding the Why

Here’s where most guides stop, and it’s a massive disservice. They tell you how to flip the Boolean but not why you’re flipping it or what it actually does. Let’s be better.

Simply turning on httpd_can_sendmail because a blog post told you to is a recipe for a slightly more insecure system. Your job is to understand the access you’re granting. The sesearch tool is your best friend here.

# Let's see what rules the httpd_can_sendmail boolean actually controls
sesearch -b httpd_can_sendmail -A

This command will show you all the Allow rules that are enabled when this Boolean is true. You might see output that grants httpd_t the ability to connect to smtp_port_t or to write to a postfix spool directory. Now you know what you’ve done. You haven’t just “made it work”; you’ve specifically allowed the web server to connect to an SMTP port. This insight is what separates a mechanic from an engineer.

Best Practices and the Inevitable Gotchas

  1. Never, Ever Use setenforce 0. Using setenforce 0 (putting SELinux into Permissive mode) to “solve” a problem is like fixing a squeaky brake by cutting the brake line. You’ve removed the symptom (the denial messages) but you’ve also disabled the entire security mechanism. Booleans exist so you don’t have to do this. Identify the denial, find the correct Boolean, and toggle it. Leave Enforcing mode on.

  2. Check the Defaults. Some Booleans are on by default on some distributions and off on others. Never assume. Always check with getsebool first.

  3. It’s Not Always a Boolean. Sometimes, the access you need isn’t governed by a Boolean at all. It might be a labeling issue (chcon, restorecon) or require a custom policy module (audit2allow). If you can’t find a Boolean that fits the denial in your audit logs, it’s probably not a Boolean problem.

Booleans are SELinux’s concession to practicality. They’re the meticulously designed pressure release valves on a supremely strict system. Use them, appreciate them, but always—always—know exactly what steam you’re letting out.