RED HAT ENTERPRISE LINUX

SELinux Security

Protecting Systems with Mandatory Access Control

College-Level Course Module | RHEL System Administration

Welcome to this comprehensive module on Security-Enhanced Linux, or SELinux. SELinux is one of the most powerful security features in Red Hat Enterprise Linux, providing mandatory access control that goes far beyond traditional Unix permissions. While standard permissions control who can access files based on user and group ownership, SELinux controls what processes can do based on security policies - even if traditional permissions would allow the action. This module will transform SELinux from a mysterious system that many administrators disable (a serious mistake) into a tool you understand and can confidently manage. You'll learn to check and change SELinux modes, understand and modify file contexts, troubleshoot access denials, and use booleans to adjust policy behavior. These skills are essential for RHCSA certification and for securing production RHEL systems.

Learning Objectives

Understand SELinux concepts and modes

Enforcing, permissive, and disabled modes; MAC vs DAC

Manage SELinux file contexts

View, change, and restore security contexts on files

Configure SELinux booleans

Toggle policy behaviors without modifying the policy itself

Troubleshoot SELinux denials

Analyze audit logs and resolve access violations

We have four main learning objectives for SELinux. First, you'll understand SELinux fundamentals - what it does, how it differs from standard permissions, and the three operating modes. This conceptual foundation is essential for everything else. Second, you'll master file contexts - the labels that SELinux uses to determine what processes can access which files. You'll learn to view contexts, change them when needed, and restore them to defaults. Third, you'll work with booleans - switches that modify policy behavior. Booleans let you adjust what's allowed without writing custom policy, covering common administrative needs. Fourth, you'll troubleshoot SELinux denials. When something doesn't work and SELinux is involved, you'll know how to investigate, understand the denial, and fix it properly rather than just disabling SELinux.

What is SELinux?

SELinux (Security-Enhanced Linux) is a mandatory access control (MAC) system built into the Linux kernel that enforces security policies controlling what processes can access.

Mandatory Access Control

System-enforced rules that even root cannot override. Policy decides all access.

Discretionary Access Control

Traditional Unix permissions. Owners control access. Root bypasses everything.

Defense in Depth

SELinux adds a layer. If an attacker compromises a service, SELinux limits damage.

Principle of Least Privilege

Processes get only the access they need. Nothing more.

Real Example: A compromised web server can read web content, but SELinux prevents it from reading /etc/shadow - even though the process runs as root.

SELinux fundamentally changes how access control works in Linux. Traditional Unix permissions use Discretionary Access Control - the owner decides who can access their files, and root can do anything. This is a problem because if an attacker compromises a service running as root, they own the system. SELinux implements Mandatory Access Control. The system enforces a security policy that even root must obey. A process can only perform actions that the policy explicitly allows, regardless of traditional permissions. This provides defense in depth. If an attacker exploits a vulnerability in Apache, they can't automatically read /etc/shadow or install backdoors in /usr/bin - the policy doesn't allow httpd to access those resources. The principle of least privilege means each process gets exactly the access it needs and nothing more. Apache needs to read web content and write logs - that's what the policy allows. Not /etc/shadow, not kernel modules, not other services' data.

SELinux Modes

Enforcing

Policy is enforced. Violations are blocked and logged. This is the production setting.

Permissive

Policy is not enforced but violations are logged. Useful for troubleshooting.

Disabled

SELinux is completely off. No protection, no logging. Avoid this mode!

# Check current SELinux status
[root@server ~]# getenforce
Enforcing

# Detailed status information
[root@server ~]# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Memory protection checking:     actual (secure)
Max kernel policy version:      33

SELinux operates in three modes. Enforcing mode actively enforces the security policy. Access that violates policy is denied and logged. This is the default and recommended mode for production systems. Permissive mode doesn't enforce the policy but logs what would have been denied. Use this for troubleshooting - you can see what SELinux would block without actually breaking functionality. It's also useful when initially enabling SELinux on a system to identify needed changes. Disabled mode turns SELinux completely off. No policy enforcement, no logging. While this "solves" SELinux problems, it removes a critical security layer. Never disable SELinux in production without very good reason and compensating controls. The getenforce command shows the current mode in one word. sestatus provides detailed information including the policy name (targeted is standard), mode from the configuration file, and other status details. The mode from config file tells you what mode will be active after reboot.

