Chapter 7 — Security: SELinux, AppArmor, patching, baseline
Identify the MAC layer, then fix causes — not the enforcement
Security controls differ by distribution: SELinux is commonly enabled/enforcing on Fedora/RHEL-family systems; AppArmor is installed and loaded by default on Ubuntu. Check the active LSM and its state rather than assuming one, and inspect denial/audit logs alongside ordinary Unix permissions (RHEL 9: Using SELinux; Ubuntu Server AppArmor).
SELinux troubleshooting: inspect current mode and AVC denials, verify path labels and service domain, and correct labels/policy for the specific service; do not respond to a denial by disabling SELinux globally or making broad allow rules (RHEL 9: Using SELinux). Fedora/Red Hat tooling and policy guidance are distribution-specific (Fedora SELinux: getting started).
AppArmor: profiles have complain/learning and enforced modes; aa-complain changes a profile to permit-and-log; use complain mode for controlled profile testing, then tune a narrow profile and re-enforce. Disabling a profile removes confinement, and Ubuntu warns that disabling AppArmor reduces system security — never use global disable as a first diagnostic step (Ubuntu Server AppArmor).
Recursive SELinux relabeling belongs with the recursive-permission warnings of Chapter 2: inventory first, scope narrowly, and understand container volume relabel semantics before applying them to shared host paths (Chapter 8).
Patching: the distribution's tooling, the transaction in full
Patching is distribution-specific — use the configured package manager and supported repositories. Debian publishes security advisories and documents unattended-upgrades as a way to automate package updates (Debian Security). DNF5 has a --security advisory filter and an --allowerasing option that explicitly permits package removals (DNF5 upgrade). Either way: review the proposed package transaction — especially removals, kernel/service restarts, and reboot requirements — before confirming. A security-only filter is not a reason to skip that review (DNF5 upgrade; Debian Security).
Kernel updates and reboots are operational events: plan and verify them, and do not let unattended tooling reboot a control plane without an explicit decision.
Minimum security baseline
A defensible starting baseline for a Linux host (Debian Security; DNF5 upgrade; Ubuntu AppArmor; RHEL SELinux):
- a supported distribution release;
- vendor security updates applied within a defined, risk-based SLA; planned and verified kernel/reboot handling;
- unique named admin accounts with least privilege and MFA where supported;
- SSH key/certificate hygiene;
- no unnecessary listeners (Chapter 3:
ss -lntup); a host firewall with explicit allowed services (Chapter 4); - securely stored secrets; encrypted sensitive storage (Chapter 5);
- audit/logging (Chapter 3; Chapter 9);
- SELinux or AppArmor maintained in its intended enforcing posture.
Monitoring baseline
Minimum signals to instrument: host reachability and service probes; CPU/load and saturation; memory, swap, and OOM events; filesystem free bytes and inodes; disk I/O latency/error/health; RAID degraded/rebuild status; network; certificate expiry; backup last-success age, size/change anomalies, and repository-check state; log pipeline health (Prometheus Node Exporter guide; Prometheus alerting practices). Prometheus Node Exporter exposes hardware/kernel metrics (documented examples include CPU, filesystem available bytes, network rates); its endpoint is a metrics service and should be reachable only from the monitoring plane, not exposed indiscriminately (Prometheus security).
Observability hygiene: centralize or forward critical logs off-host; preserve the journal across reboots if it is the primary log store; synchronize clocks; restrict log access; retain enough data for detection and investigation; and test alert delivery (journalctl(1)).
One-page dashboard questions worth building toward: Is the host/service reachable? Is any resource approaching exhaustion? Is storage healthy and redundant? Did a recoverable backup complete recently? Can the team restore it? Are important logs arriving? (df(1); Node Exporter; journalctl(1); restic checks)
Thresholds are policy, not physics. No universal numeric thresholds for disk utilization, inode pressure, SMART attributes, alert durations, patch deadlines, RPO/RTO, backup retention, or log retention are appropriate without workload and risk context — publish example starting values only as adjustable choices (operations notes).