Exam objective 5.4 demands that you configure SELinux contexts, set booleans, and troubleshoot permissions denials - all without panicking. SELinux solves a fundamental problem: standard Linux permissions let the file owner decide who accesses what, but if a hacker compromises a service (like a web server), that service can read any file its user owns. SELinux adds a mandatory layer of security that confines each process to only what it absolutely needs, blocking unauthorised access even if standard permissions say 'yes'. For your EX200 exam, you must know how to check, fix, and adjust SELinux settings because these are the second-most common reason services fail after standard permission issues.
Jump to a section
A simple way to picture SELinux Configuration and Troubleshooting
A security guard checks your ID badge at the building entrance, so you assume you can freely walk into any office on any floor. But in this building, each door also has its own lock that only opens for badges with the correct security clearance and department code. Even though the guard let you in, you cannot open the accounting office door because your badge lacks the 'finance' label. The guard is like Discretionary Access Control (DAC) - the standard Linux permissions that check who you are. The additional door locks are SELinux, which enforces a mandatory policy based on labels attached to every file, process, and user. In a real building, if the fire alarm rings, the doors might automatically unlock so people can escape. This maps to SELinux booleans - you can flip a toggle to temporarily allow a specific action, like granting a web server access to read user home directories, without redesigning the entire security policy. Troubleshooting a locked door means checking both the guard's list and the door's label requirements. Similarly, when a service fails on Linux, you must check standard permissions AND SELinux contexts, often using audit logs to spot the denied access and then correct the file label or adjust a boolean. The security guard cannot override a door lock, and the door lock cannot override the guard - they work together to enforce a layered security model.
This analogy is specific to SELinux because it illustrates the concept of mandatory access control (the door locks) layered on top of discretionary access control (the guard), and how booleans act as policy toggles - a relationship unique to SELinux configuration and troubleshooting.
SELinux stands for Security-Enhanced Linux. It is a kernel module (a piece of code that loads into the Linux kernel, which is the core of the operating system) that provides mandatory access control. Mandatory access control means the system enforces security rules that even the file owner cannot override. This contrasts with discretionary access control, the default Linux model, where the file owner decides who can read, write, or execute a file.
SELinux works by attaching a security context (a label) to every file, process, port, and user. This label contains several pieces of information: user, role, type, and sensitivity. For the EX200 exam, the most important part is the 'type' field. The type defines what a subject (like a process) is allowed to do to an object (like a file). The rule that decides whether a type can access another type is called a policy rule. The overall collection of these rules is called the SELinux policy.
SELinux has three modes:
Enforcing: SELinux is active and enforces all policy rules. Denied actions are blocked and logged.
Permissive: SELinux logs all denials but does NOT block any action. This is used for troubleshooting: you can see what would be denied without breaking your services.
Disabled: SELinux is turned off completely. No rules are applied, and no logging occurs. On Red Hat Enterprise Linux, switching from disabled to enforcing requires a reboot because the labels must be reapplied to the entire filesystem.
You can check the current mode with the command 'getenforce' and change it temporarily with 'setenforce 0' for permissive or 'setenforce 1' for enforcing. To make the change permanent, you edit the file '/etc/selinux/config' and set the 'SELINUX' variable to 'enforcing', 'permissive', or 'disabled'. This is a common exam trap: candidates use 'setenforce' but forget to edit the config file, so the mode resets after reboot.
Now, what causes SELinux to deny access? The most common scenario is that a file has a security context (label) that does not match what the process expects. For example, the Apache web server (called httpd on Red Hat) runs with a type of 'httpd_t'. It expects to read files with the type 'httpd_sys_content_t' in the default web directory '/var/www/html'. If you create a new file in your home directory and then move it to '/var/www/html', the file keeps its original label (often 'user_home_t' or 'admin_home_t'). The httpd process, running as 'httpd_t', is not allowed to read files with type 'user_home_t'. Even if standard permissions are set to 755 (world readable), SELinux blocks the access with a denial.
To fix this, you must restore the correct context using 'restorecon' (restore security context) or change it manually with 'chcon' (change context). 'restorecon' resets the label to the default type defined in the policy for that directory. For instance, 'restorecon -v /var/www/html/index.html' will set the correct type. 'chcon' lets you set an arbitrary label, but it is less commonly needed in day-to-day admin work.
Another major concept is SELinux booleans. A boolean is an on/off switch that toggles a specific policy rule without requiring you to write a new policy. For example, if you want to allow the web server to connect to a network database (like MySQL), you would enable the boolean 'httpd_can_network_connect_db'. You list booleans with 'getsebool -a' and set them with 'setsebool -P boolean_name on'. The '-P' flag makes the change permanent across reboots. Without '-P', the change is temporary until reboot.
SELinux also protects network ports. Each port has a context type. For example, port 80 is labelled 'http_port_t'. If you try to run a web server on a non-standard port like 8888, SELinux will block it unless you assign the correct port context with 'semanage port -a -t http_port_t -p tcp 8888'.
Finally, troubleshooting SELinux issues relies heavily on the audit log at '/var/log/audit/audit.log'. When SELinux denies an action, it writes an entry with the subject (process), object (file), and the denied permission. The command 'ausearch -m avc -ts recent' searches for recent denial messages. You can also use 'sealert -a /var/log/audit/audit.log' to get human-readable hints and suggested fixes.
SELinux replaced the old 'root can do anything' model with a least-privilege approach. Even the root user cannot bypass SELinux rules unless they explicitly change the mode. This makes Linux far more secure against exploits that target services listening on the network.
Identify the Symptom
A service (like a web server or database) fails to start or cannot access a file. Check standard permissions first with 'ls -l'. If they look correct, the issue is likely SELinux. Confirm by running 'getenforce' — if it returns 'Enforcing', SELinux is active.
Switch to Permissive Mode for Testing
Run 'setenforce 0' to put SELinux into permissive mode. This does not disable SELinux but allows all operations while logging what would have been denied. Test the service again. If it works in permissive mode, SELinux is the cause of the denial.
Search the Audit Log for Denials
Use 'ausearch -m avc -ts recent' to view recent SELinux denial messages. The output shows which process (scontext) was denied access to which file (tcontext) and what operation (read, write, connect) was blocked. This pinpoints the exact misconfiguration.
Analyse the Denial with sealert
Run 'sealert -a /var/log/audit/audit.log' to get a human-readable explanation of the denials. The tool suggests the correct fix, such as restoring the context with 'restorecon' or enabling a specific boolean.
Apply the Fix
If the denial is due to a wrong file context, run 'restorecon -Rv /path/to/file' to reset it to the default type. If the denial is due to a boolean that controls a feature (like network access), use 'setsebool -P boolean_name on'. If the denial is about a port, use 'semanage port -a -t service_port_t -p tcp port_number'.
Switch Back to Enforcing and Verify
Run 'setenforce 1' to return to enforcing mode. Test the service again to confirm it now works. Then check that the change persists across reboots by verifying '/etc/selinux/config' and 'getsebool -a' (if you set a boolean). Finally, run 'ausearch -m avc -ts recent' again to ensure no new denials appear.
An IT professional working for a medium-sized e-commerce company receives a ticket: 'The web application has stopped serving product images. Users see broken icons.' The application runs on Red Hat Enterprise Linux 8 with Apache (httpd). The developer recently uploaded a new batch of images to a custom directory '/data/product-images'. The IT pro's first step is to check standard permissions: 'ls -l /data/product-images' shows files are owned by root:root with 755 permissions, so everyone can read. That looks fine. Next, the IT pro checks if SELinux is blocking access. They run 'getenforce' and see 'Enforcing'. Then they check the audit log: 'ausearch -m avc -ts recent | grep httpd'. The output shows multiple denials: the httpd process (type 'httpd_t') tried to read files with type 'var_t' on directory '/data'. The directory was created by the developer who used 'mkdir /data' — that directory inherited the default type for the root filesystem, which is 'default_t' or the generic type for the top-level directory. The web server is not allowed to read such files.
The IT pro now knows the fix: change the security context of '/data/product-images' to the correct type for web content. They run 'semanage fcontext -a -t httpd_sys_content_t "/data/product-images(/.*)?"' which adds a default rule for that path. Then they run 'restorecon -Rv /data/product-images' to apply the labels. The images load immediately. But the IT pro also wants to prevent similar issues in the future. They create a step-by-step documentation:
Always use 'ls -Z' to view SELinux context of new files.
When moving files from home directories to web directories, always run 'restorecon -v' on them.
When creating custom application directories, add them to the semanage fcontext database.
Another common scenario: a developer wants to run a custom script that connects to a remote MySQL database. The script runs under the user context 'unconfined_t' (the default for user processes), so it has few restrictions. But if the same script must run as a systemd service with restricted context, SELinux might block outbound network connections. The IT pro would then check booleans: 'getsebool -a | grep network'. They identify that 'httpd_can_network_connect' is off. They run 'setsebool -P httpd_can_network_connect on' to allow the web service to initiate outbound TCP connections. Without this boolean, even a legitimate script on port 80 cannot fetch external APIs.
A third scenario: a security audit reveals that an internal database server is listening on TCP port 5432 (PostgreSQL). The IT pro needs to confirm that only the web server can connect. They check the SELinux context of the port: 'semanage port -l | grep postgresql'. They see that port 5432 is labelled 'postgresql_port_t'. They then verify that the web server's boolean 'httpd_can_network_connect_db' is enabled. If it is not, they enable it. This ensures that even if a rogue process gets root access, SELinux restricts which ports it can bind to.
The EX200 exam tests SELinux configuration and troubleshooting in several discrete ways. Here is exactly what you need to prepare for:
First, you must know how to switch between enforcing and permissive modes. Expect a question where a service is failing, and the log shows no standard permission error. The correct first step is to temporarily set SELinux to permissive with 'setenforce 0' to see if the service starts. If it starts in permissive mode, you know SELinux is the blocker. You must then know to check the audit log with 'ausearch -m avc' for the exact denial. A common exam trap: the question asks 'How do you permanently disable SELinux?' The answer is to edit '/etc/selinux/config' and set 'SELINUX=disabled', but the exam loves to offer 'setenforce 0' as a distractor — that is temporary only. Another trap: they ask you to change to permissive mode permanently. The answer is to set 'SELINUX=permissive' in the config file, not 'setenforce 0'. Remember: 'setenforce' is runtime only; '/etc/selinux/config' is persistent.
Second, you must be able to view and change security contexts. The exam will ask: 'Which command shows the SELinux context of files?' The answer is 'ls -Z'. For processes, 'ps -Z'. For users, 'id -Z'. You must know how to restore a default context with 'restorecon' and how to change it manually with 'chcon'. The exam often gives you a scenario where a file was moved from /root to /var/www/html, and the web server cannot access it. The correct answer is to run 'restorecon -v /var/www/html/filename'. A trap: they might suggest 'chcon -t httpd_sys_content_t file' — that works, but 'restorecon' is the recommended way because it uses the default policy. Also, 'chcon' does not survive a full filesystem relabel; 'restorecon' does.
Third, you must understand booleans. The exam will ask you to list all booleans ('getsebool -a'), get the current state of a specific boolean ('getsebool httpd_can_network_connect'), and set a boolean persistently ('setsebool -P boolean_name on'). The trap: leaving off '-P' so the change is temporary. Another trap: they ask 'Which boolean allows the web server to read user home directories?' The answer is 'httpd_enable_homedirs' (or similar, but you must memorise the exact name). You do not need to memorise all booleans — only the few common ones listed in the Red Hat documentation for EX200: 'httpd_can_network_connect', 'httpd_can_network_connect_db', 'httpd_enable_homedirs', 'httpd_use_nfs', 'ftp_home_dir'.
Fourth, you may be asked about port labelling. The exam could ask: 'You want to run a web server on port 8080. What should you do?' The correct answer: 'semanage port -a -t http_port_t -p tcp 8080'. The trap: they might say 'just change the port in httpd.conf' — that will fail because SELinux blocks it. Another trap: 'semanage port -m' modifies an existing port, but '-a' adds a new one. Know the difference.
Fifth, you might see a troubleshooting question where you are given an audit log entry. The entry will show 'avc: denied { read } for pid=... comm="httpd" path="/var/www/html/file" scontext=... tcontext=...'. You must interpret that the source context is the httpd process, the target context is the file, and the denied operation is 'read'. The fix is to change the file's context using 'restorecon' or 'chcon'. Another trap: they ask 'What tool converts audit log denials into human-readable suggestions?' The answer is 'sealert'.
Sixth, understand that SELinux contexts include user, role, type, and level (sensitivity). For EX200, types 'targeted' policy (the default) only enforces type enforcement. You do not need to know MLS (Multi-Level Security) for the exam.
Finally, memorise these commands and what they do: - 'getenforce' — shows current mode - 'setenforce 0|1' — sets mode temporarily - 'getsebool -a' — lists all booleans - 'setsebool -P boolean on|off' — sets boolean persistently - 'semanage fcontext -a -t type path' — adds a file context rule - 'restorecon -Rv path' — restores contexts recursively - 'chcon -t type file' — changes context manually - 'ls -Z' — view file context - 'ps -Z' — view process context - 'ausearch -m avc' — search audit log for denials - 'sealert -a /var/log/audit/audit.log' — analyse log for fixes
SELinux adds a mandatory access control layer on top of standard Linux permissions, so even root cannot access files without the correct security context.
The three SELinux modes are enforcing (active blocking), permissive (logging only), and disabled (completely off); use getenforce to check and setenforce to change temporarily.
To permanently change SELinux mode, edit /etc/selinux/config and set the SELINUX variable to enforcing, permissive, or disabled.
File security contexts are viewed with ls -Z, and the default context for a path can be restored with restorecon -Rv.
SELinux booleans are on/off switches for specific policy rules; set them persistently with setsebool -P boolean_name on.
When a service fails and standard permissions look correct, check the audit log at /var/log/audit/audit.log using ausearch -m avc to find SELinux denials.
To allow a service to use a non-standard port, use semanage port -a -t service_port_t -p tcp port_number.
The Red Hat recommended troubleshooting workflow is: set SELinux to permissive, test the service, then analyse the audit log with sealert, then fix the context or boolean, then set SELinux back to enforcing.
These come up on the exam all the time. Here's how to tell them apart.
Discretionary Access Control (DAC)
The file owner decides who can read, write, or execute the file.
Controlled by user, group, and others permissions (rwx).
Root can bypass all DAC restrictions.
Mandatory Access Control (MAC) via SELinux
The system policy decides what processes can access, regardless of the file owner.
Controlled by SELinux security contexts (type labels) on files and processes.
Root is also bound by SELinux rules unless the mode is changed.
Enforcing Mode
SELinux blocks unauthorised actions and logs them to the audit log.
Use this mode for production systems to enforce the security policy.
Run 'setenforce 1' to enter this mode.
Permissive Mode
SELinux does not block any actions but logs what it would have denied.
Use this mode for troubleshooting to see denials without breaking services.
Run 'setenforce 0' to enter this mode.
restorecon
Resets the context to the default policy value for the given path.
Recommended for most fixes because it uses the correct type from the policy database.
Changes persist through filesystem relabel operations.
chcon
Manually sets an arbitrary context regardless of the default policy.
Useful for custom labelling that does not match any default rule.
Changes may be overwritten by a full restorecon or filesystem relabel.
getsebool -a
Lists all SELinux booleans and their current state (on or off).
Does not change any settings, only queries them.
Use the output to identify which boolean might need toggling.
setsebool -P
Changes a boolean to on or off and makes the change permanent with the -P flag.
Without -P, the change is temporary until reboot.
Use this to enable features like network access for the web server.
ausearch -m avc
Searches the audit log for SELinux avc denial messages based on filters.
Outputs raw audit records showing subject, object, and denied action.
Ideal for quickly checking if recent denials occurred.
sealert -a
Analyses the full audit log and produces human-readable explanations and suggested fixes.
Outputs plain English descriptions like 'SELinux is preventing httpd from read access on file'.
Use this when you need guidance on what to do next.
File Context (ls -Z)
A label attached to every file and directory on the system.
Determines what processes (with which types) can read/write/execute the file.
Changed with chcon or restorecon, managed with semanage fcontext.
Port Context (semanage port -l)
A label attached to every TCP or UDP port number.
Determines which service types can bind to or listen on that port.
Changed with semanage port -a or -m.
Mistake
SELinux is an antivirus or firewall that blocks malware.
Correct
SELinux is a mandatory access control system that restricts what processes can do, regardless of the user. It does not scan for malware or block network traffic like a firewall.
The name 'Security-Enhanced Linux' sounds like it adds general security features, and beginners often conflate kernel security with anti-malware tools.
Mistake
Disabling SELinux is the best way to fix application permission issues.
Correct
Disabling SELinux removes the security layer entirely. The correct approach is to put SELinux into permissive mode temporarily to diagnose the issue, then fix the context or boolean, not disable it permanently.
It is quicker to turn off SELinux than to troubleshoot the specific label or boolean, and many online tutorials suggest disabling it, leading to insecure systems.
Mistake
Changing file ownership with chown or permissions with chmod will fix SELinux denials.
Correct
SELinux enforces rules based on security contexts, not Unix users or permissions. A file owned by root with 777 permissions can still be denied if its SELinux type does not match what the process expects.
In standard Linux, file ownership and permissions are everything. Beginners naturally apply the same solution to SELinux problems without realising it is a separate system.
Mistake
Running a command as root bypasses SELinux restrictions.
Correct
Even the root user is subject to SELinux type enforcement. Root can change the mode or disable SELinux, but unless they do, SELinux rules apply to root processes as well.
The traditional Unix model gives root unlimited power. SELinux intentionally breaks that model, so beginners assume root can override everything.
Mistake
The audit log at /var/log/audit/audit.log only records SELinux denials.
Correct
The audit log records all Linux audit events, including user logins, changes to system time, and any action configured for auditing, not just SELinux denials. You filter for SELinux with 'ausearch -m avc'.
The name 'audit.log' and the fact that SELinux denials are the most common entries leads beginners to think it is SELinux-only.
Mistake
Once you restore the context with restorecon, the change is permanent and never needs to be done again.
Correct
Restorecon resets the context to the default policy for that directory, but if the file is later moved or copied from a different location, the new file may have a different context requiring another restorecon.
Beginners think of it as a one-time fix, whereas context management is an ongoing task whenever files are moved or created outside their expected locations.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
setenforce 0 puts SELinux into permissive mode (logs but does not block), while setenforce 1 puts it into enforcing mode (actively blocks and logs).
Edit the file /etc/selinux/config, change the line SELINUX=enforcing to SELINUX=disabled, save the file, and reboot the system.
restorecon resets the SELinux security context of a file or directory to the default value defined in the policy for that path. Use it after moving or copying files into a directory where the expected context differs.
Run 'getsebool -a' to list all booleans with their current state. To check a specific boolean, use 'getsebool boolean_name'.
Use the sealert command. For example, 'sealert -a /var/log/audit/audit.log' gives human-readable suggestions for fixing denials.
The file retains its original SELinux context (typically admin_home_t) which the web server (httpd_t) is not allowed to read. Running restorecon on the file resets its context to httpd_sys_content_t, fixing the issue.
You've finished SELinux Configuration and Troubleshooting. Continue through the EX200 study guide to build a complete picture of the exam.
Done with this chapter?