Changing SELinux Mode

# Temporarily change mode (until reboot)
[root@server ~]# setenforce 0           # Set to Permissive
[root@server ~]# getenforce
Permissive

[root@server ~]# setenforce 1           # Set to Enforcing
[root@server ~]# getenforce
Enforcing

# Permanent change: edit configuration file
[root@server ~]# vim /etc/selinux/config
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=enforcing

# SELINUXTYPE= can take one of these values:
#     targeted - Targeted processes are protected.
#     minimum - Modification of targeted policy.
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted

⚠ Warning: Changing from Disabled to Enforcing requires a reboot and full filesystem relabel (can take a long time). Going to Disabled loses all file contexts.

You can change SELinux mode temporarily or permanently. setenforce changes the mode immediately but only until reboot. Use setenforce 0 for permissive, setenforce 1 for enforcing. You cannot use setenforce to enable a disabled SELinux - that requires configuration change and reboot. For permanent changes, edit /etc/selinux/config. The SELINUX line sets the mode. The SELINUXTYPE line specifies the policy type - targeted is standard, protecting specific services while leaving most of the system unrestricted. After editing the config file, reboot for changes to take effect. Important warnings: If SELinux has been disabled and you want to enable it, the system must relabel all files with security contexts on boot. This can take significant time on large filesystems. Create /.autorelabel or use fixfiles to trigger this. If you disable SELinux, file contexts are not maintained. Re-enabling later means everything needs relabeling, and any contexts you set manually are lost. This is why disabling SELinux is strongly discouraged.

SELinux Contexts

Every process, file, and resource has an SELinux context (also called a label). The policy uses contexts to determine what access is allowed.

user:role:type:level

system_u:object_r:httpd_sys_content_t:s0

User: SELinux user (not Linux user)
system_u, unconfined_u

Role: SELinux role
object_r for files, system_r for processes

Type: The most important part!
Determines what access is allowed

Level: MLS/MCS security level
Usually s0, used for advanced scenarios

SELinux contexts are labels attached to everything - files, processes, ports, users. The context has four parts separated by colons. The SELinux user is not the same as the Linux user. Common SELinux users are system_u for system processes and files, unconfined_u for regular users on targeted policy. The role indicates what roles the user can assume. For files it's always object_r. For processes you'll see system_r or unconfined_r. The type is the most important part for daily administration. This is what the targeted policy primarily uses to make decisions. File types end in _t: httpd_sys_content_t for web content, etc_t for /etc files, user_home_t for home directories. Process types are called domains. The level is used for Multi-Level Security (MLS) or Multi-Category Security (MCS). On standard systems it's usually s0. It's used for advanced scenarios like container isolation. For most administration, you'll focus on the type. When troubleshooting, understanding that processes have a domain type and files have a file type, and the policy controls which domains can access which types, is the key insight.

Viewing Contexts

# View file contexts with ls -Z
[root@server ~]# ls -Z /var/www/html/
system_u:object_r:httpd_sys_content_t:s0 index.html

# View contexts on /etc files
[root@server ~]# ls -Z /etc/passwd /etc/shadow
system_u:object_r:passwd_file_t:s0 /etc/passwd
system_u:object_r:shadow_t:s0     /etc/shadow

# View process contexts with ps -Z
[root@server ~]# ps -eZ | grep httpd
system_u:system_r:httpd_t:s0          1234 ?    00:00:01 httpd

# View your current context
[root@server ~]# id -Z
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

# View context of a directory and contents
[root@server ~]# ls -laZ /var/www/

Key Point: The -Z option works with ls, ps, id, cp, and other commands to show SELinux contexts.

