Disable IEEE 1394 (FireWire) Support
Ensures the firewire-core kernel module is not loaded and is blacklisted so the DMA-capable FireWire stack cannot be activated.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
FireWire (IEEE 1394) grants connected devices DMA access to system memory, so a malicious peripheral can read or write RAM directly, bypassing the OS to steal keys or inject code (a classic physical-access/DMA attack). On systems that do not use FireWire, disabling the module protects against exploitation of any flaws in its implementation and closes this DMA vector.
What Pavois checks
Pavois uses kernel_module('firewire-core') to assert the module is not loaded and is disabled in the effective modprobe policy. Inspecting the live kernel and resolved modprobe config (not a lone .conf) catches a module blacklisted in one file yet still loaded, or re-enabled by an override drop-in.
describe kernel_module('firewire-core') do
it { should_not be_loaded }
it { should be_disabled }
endHow to verify it is applied
Run lsmod | grep firewire (no output = not loaded) and modprobe -n -v firewire_core (expect install /bin/true or /bin/false). modprobe --showconfig | grep firewire shows the effective rules.
Inspect & investigate
Blocked load attempts appear in the kernel log: journalctl -k | grep -i firewire / dmesg | grep -i firewire. lsmod shows resident modules; modprobe --showconfig shows the policy.
Remediation
pavois harden apply uses the kernel_module resource to blacklist firewire_core: it writes a modprobe rule (install firewire_core /bin/false plus a blacklist entry) preventing auto-load when a FireWire device appears, and unloads it if resident. reboot_required is true to fully remove the dependent FireWire driver stack.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| action | blacklist |
|---|---|
| name | firewire-core |
| reboot_required | true |
| resource | kernel_module |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
On a standard server, disabling FireWire has no functional impact, IEEE 1394 ports are essentially gone from modern hardware. Precaution: the rare host using FireWire audio/video capture or external 1394 storage would lose those devices; confirm none are in use (lspci | grep -i 1394, lsmod | grep firewire) before applying. A reboot is needed to unload an already-loaded stack.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| CIS | 1.1.1.9 | direct | per OS, see the benchmark table | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.