Red Hat Enterprise Linux operations

1. Know what is installed

RPM tracks installed packages; DNF resolves packages and dependencies through repositories. The running kernel can differ from the newest installed kernel until a reboot. Inventory before planning maintenance.

cat /etc/redhat-release
uname -r
rpm -q kernel openssh-server
dnf repolist

What to expect

Distribution version, running kernel, installed package versions and configured repositories. A missing package is reported explicitly.

A newer kernel may be installed but not booted. Confirm boot configuration and schedule a tested reboot; installing a package does not prove it is active.

Watch for: Do not mix repositories from incompatible major releases.

2. Read service evidence

A unit may be enabled for startup but currently failed. journalctl can limit evidence to this boot and this service. The SSH daemon is commonly named sshd on RHEL.

systemctl status sshd --no-pager
systemctl is-enabled sshd
journalctl -u sshd -b --no-pager -n 30

What to expect

Current SSH unit status, enablement state, and recent accessible logs. A VM without SSH installed will report no unit.

The active state and application reachability answer current operation. Enablement describes startup configuration. Inspect logs before restarting.

Watch for: Restarting can disrupt access and erase transient evidence; retain console access.

3. Inspect security controls

SELinux labels and policy add mandatory access checks beyond Unix mode bits. firewalld zones group network policy. An application failure can involve either control, neither, or both. Gather specific evidence.

getenforce
ls -Zd /var/log
# On a lab host with firewalld, with permission:
sudo firewall-cmd --get-active-zones

What to expect

SELinux mode, a directory context, and active firewall zones if the daemon is running.

It removes a security boundary without correcting labels or the access design. Check the audit denial, expected context and documented policy, then make a narrow tested correction.

Watch for: Do not run chmod 777, flush all rules, or disable enforcement to conceal the cause.

4. Repair a file label without disabling SELinux

Before this lesson: Complete the Linux permissions/services lessons and RHEL lessons 1–3. Use a fresh disposable RHEL 9 VM with targeted SELinux in Enforcing mode, console access, a rollback snapshot and working RHEL repositories. Reserve TCP port 80 for this lab. Run only in a lab isolated from work networks; sudo below intentionally installs packages and changes that VM. RHEL 10, containers and permissive hosts are outside this worked environment.

Outcome: distinguish a Unix permission problem from an SELinux type mismatch, then make the expected label survive a relabel. Ordinary mode bits and SELinux are separate checks. A readable file can still be denied to a confined httpd process. A file context contains user, role, type and level fields; this exercise concentrates on the type field rather than treating the whole context as a Unix owner name.

A local file-context rule describes the label a path should have. semanage fcontext records that rule; restorecon applies it to existing files. chcon changes a current label without creating that path rule. This distinction explains a frequent incident: a manually corrected file works today but is relabeled incorrectly later. For this static, read-only web content, use httpd_sys_content_t; do not grant write-oriented types or unrelated network booleans to solve a read problem.

The lab creates one new directory, one text file and one Apache Alias available only to local clients. It deliberately gives the directory tree an unsuitable user_home_t label so the denial has a controlled cause. The preparation script refuses to overwrite its reserved paths. Start from the VM snapshot rather than rerunning preparation over a partly completed lab. If a package install, config test or service start fails, resolve that step before interpreting any HTTP result.

Save the three Bash files below. Run them in numbered order, reading each before execution; pause after 02-observe.sh. First confirm Enforcing, then inspect the response, Unix modes, labels and audit events together. The expected failure is HTTP 403 with evidence of an httpd_t subject trying to access an unsuitable file type. A 404 suggests an Alias/path mistake; a connection refusal suggests a listener problem; a 403 without a matching AVC needs Apache authorization and ordinary permissions checked too. Do not invent an AVC merely because this exercise predicts one.

In the correction script, the quoted path expression matches the lab directory and descendants. Its parentheses, slash and wildcard belong to SELinux's file-path pattern, so the shell must receive it as one literal argument. Preview with restorecon -nRv before applying restorecon -Rv. The mapping alone does not rewrite existing labels. After relabeling, compare actual labels to the expected defaults with matchpathcon and request the exact same URL again. Repeat the preview: there should be no remaining label changes for this tree.

This success proves a narrowly scoped static read with enforcement on; it does not prove a secure application deployment. Upload permissions, TLS, remote firewalld policy and service-account design are separate lessons. No firewall is opened here. For cleanup, revert the disposable VM snapshot after retaining your notes. If you retain the VM instead, stop using the Alias before removing the lab files and its exact local context rule; do not run a broad relabel or delete another administrator's rules.