The -Z option is your window into SELinux contexts. ls -Z shows file contexts. Notice how /var/www/html files have httpd_sys_content_t - this type tells SELinux these files are web content that httpd can read. Different files have different types: passwd_file_t for /etc/passwd, shadow_t for /etc/shadow. The policy allows certain processes to read passwd_file_t but restricts shadow_t to specific privileged processes. ps -Z shows process contexts. The httpd process runs in the httpd_t domain. The policy defines what httpd_t can do - read httpd_sys_content_t files, bind to http ports, write to httpd_log_t files, etc. id -Z shows your current context. On a standard targeted policy, regular users are unconfined_t - meaning SELinux doesn't restrict them much. The targeted policy focuses on confining network-facing services, not users. Understanding the relationship is key: the httpd process (httpd_t domain) can read files with httpd_sys_content_t type because the policy has a rule allowing it. No rule, no access.

Changing File Contexts

# Change context temporarily with chcon
[root@server ~]# chcon -t httpd_sys_content_t /var/www/html/newfile.html

# Change context recursively
[root@server ~]# chcon -R -t httpd_sys_content_t /var/www/html/newdir/

# Copy context from another file
[root@server ~]# chcon --reference=/var/www/html/index.html /var/www/html/newfile.html

# Verify the change
[root@server ~]# ls -Z /var/www/html/newfile.html
system_u:object_r:httpd_sys_content_t:s0 newfile.html

⚠ Important: chcon changes are temporary! They will be lost if you run restorecon or during a filesystem relabel. Use semanage fcontext for permanent changes.

# chcon is useful for quick testing, but not persistent
[root@server ~]# restorecon /var/www/html/newfile.html   # Reverts to default!

chcon (change context) modifies SELinux contexts on files. The -t option changes the type, which is what you'll do most often. The -R option works recursively for directories. The --reference option copies the context from another file. However, chcon has a critical limitation: changes are temporary. SELinux maintains a database of what context each file path should have. When restorecon runs (or during system relabel), files are reset to their default contexts. So chcon is useful for quick testing - "if I change this context, does the application work?" - but not for permanent configuration. If you use chcon to fix something, it will break again after updates or relabeling. The proper solution is semanage fcontext, which we'll cover next. Think of chcon as temporary troubleshooting and semanage as permanent configuration.

Permanent Context Changes

# Define a permanent context rule
[root@server ~]# semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"

# Apply the rule to existing files
[root@server ~]# restorecon -Rv /srv/www
Relabeled /srv/www from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0
Relabeled /srv/www/index.html from unconfined_u:object_r:var_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

# View defined context rules
[root@server ~]# semanage fcontext -l | grep /srv/www
/srv/www(/.*)?      all files    system_u:object_r:httpd_sys_content_t:s0

# Delete a custom context rule
[root@server ~]# semanage fcontext -d "/srv/www(/.*)?"

# List only locally added rules (not policy defaults)
[root@server ~]# semanage fcontext -l -C

Two-Step Process: 1) semanage fcontext defines the rule, 2) restorecon applies it to files.

semanage fcontext creates permanent context rules that survive relabeling. This is the correct way to configure non-standard file locations. The command semanage fcontext -a adds a rule. The -t specifies the type. The path uses regular expression syntax - "/srv/www(/.*)?" means /srv/www and everything under it. The rule is stored in the local policy database, but doesn't immediately change files. You must run restorecon to apply the rule. The -R option is recursive, -v is verbose showing what changed. semanage fcontext -l lists all context rules. There are thousands from the policy. Use grep to find specific paths. The -C option shows only locally customized rules, filtering out policy defaults. To remove a custom rule, use semanage fcontext -d with the same path pattern. Common scenario: you configure Apache to serve content from /srv/www instead of /var/www/html. Files there have var_t type, which httpd can't read. You add a rule mapping /srv/www to httpd_sys_content_t, run restorecon, and Apache works.

Restoring Default Contexts

# Restore context on a single file
[root@server ~]# restorecon -v /var/www/html/index.html
Relabeled /var/www/html/index.html from unconfined_u:object_r:default_t:s0 to unconfined_u:object_r:httpd_sys_content_t:s0

# Restore contexts recursively
[root@server ~]# restorecon -Rv /var/www/

