System hardening
Configuring a system so that fewer things can go wrong on purpose: remove what isn't needed, restrict what is, and log what happens. It's the layer of defensive-security that runs before any attacker shows up, and it's mostly unglamorous configuration — trimstray's guide is a long list of settings with reasons attached.
The shape of the work
The guide's chapter structure is the practice in miniature: rationale → solution → comments → resources. Each control names the threat it addresses before it names the setting, which is the part that distinguishes hardening from cargo-culting a config file. A control you can't justify is a control you'll revert the first time it breaks something.
Typical surfaces: boot and kernel parameters, filesystem mount options, package and service minimization, account and authentication policy, network stack and firewall defaults, logging and audit configuration, and integrity checking. The guide targets RHEL 7 / CentOS 7, which dates it — but the categories outlive any distribution version.
Why it's benchmark-shaped
Hardening is where security meets audit, so the controls get published as benchmarks (CIS, STIG) and checked by tooling (OpenSCAP) rather than argued case by case. That's a real strength — a documented baseline you can measure drift against — and a real weakness: a system can be fully compliant and still trivially compromised through the application running on it, which no host benchmark inspects.
The automation seam
A written guide tells a human what to change; a configuration framework makes it repeatable. The guide points at the DevSec Hardening Framework (dev-sec.io) for that, which is where hardening stops being a document and becomes code — and where it acquires the ordinary problems of infrastructure code: drift, exceptions, and settings nobody remembers enabling.
Patch latency became an exploit primitive (2026-09-19)
The hardening literature treats patching as hygiene with a cadence attached. vms-wont-contain-agents turns the cadence itself into the attack surface. Two of three hypervisor escapes there ran through the gap between an upstream fix and a distribution backport: one combined an unassigned bug-fix commit with a known CVE in an older stable package; another used a KVM bug patched upstream and absent from the distribution.
The reason this is new is not that unpatched software is exploitable. It is that an agent reading the commit which fixes a bug needs no advisory, no proof-of-concept and no write-up — so the disclosure asymmetry that made backport windows survivable is gone. Trail of Bits' conclusion is blunt and belongs on this page: older stable distributions should be assumed vulnerable.
That cuts against the operational instinct this practice usually encodes, which is that a slower, better-tested release train is the safer one. On this evidence, for a host running untrusted code, it is the more exposed one. See hypervisor-isolation for the surface side of the same finding.
Related
security-benchmark · practical-linux-hardening-guide · defensive-security · security-operations-center · hypervisor-isolation · vms-wont-contain-agents · firecracker