#!/usr/bin/env bash
set -euo pipefail
[[ "$(getenforce)" == Enforcing ]] || { echo "Requires Enforcing RHEL 9 lab"; exit 1; }
[[ ! -e /srv/auwen-label-lab && ! -e /etc/httpd/conf.d/auwen-label-lab.conf ]] || {
  echo "Reserved path exists; use a fresh lab snapshot"; exit 1;
}
sudo dnf install -y httpd policycoreutils-python-utils audit curl
sudo install -d -m 0755 /srv/auwen-label-lab
printf 'AUWEN label lab OK
' | sudo tee /srv/auwen-label-lab/probe.txt >/dev/null
sudo chmod 0644 /srv/auwen-label-lab/probe.txt
sudo tee /etc/httpd/conf.d/auwen-label-lab.conf >/dev/null <<'APACHE'
Alias /auwen-label-lab /srv/auwen-label-lab
<Directory /srv/auwen-label-lab>
    AllowOverride None
    Options -Indexes
    Require local
</Directory>
APACHE
# Deliberate bad label, on this disposable tree only.
sudo chcon -R -t user_home_t /srv/auwen-label-lab
sudo httpd -t
sudo systemctl start httpd
sudo systemctl reload httpd

#!/usr/bin/env bash
set -eu
getenforce
ls -ldZ /srv/auwen-label-lab
ls -lZ /srv/auwen-label-lab/probe.txt
# Do not use --fail here: an HTTP error response is evidence to read.
curl --noproxy '*' --max-time 5 -i http://127.0.0.1/auwen-label-lab/probe.txt
sudo ausearch -m AVC,USER_AVC -ts recent -i

#!/usr/bin/env bash
set -euo pipefail
# Stop if an existing local rule conflicts; inspect it rather than overwriting it.
sudo semanage fcontext -a -t httpd_sys_content_t '/srv/auwen-label-lab(/.*)?'
sudo restorecon -nRv /srv/auwen-label-lab
# Continue only after reviewing that the preview is confined to the lab tree.
read -r -p 'Apply the reviewed labels? Type APPLY: ' decision
[[ "$decision" == APPLY ]] || exit 1
sudo restorecon -Rv /srv/auwen-label-lab
matchpathcon -V /srv/auwen-label-lab /srv/auwen-label-lab/probe.txt
curl --noproxy '*' --max-time 5 --fail -i http://127.0.0.1/auwen-label-lab/probe.txt
sudo restorecon -nRv /srv/auwen-label-lab
getenforce

Run it

bash 01-prepare.sh
bash 02-observe.sh
# Inspect the response and audit evidence before proceeding.
bash 03-correct.sh

What to expect

Before repair: Enforcing, directory 0755/file 0644, user_home_t type, a predicted 403 and a related AVC. ausearch returning no matches is a diagnostic result, not a completed check. After repair: httpd_sys_content_t, successful matchpathcon verification and HTTP 200 with “AUWEN label lab OK”. The last dry run should propose no further relabeling and getenforce should still report Enforcing. These are learner checkpoints, not output captured on this publishing host.

1. In the enforcing lab, the read should fail again. The persistent mapping still exists, so:
sudo chcon -t user_home_t /srv/auwen-label-lab/probe.txt
sudo restorecon -v /srv/auwen-label-lab/probe.txt
matchpathcon -V /srv/auwen-label-lab/probe.txt
The repair should restore httpd_sys_content_t. Repeat the HTTP request and record the result.
2. chmod changes discretionary permissions, not the SELinux type or allow rules. It would broaden ordinary access without explaining this denial.
3. ls -Z shows the current context; matchpathcon shows the expected context for the path. If the expected type is correct but the current label differs, a narrow restorecon is appropriate. If the expected type is also wrong, inspect the intended path rule first. A moved file may retain its old label.
Ready to continue when your evidence links one failed request to its label cause, the corrected request succeeds with enforcement on, and a second relabel has no further work. Keep booleans, writable web directories and remote exposure planned until their separate access requirements are understood.

Watch for: Do not treat every 403 as SELinux. Missing audit records, Unix traversal permissions, Apache Require rules and an absent listener need separate checks. Do not disable enforcement, turn on broad booleans, generate an allow module blindly or relabel all of /srv. The local-only Apache rule is application access control, not a claim that other virtual hosts are private.

Lesson references

• Red Hat RHEL 9: non-standard service paths and verification (checked 28 September 2026) ↗
• Red Hat RHEL 9: AVCs, incorrect labels and persistent mappings ↗
• Apache 2.4: Alias and directory authorization ↗
• Apache 2.4: Require local ↗