# Preview what would change (dry run)
[root@server ~]# restorecon -Rvn /var/www/

# Force relabel even if context seems correct
[root@server ~]# restorecon -RFv /var/www/

# Relabel entire filesystem (creates /.autorelabel and reboots)
[root@server ~]# touch /.autorelabel
[root@server ~]# reboot

# Or use fixfiles (more options)
[root@server ~]# fixfiles -F onboot
[root@server ~]# reboot

Common Fix: Files copied or moved often have wrong contexts. restorecon is frequently the solution to SELinux denials.

restorecon resets file contexts to the policy defaults (including any semanage fcontext rules you've added). It's one of the most useful SELinux commands. Common uses: after copying files (cp preserves contexts, which may be wrong for the destination), after extracting archives (tar and similar may not preserve correct contexts), when files mysteriously have wrong contexts. The -R option works recursively on directories. The -v option shows what changed. The -n option is a dry run, showing what would change without making changes. The -F option forces relabeling even if the context looks correct. For full system relabeling (needed when enabling SELinux after it was disabled, or after major policy changes), create /.autorelabel and reboot. The system will relabel everything on boot, which can take a long time on large filesystems. fixfiles provides more control over relabeling operations. Many SELinux problems are simply files with wrong contexts. "I copied my web content from /home to /var/www and now Apache can't read it" - that's because the files kept their home directory context. restorecon fixes it.

SELinux Booleans

Booleans are switches that modify SELinux policy behavior. They enable or disable specific policy rules without editing the policy itself.

# List all booleans
[root@server ~]# getsebool -a
abrt_anon_write --> off
allow_console_login --> on
allow_cvs_read_shadow --> off
...
httpd_can_network_connect --> off
httpd_can_network_connect_db --> off
httpd_enable_homedirs --> off
...

# List booleans with descriptions
[root@server ~]# semanage boolean -l | grep httpd
httpd_can_network_connect      (off  ,  off)  Allow httpd to connect to network
httpd_can_network_connect_db   (off  ,  off)  Allow httpd to connect to databases
httpd_enable_homedirs          (off  ,  off)  Allow httpd to read user home directories

# Check a specific boolean
[root@server ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off

SELinux booleans are like feature flags for the security policy. Instead of writing custom policy rules, you can toggle booleans to enable common configurations. getsebool -a lists all booleans and their current state. There are hundreds, covering various services and scenarios. The naming convention helps: httpd_ booleans affect Apache, samba_ booleans affect Samba, etc. semanage boolean -l provides descriptions explaining what each boolean does. The output shows current value and default value. Common booleans you'll encounter: httpd_can_network_connect allows Apache to make outgoing network connections (needed for proxying). httpd_enable_homedirs allows Apache to serve content from user home directories (~user URLs). samba_enable_home_dirs allows Samba to share home directories. ftpd_anon_write allows anonymous FTP uploads. Booleans solve the problem of policy being too restrictive for your use case without requiring custom policy. Need Apache to connect to a database? Turn on httpd_can_network_connect_db rather than writing policy rules.

Setting Booleans

# Set boolean temporarily (until reboot)
[root@server ~]# setsebool httpd_enable_homedirs on
[root@server ~]# getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on

# Set boolean permanently (survives reboot)
[root@server ~]# setsebool -P httpd_enable_homedirs on

# Alternative: use semanage
[root@server ~]# semanage boolean -m --on httpd_can_network_connect

# Set multiple booleans at once
[root@server ~]# setsebool -P httpd_enable_homedirs=on httpd_can_network_connect=on

# View locally modified booleans
[root@server ~]# semanage boolean -l -C
SELinux boolean                State  Default Description
httpd_enable_homedirs          (on   ,   off)  Allow httpd to read user home dirs

⚠ Remember: Without -P, boolean changes are temporary and lost on reboot!

setsebool changes boolean values. Without options, the change is temporary - useful for testing. With -P (persistent), the change survives reboot. The -P option writes to the policy database and takes a moment longer. You can use "on" and "off" or "1" and "0" for values. semanage boolean -m is an alternative way to modify booleans, always persistent. Use --on or --off. Set multiple booleans in one command to save time, especially with -P which rebuilds the policy. semanage boolean -l -C shows only booleans you've modified from their defaults. This is useful for documenting your customizations. Typical workflow: You configure Apache to proxy to a backend server. It doesn't work. You check audit logs, find SELinux denying network connections. You search for related booleans with "semanage boolean -l | grep httpd | grep network", find httpd_can_network_connect, enable it with setsebool -P, and Apache works.

SELinux Port Contexts

# List all port contexts
[root@server ~]# semanage port -l | head
SELinux Port Type              Proto    Port Number
afs3_callback_port_t           tcp      7001
afs3_callback_port_t           udp      7001
...
http_port_t                    tcp      80, 81, 443, 488, 8008, 8009, 8443, 9000

# Find which type a port uses
[root@server ~]# semanage port -l | grep 8080
http_cache_port_t              tcp      8080, 8118, ...

# Add a non-standard port for httpd
[root@server ~]# semanage port -a -t http_port_t -p tcp 8888

# Verify the addition
[root@server ~]# semanage port -l | grep 8888
http_port_t                    tcp      8888, 80, 81, 443, ...

# Delete a custom port assignment
[root@server ~]# semanage port -d -t http_port_t -p tcp 8888

# Modify existing (if port already assigned to different type)
[root@server ~]# semanage port -m -t http_port_t -p tcp 8080

SELinux also controls which ports services can use. Each port has a type, and processes can only bind to ports with types their domain is allowed to use. semanage port -l lists all port type assignments. http_port_t includes the standard HTTP ports (80, 443) plus several alternates. If you configure Apache on port 8888 (not in http_port_t), it will fail to start with a permission denied error - SELinux blocks it. semanage port -a adds a port to a type. Specify the type (-t), protocol (-p tcp or -p udp), and port number. After adding 8888 to http_port_t, Apache can bind to it. semanage port -d removes custom port assignments. You can only remove ports you added, not policy defaults. If a port is already assigned to a different type and you need to reassign it, use -m to modify. This is common with ports like 8080 that might be assigned to different services in the default policy. This is a common troubleshooting scenario: service won't start, logs show "permission denied" binding to port, solution is semanage port to allow the service's domain to use that port.

Troubleshooting with Audit Logs

# View SELinux denials in audit log
[root@server ~]# grep "denied" /var/log/audit/audit.log
type=AVC msg=audit(1705774800.123:456): avc:  denied  { read } for  pid=1234 comm="httpd" name="index.html" dev="sda1" ino=12345 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file permissive=0

# Use ausearch for better formatting
[root@server ~]# ausearch -m AVC -ts recent
----
time->Sat Jan 20 14:00:00 2024
type=AVC msg=audit(1705774800.123:456): avc:  denied  { read } for  pid=1234 
  comm="httpd" name="index.html" 
  scontext=system_u:system_r:httpd_t:s0 
  tcontext=unconfined_u:object_r:user_home_t:s0 tclass=file

# Search for denials from specific source
[root@server ~]# ausearch -m AVC -c httpd

# Today's denials
[root@server ~]# ausearch -m AVC -ts today

Reading the denial: httpd_t (process) tried to read a file with user_home_t context. The policy doesn't allow httpd_t to read user_home_t files.

When SELinux denies access, it logs an AVC (Access Vector Cache) message to the audit log. These messages tell you exactly what was blocked. Breaking down the denial: "denied { read }" - the operation that was blocked. "comm=httpd" - the process name. "scontext=...httpd_t..." - source context, the process's domain. "tcontext=...user_home_t..." - target context, the file's type. "tclass=file" - what kind of object (file, directory, socket, etc.). Reading this: httpd (running as httpd_t) tried to read a file labeled user_home_t. The policy doesn't allow httpd_t to read user_home_t. ausearch formats audit records more readably. The -m AVC filter shows only SELinux denials. The -ts option filters by time: "recent" for the last 10 minutes, "today" for today, or specific times. The -c option filters by command name. Understanding these logs is crucial for troubleshooting. They tell you exactly what's wrong and point to the solution - either fix the file context, enable a boolean, or (rarely) create custom policy.

Using sealert

# Install setroubleshoot if not present
[root@server ~]# dnf install setroubleshoot-server

# Analyze audit log for SELinux issues
[root@server ~]# sealert -a /var/log/audit/audit.log
SELinux is preventing httpd from read access on the file index.html.

*****  Plugin catchall_labels (83.8 confidence) suggests   *******************

If you want to allow httpd to have read access on the index.html file
Then you need to change the label on index.html
Do
# semanage fcontext -a -t httpd_sys_content_t '/srv/www/index.html'
# restorecon -v '/srv/www/index.html'

*****  Plugin catchall (17.1 confidence) suggests   **************************

If you believe that httpd should be allowed read access on the index.html
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
# ausearch -c 'httpd' --raw | audit2allow -M my-httpd
# semodule -i my-httpd.pp

sealert is amazing! It analyzes denials and suggests specific commands to fix them.

sealert is the SELinux alert tool from the setroubleshoot package. It analyzes audit logs and provides human-readable explanations with suggested fixes. Run sealert -a /var/log/audit/audit.log to analyze all recorded denials. It groups similar denials and provides confidence-rated suggestions. The output is incredibly helpful. It explains what was denied ("httpd from read access on index.html"), why it matters, and provides exact commands to fix it. Usually there are multiple suggestions ranked by confidence. The highest-confidence suggestion is usually the right one. In this example, the first suggestion (83.8% confidence) correctly identifies that the file has the wrong label and provides the semanage and restorecon commands. The second suggestion (lower confidence) is for creating custom policy - usually not needed if the first suggestion applies. sealert can also run as a daemon, sending desktop notifications when denials occur. On servers, running sealert manually after issues is typical. Always read the suggestions critically - sometimes the suggested fix isn't appropriate for your situation, but sealert gives you the information to make the right decision.

audit2allow and Custom Policy

# See what policy would allow recent denials
[root@server ~]# ausearch -m AVC -ts recent | audit2allow
#============= httpd_t ==============
allow httpd_t user_home_t:file read;

# Generate a loadable policy module
[root@server ~]# ausearch -m AVC -ts recent | audit2allow -M myapp
******************** IMPORTANT ***********************
To make this policy package active, execute:

semodule -i myapp.pp

# Load the custom policy module
[root@server ~]# semodule -i myapp.pp

# List loaded policy modules
[root@server ~]# semodule -l | grep myapp
myapp

# Remove custom module if needed
[root@server ~]# semodule -r myapp

⚠ Warning: Custom policy is a last resort! First try: fix file contexts, enable booleans, or add port labels. Custom policy can create security holes.

audit2allow generates policy rules to permit denied actions. It's powerful but dangerous if misused. Running audit2allow without options shows what policy rules would allow the denied actions. This is informational - review it to understand what's being requested. With -M modulename, it creates a policy module (.pp file) you can load. semodule -i loads the module, making it part of the active policy. Custom policy should be a last resort. The hierarchy of fixes: 1) Fix file contexts with semanage fcontext and restorecon. 2) Enable appropriate booleans. 3) Add port labels with semanage port. 4) Only if none of those work, consider custom policy. Why be cautious? audit2allow generates permissive rules based on what was denied. If malware tried to do something bad and was denied, running audit2allow would create policy allowing that bad action. Always understand what you're allowing. Never run "ausearch | audit2allow -M fix; semodule -i fix.pp" blindly. Review the generated rules. Ensure they make sense for your application. semodule -l lists loaded modules. semodule -r removes modules.

