RHCSA (034): Season 2 - Scenario 9: Symlink Context Search

Episode 034 Executive Summary

In this Symlink Context Search RHCSA lab scenario, I start performing the lab after a 6 minute introduction by the podcast hosts. You will get the most out of this lab if you listen to the entire show and then try to practice the lab several times, either along with me or by yourself. Today we explore the often confusing relationship between file links and security policies on RHEL systems.

This scenario is highly deceptive because creating a symbolic link is a trivial task, but making that link functional across different security domains trips up many candidates. The operational goal here bridges basic file management and advanced security. You will use regular expressions to parse system data, create links to that data, and then troubleshoot why a web service cannot read the target file.

The core challenge requires you to extract specific user accounts using advanced search tools, link that data into a web directory, and modify the underlying security context to permit access. We will use system utilities to generate the data, create the soft link, and apply the correct labels so the web server can serve the file successfully. Verification is done by simulating a web request to ensure the link and contexts resolve correctly.

Keywords: RHCSA, RHEL 10, Rocky Linux 10, Symlinks, Grep, Regex, SELinux Contexts, File Management

EPISODE 034: Symlink Context Search

• Season: 2 | Difficulty: High
• Objectives: Primary 1.9, 1.3; Secondary 10.5, 10.6
• Lab Focus: Symlinks, Grep, Regex, SELinux Contexts
• URL: https://djere.com/rhcsa-034-season-2-scenario-9-symlink-context-search.html

1. SCENARIO BRIEF (THE PROBLEM)

The security team requires a daily export of all system accounts that have an active, interactive shell assigned to them. This file must be generated in a dedicated audit directory and then symbolically linked to an internal web server directory for easy access by auditors. You must use regular expressions to find the correct accounts, create the symlink, and ensure the web server can read the target file through the link despite the restrictive default SELinux policies on custom directories.

2. TASK ANALYSIS (THE "WHY")

• 1.9: Symbolic links allow files to exist in a secure directory while being accessible from application directories without duplicating data.
• 1.3: Regular expressions combined with search utilities allow administrators to filter massive configuration files for specific, complex patterns reliably.
• 10.5: Custom directories lack the default security contexts required by services like Apache, meaning SELinux will block access to the linked target file until the context is explicitly defined.
• 10.6: Defining a policy is not enough; the policy must be actively applied to the filesystem objects to take effect.

3. SOLUTION STEPS

Step 1: Environment Setup (Root Only)

# Check if the Apache web server is installed, and install it quietly with the assume-yes flag if it is missing
if ! rpm -q httpd; then dnf install -y httpd; fi

# Check if the SELinux management tools are installed, and install them if missing
if ! rpm -q policycoreutils-python-utils; then dnf install -y policycoreutils-python-utils; fi

# Enable the web server to start on boot and start it immediately to serve our files
systemctl enable --now httpd

# Create the parent directory structure for the audit data using the parents flag to avoid errors
mkdir -p /opt/audit-data

Step 2: Core Implementation (Execute as root)

# Use the extended regex flag with grep to match lines ending in either bash or zsh, and redirect the output to our audit file
grep -E '(/bin/bash|/bin/zsh)$' /etc/passwd > /opt/audit-data/active-shells.txt

# Create a soft link pointing from the web server document root to our newly created audit file
ln -s /opt/audit-data/active-shells.txt /var/www/html/active-shells-link.txt

# Add a new file context rule to the SELinux policy targeting the audit directory and all its contents
semanage fcontext -a -t httpd_sys_content_t '/opt/audit-data(/.*)?'

# Recursively apply the newly defined SELinux file context to the directory and log the changes
restorecon -Rv /opt/audit-data

# Technical Breakdown: The web server process runs in the httpd_t domain. Even if a symlink in the web root is readable, SELinux evaluates the context of the target file. By setting the target file to httpd_sys_content_t, we grant the web server permission to read the data.
# Pro-Tip: Always remember that a symbolic link inherits the SELinux context of the directory it resides in, but the process accessing the link still needs permission to read the actual target file.

Step 3: Verification (The "Proof of Work")

# Request the linked file through the local web server loopback address to confirm permissions and SELinux contexts are correct
curl -s http://localhost/active-shells-link.txt

* EXPECTED: Output displaying a list of users with /bin/bash or /bin/zsh at the end of their /etc/passwd entry.

4. COMPREHENSIVE CLEANUP (ZERO-TRACE)

# Remove the custom SELinux file context policy we added for the audit directory
semanage fcontext -d -t httpd_sys_content_t '/opt/audit-data(/.*)?'

# Remove the symbolic link from the web server document root
rm -f /var/www/html/active-shells-link.txt

# Recursively forcefully remove the audit directory and its contents
rm -rf /opt/audit-data

# Stop the web server and disable it from starting on boot
systemctl disable --now httpd