Booleans and AVC Diagnosis

setsebool - a hands-on Linux lab on a real virtual machine.

SELinux booleans are named on/off switches that toggle whole chunks of policy without writing rules. Read one with getsebool NAME, flip it permanently with setsebool -P NAME on (without -P the change is lost at the next reboot), and find the one you need with getsebool -a grep KEYWORD. When a service fails for no visible reason, diagnose the denial with ausearch -m AVC -ts recent and sealert -a /var/log/audit/audit.log, which often name the exact boolean, restorecon, or semanage fix. Serves EX200 security: manage SELinux booleans to permit and restrict services.

You set up a web application on a RHEL 10 box. The service is running, the firewall allows port 80, the file permissions are correct. But the app cannot reach its backend database, and the log fills with permission-denied errors that make no sense. You check the user, the group, the ownership, the network. Everything looks right. Everything IS right, by the normal rules. And it still fails.

The thing blocking you is SELinux, and it is doing exactly what it was told. By default, SELinux forbids the web server from opening network connections out to other machines, because a compromised web server that can dial out is a favorite attacker tool. That default is a policy switch, and it is currently off. This lesson teaches you to find that switch, flip it the right way, and, when you have no idea which switch is the problem, read the audit log that names it for you. This is the difference between a service that mysteriously fails and one you can fix in thirty seconds.

The black boxes below are a practice terminal: a safe sandbox that checks the one command each step teaches. The outputs are from a real RHEL 10 machine (AlmaLinux 10.2) running as root with SELinux in Enforcing mode. The boolean names and their off/on states are real and stable across machines. What varies per machine is the audit log content, the timestamps, and the exact list of booleans your system has, so treat those as illustrative. What is stable everywhere is the SHAPE: getsebool reports a switch as --> off or --> on, setsebool -P flips it for good, and the audit tools name the fix.

SELinux policy is a huge rulebook that says which processes may touch which files, ports, and network connections. Most of that rulebook is fixed. But some parts are meant to be toggled on and off depending on how you run your machine, and those toggle points are called booleans.

A boolean is a named on/off switch that turns a whole chunk of policy on or off at once. httpd_can_network_connect is one switch that decides whether the web server is allowed to open outbound network connections. Flip it on and a block of rules permitting that traffic activates. Flip it off and they deactivate. Think of a boolean like a labeled breaker in an electrical panel: you do not rewire the house, you just throw the switch that the electrician already installed for that exact purpose. Booleans exist so you can adjust common scenarios without writing raw policy, which on the exam you almost never do.

When a service on RHEL is denied something and the file permissions and firewall are all correct, SELinux is the next suspect. A boolean is very often the fix. Sharing home directories over NFS, letting the web server talk to a database, allowing an FTP daemon to read user files, permitting a mail server to write to a nonstandard spot: every one of these ships as a boolean. It is off by default for safety, waiting for an administrator who needs it to turn it on.

The exam rewards this reflex directly. A task says a service must be able to do X, you confirm the normal settings are fine, and the missing piece is a single boolean set to on and made permanent. Knowing the switch exists, finding its name, and flipping it correctly is a repeatable point you should never leave on the table.

Start by asking what state a boolean is currently in. The command is getsebool followed by the boolean's name. It prints the name, an arrow, and the word off or on. Nothing else. This is how you check a switch before you touch it and how you confirm the change afterward.

Before you run it, know what to expect: a fresh RHEL system ships httpd_can_network_connect turned off, because the web server has no business dialing out until you say so. Read its current state:

getsebool httpd_can_network_connect

prompt: [root@servera ~]# answer: getsebool httpd_can_network_connect output: httpd_can_network_connect --> off hint: The reader is getsebool, then the boolean name: getsebool httpd_can_network_connect

The output httpd_can_network_connect --> off reads left to right: the name of the switch, an arrow, and its state. off means the policy that would let the web server open outbound network connections is currently inactive, which is why an app that tries to reach a remote database gets denied. This is the safe default. You have not changed anything yet; you have only looked. Always look before you flip, so you know the starting state and can prove your change afterward.

To change a boolean you use setsebool, giving it the name and the target state, on or off. But there is a trap that catches everyone once. Plain setsebool NAME on changes the switch right now, in the running kernel, and that change is lost at the next reboot. It does not survive. To make the change permanent you add the -P flag, which writes the new state to disk so it comes back after a reboot.

On the exam and in real work you almost always want the change to stick, so you almost always want -P. Turn the switch on, permanently:

setsebool -P httpd_can_network_connect on

prompt: [root@servera ~]# answer: setsebool -P httpd_can_network_connect on output: hint: The setter is setsebool, and -P makes it permanent: setsebool -P httpd_can_network_connect on

No output, which is success: setsebool is silent when it works. The -P flag is the whole point. It means persistent: the new value is written to the policy on disk, so a reboot will not undo it. The web server is now allowed to open outbound network connections, and it will still be allowed after the machine restarts. Leave off the -P and you get a change that works only until the next reboot silently reverts it. That is one of the classic ways an exam task quietly fails hours after you thought it was done.

The single most common SELinux mistake is forgetting -P. setsebool httpd_can_network_connect on looks identical to the permanent version and works perfectly in every test you run right now. Then the machine reboots, the boolean snaps back to off, and the service breaks again with no obvious cause. On the exam, graders reboot. If a task says a setting must persist, and boolean tasks always do, the -P is not optional. Type it every time.

You never trust a change you have not verified. Run the exact same getsebool you ran at the start and read the state back. If your setsebool -P worked, the arrow now points at on. This before-and-after pattern, read then set then read, is how you prove to yourself, and to a grader, that the switch is where it should be.

Read the state back and confirm it flipped:

getsebool httpd_can_network_connect

prompt: [root@servera ~]# answer: getsebool httpd_can_network_connect output: httpd_can_network_connect --> on hint: Read it back the same way you first checked it: getsebool httpd_can_network_connect

The arrow now reads on. The same command that showed off before your setsebool -P now shows on, which proves the change took. This is the whole loop: getsebool to see the starting state, setsebool -P to change it, getsebool again to confirm. On the exam, that final confirming read is what turns a hopeful change into a checked one. Never leave a boolean task without reading the switch back.

Half the battle is knowing which boolean you need. There are hundreds, and you will not memorize them. getsebool -a lists every boolean on the system with its state, which is far too much to read raw. So you pipe it into grep and search for a keyword tied to your problem: the service name, or what it is trying to do.

Say a web app cannot make network connections and you suspect a boolean but do not recall the exact name. Search every boolean for the httpd network family:

getsebool -a | grep httpd_can_network

prompt: [root@servera ~]# answer: getsebool -a | grep httpd_can_network output: httpd_can_network_connect --> on httpd_can_network_connect_cobbler --> off httpd_can_network_connect_db --> off hint: List them all with getsebool -a, then filter with grep on a keyword: getsebool -a | grep httpd_can_network

getsebool -a dumps every boolean and its state; the | grep httpd_can_network keeps only the lines matching that keyword. Here it surfaces three related switches. httpd_can_network_connect (now on, from your earlier change) is the broad one for general outbound connections. httpd_can_network_connect_db is the narrower one for reaching databases specifically, still off. This is how you discover the exact switch a task needs: grep on the service (httpd, ftpd, nfs, samba) or the action, read the candidates, and pick the one whose name matches what you are trying to allow.

The full list of booleans varies from machine to machine depending on which packages are installed, so your getsebool -a output will be longer or shorter than another system's. The httpd_can_network_connect family shown here is standard on any box with the web policy present. When you grep, start broad with just the service name, for example grep httpd, then narrow the keyword once you see the candidates.

Sometimes you do not even know a boolean is the problem. A service just fails, and you need the machine to tell you why. Every SELinux denial is logged as an AVC (Access Vector Cache) message in the audit log, and two tools turn that raw log into an answer.

ausearch -m AVC -ts recent pulls the recent AVC denials out of the audit log so you can see what was blocked and when. sealert -a /var/log/audit/audit.log goes further: it analyzes the log and prints a plain-language explanation. It very often names the exact fix, whether that is a boolean to set, a restorecon to run, or a semanage command to add a label. When an exam task fails for no visible reason, these two commands are where you look first. They frequently hand you the precise setsebool -P line to run, turning a mystery into a copy-paste fix.

Read the two diagnosis commands as a pair. ausearch -m AVC -ts recent answers what got denied: it filters the audit log to AVC messages (-m AVC) from the recent past (-ts recent). sealert -a /var/log/audit/audit.log answers what to do about it: it reads the whole audit log (-a) and suggests a concrete fix. Run ausearch to confirm SELinux is the culprit, then sealert to be told the remedy.

Scaffolding off. No command is printed this time. You have every piece you need.

A web application on your RHEL 10 server must be allowed to open outbound network connections, and the setting has to survive a reboot because the grader will restart the machine. You have already confirmed the file permissions and firewall are correct, and you know the boolean that governs this is httpd_can_network_connect. Which single command turns that boolean on in a way that persists across reboots? Remember the flag that everyone forgets.

prompt: [root@servera ~]# answer: setsebool -P httpd_can_network_connect on output: hint: It is the setter, not the reader, and it needs the persistent flag. setsebool -P, the name, then on.

setsebool -P httpd_can_network_connect on is the answer, and the -P is the entire point of the challenge. Without it the switch flips now but reverts at the next reboot, and the grader reboots. setsebool (the setter, not getsebool the reader), -P (persistent, written to disk), the boolean name, then the target state on. Confirm it afterward with getsebool httpd_can_network_connect and read back --> on. That read-set-read loop, with -P in the middle, is the whole discipline of boolean tasks.

You earned this cheat sheet. Every row is a form you just ran or built:

The one thing to burn in for the exam: a boolean change without -P is lost at the next reboot, and the grader reboots. When a service fails and permissions look right, suspect SELinux, find the boolean with getsebool -a | grep, set it with setsebool -P, and confirm with getsebool.

The diagnosis tools save you when you are blind. If a service fails and you cannot guess the boolean, run ausearch -m AVC -ts recent to prove SELinux blocked it, then sealert -a /var/log/audit/audit.log to be told the fix. sealert will often print the exact setsebool -P line, or a restorecon, or a semanage command, so you rarely have to invent the remedy yourself.

The practice terminal has walked you through the whole loop. getsebool to read a switch, setsebool -P to flip it permanently, getsebool again to confirm, getsebool -a | grep to find the switch you need by keyword, and the ausearch and sealert pair to diagnose a denial when you have no idea what is wrong. Every one of those you typed yourself.

The security module capstone, Operation Lockdown, is where you run these against a real RHEL 10 machine. A full VM boots for you, with SELinux Enforcing and real services that will be denied until you find and flip the right booleans. The mission hands you objectives that use exactly what you practiced here: a service that must be allowed to do something, a denial to diagnose in the audit log, and a boolean to set permanently and confirm. One difference from this lesson: the mission shows no commands. You read the objective, recall the getsebool and setsebool -P forms, find the switch, and flip it. That recall is what makes it stick on exam day.

Finish the other security lessons, then take Operation Lockdown and secure a real RHEL 10 box.

Practice Booleans and AVC Diagnosis in a real Linux terminal at The Linux Camp. Progress is verified automatically as you type commands on the machine.