Common Scenarios

Web Content in Non-Standard Location

Problem: Apache can't read /srv/www
Fix: semanage fcontext + restorecon

Apache Connecting to Backend

Problem: Apache can't reach app server
Fix: setsebool -P httpd_can_network_connect on

Service on Non-Standard Port

Problem: Service won't bind to port 8888
Fix: semanage port -a -t type -p tcp 8888

Samba Sharing Home Dirs

Problem: Can't access home directories
Fix: setsebool -P samba_enable_home_dirs on

Files Copied Have Wrong Context

Problem: Copied files inaccessible
Fix: restorecon -Rv /path

Apache Running CGI Scripts

Problem: CGI scripts don't execute
Fix: setsebool -P httpd_enable_cgi on + correct context

# Quick diagnosis workflow
[root@server ~]# ausearch -m AVC -ts recent              # Find denials
[root@server ~]# sealert -a /var/log/audit/audit.log    # Get suggestions
[root@server ~]# ls -Z /path/to/file                    # Check contexts
[root@server ~]# semanage boolean -l | grep service     # Find booleans

Most SELinux issues fall into common categories with standard solutions. Non-standard file locations need context rules. Apache serving from /srv/www, Samba sharing from /data, any custom path needs semanage fcontext to define what type files should have, then restorecon to apply it. Network connections from services are often blocked by default. Apache connecting to databases, application servers, or external APIs needs httpd_can_network_connect or the more specific httpd_can_network_connect_db. Non-standard ports need port labels. Moving SSH to port 2222, Apache to 8888, or any service to a non-default port requires semanage port. Home directory access for services is usually disabled. Samba, FTP, and HTTP serving user home directories requires boolean changes. Wrong contexts from copying files is extremely common. cp preserves the source context. Files copied from /home to /var/www keep home directory contexts. restorecon fixes this. The quick diagnosis workflow: find denials, get suggestions, check contexts, find relevant booleans. With practice, you'll recognize patterns and know the fix immediately.

Troubleshooting Workflow

Verify SELinux is the cause

setenforce 0 - if it works in permissive, SELinux is blocking it

Find the denial

ausearch -m AVC -ts recent or check /var/log/audit/audit.log

Analyze with sealert

sealert -a /var/log/audit/audit.log for suggestions

Apply the appropriate fix

Fix context, enable boolean, or add port label (rarely: custom policy)

Return to enforcing and test

setenforce 1 - verify the fix works with SELinux enforcing

# Complete troubleshooting example
[root@server ~]# setenforce 0           # Test without SELinux
[root@server ~]# curl localhost         # Works! SELinux was blocking
[root@server ~]# setenforce 1           # Re-enable
[root@server ~]# ausearch -m AVC -c httpd -ts recent   # Find denial
[root@server ~]# restorecon -Rv /var/www/html           # Fix context
[root@server ~]# curl localhost         # Test again - works!

Follow this systematic workflow when troubleshooting SELinux issues. Step 1: Verify SELinux is actually the problem. Temporarily set permissive mode. If the problem goes away, SELinux was blocking it. If it persists, SELinux isn't the issue - look elsewhere. Step 2: Find the denial. Use ausearch to locate relevant AVC messages. Filter by time and command name to narrow down. Step 3: Analyze with sealert. Get human-readable explanations and suggested fixes. Review the suggestions - they're usually right but not always. Step 4: Apply the fix. Based on sealert suggestions and your understanding, fix the context, enable a boolean, or add a port label. Custom policy only as a last resort. Step 5: Return to enforcing and verify. Always test with SELinux enforcing. A fix that only works in permissive mode isn't a fix. The example shows a common flow: something doesn't work, permissive mode works, find denials, fix contexts, verify in enforcing mode.

SELinux for Containers

SELinux provides additional isolation for containers, preventing container escapes and limiting the impact of compromised containers.

# Containers run with container_t or similar domains
[root@server ~]# ps -eZ | grep container
system_u:system_r:container_t:s0:c123,c456  12345 ?  00:00:01 nginx

# Each container gets unique MCS categories (c123,c456)
# This prevents containers from accessing each other's data

# View volume contexts
[root@server ~]# ls -Z /var/lib/containers/storage/
system_u:object_r:container_file_t:s0 ...

# When mounting host directories, label appropriately
[root@server ~]# podman run -v /data:/data:Z myimage   # :Z relabels

# Or set context manually
[root@server ~]# semanage fcontext -a -t container_file_t "/data(/.*)?"
[root@server ~]# restorecon -Rv /data

:Z option: Automatically relabels mounted volumes with the container's context. Use for single-container volumes.

SELinux significantly strengthens container security. Without SELinux, a container escape could give an attacker access to the entire host. With SELinux, even an escaped container is confined by the policy. Containers run in the container_t domain (or variants like svirt_lxc_net_t). This domain has limited host access - it can't read most host files or interact with host services. Multi-Category Security (MCS) isolates containers from each other. Each container gets unique category labels (c123,c456 in the example). Container A can't access Container B's files because they have different categories - even though both are container_t. When mounting host directories into containers, SELinux contexts matter. The :Z volume option tells Podman to relabel the directory with the container's context. This allows access but means only that container can use it. For shared volumes across multiple containers, use :z (lowercase) for shared context. For production, properly labeling host directories with container_file_t is more permanent than relying on :Z.

Best Practices

✓ Do

Keep SELinux in enforcing mode
Use permissive only for troubleshooting
Fix contexts before trying booleans
Use semanage for permanent changes
Run restorecon after copying files
Check audit logs when things don't work
Use sealert for guidance
Document your customizations

✗ Don't

Disable SELinux to "fix" problems
Run audit2allow blindly
Use chcon for permanent changes
Ignore denials in permissive mode
Enable booleans without understanding them
Create overly permissive custom policy
Forget to test in enforcing mode
Assume SELinux is the problem without checking

Remember: SELinux is security infrastructure. Disabling it removes a critical defense layer. Learn to work with it, not against it.

Following best practices makes SELinux manageable and keeps your systems secure. Always keep enforcing mode in production. Permissive is for troubleshooting only - it logs denials but doesn't protect you. When things don't work, check contexts first. Most problems are wrong file contexts, easily fixed with restorecon or semanage fcontext. Booleans are the next thing to check if contexts are correct. Use semanage for permanent changes. chcon is temporary - your fix will disappear on relabel. restorecon is your friend for context problems. Run it after copying files, extracting archives, or whenever contexts seem wrong. Check audit logs. SELinux tells you exactly what's blocked. Use sealert for interpreted, actionable guidance. Never disable SELinux. That's not fixing the problem; it's removing your security. Don't run audit2allow blindly - understand what policy you're creating. Document your customizations (semanage exports, boolean changes) for reproducibility and auditing. Test everything in enforcing mode before declaring victory.

Key Takeaways

Modes: getenforce/setenforce for status. Enforcing = security on. Edit /etc/selinux/config for permanent.

Contexts: ls -Z, ps -Z to view. semanage fcontext + restorecon for permanent changes. chcon only for testing.

Booleans: getsebool -a to list. setsebool -P for permanent changes. Easy policy adjustments.

Troubleshooting: ausearch -m AVC for denials. sealert for analysis. Fix contexts → booleans → ports → custom policy.

LAB EXERCISES

Check SELinux mode with getenforce and sestatus
View file contexts in /var/www/html with ls -Z
Create files in a new directory and set proper web content context
Find and enable the httpd_enable_homedirs boolean
Intentionally cause an SELinux denial and analyze with sealert
Add a non-standard port for httpd with semanage port

Next: Managing Basic Storage

Let's summarize the key SELinux skills. For modes, use getenforce to check the current mode, setenforce to temporarily change it, and /etc/selinux/config for permanent changes. Keep enforcing mode in production; use permissive only for troubleshooting. For contexts, use ls -Z and ps -Z to view contexts. Use semanage fcontext to define permanent context rules, then restorecon to apply them. Remember chcon is temporary. For booleans, getsebool -a lists all booleans, semanage boolean -l adds descriptions. Use setsebool -P for permanent changes. Booleans are the easy way to adjust policy for common needs. For troubleshooting, follow the workflow: verify SELinux is the issue, find the denial with ausearch, analyze with sealert, apply the fix (context, boolean, port, or policy), test in enforcing mode. Your lab exercises give you hands-on practice with these core skills. SELinux mastery takes practice, but these fundamentals will handle the vast majority of situations you'll encounter.