Marc S. Weidner
2e50dd9535
Signed-off-by: Marc S. Weidner <msw@coresecret.dev>
7.6 KiB
Table of Contents
1. CISS.debian.live.builder
Centurion Intelligence Consulting Agency Information Security Standard
Debian Live Build Generator for hardened live environment and CISS Debian Installer
Master Version: 8.13
Build: V8.13.768.2025.12.06
2. 30-ciss-hardening.conf
This module is a kernel module loading policy file intended to be installed under /etc/modprobe.d/30-ciss-hardening.conf in
systems produced by CISS.debian.live.builder, and the associated CISS.debian.installer.secure framework. It constrains
the Linux kernels an automatic module loading mechanism by replacing the load actions for a broad set of rarely required modules
with a no-op handler and by blacklisting others, to reduce the attack surface available to unprivileged users and remote attackers.
The configuration addresses the general class of vulnerabilities where an unprivileged actor can provoke the kernel into
autoloading a protocol or filesystem module, then exploit a defect in that module. The introductory comment explicitly
references CVE-2017-6074 as an example, where the DCCP protocol module could be pulled into memory simply by initiating a
DCCP connection. To counter this pattern, the file uses install <module> /bin/true rules to override the normal modprobe
behavior. When user space, or the kernel attempts to load one of these modules, modprobe executes /bin/true instead of
loading the module, returns success, and leaves the module absent from the running kernel.
The first group of install directives disables a series of network protocol stacks and link layer implementations that are
considered exotic in contemporary hardened server or appliance environments. These include DCCP, SCTP, RDS, TIPC,
HDLC line discipline support, amateur-radio-oriented protocols such as AX.25, NET/ROM, and ROSE, legacy
internetworking protocols like DECnet, IPX, and AppleTalk, as well as CAN bus, ATM networking, and
IEEE 802.15.4 support. In the absence of this file, many of these modules could be autoloaded in response to crafted traffic
reaching the host; with this policy in place, such attempts silently fail at the module loading step, and the packets are
processed without activating the corresponding kernel subsystems.
The next section targets filesystem support that is not expected to be needed in the envisaged deployment scenarios. The module
defines install rules and explicit blacklist entries for legacy or niche on-disk formats such as CRAMFS, FreeVxFS,
JFFS2, HFS, HFS+, and UDF. On a system using this configuration unmodified, attempts to mount volumes of these
types will not cause the kernel modules to load automatically; instead, the mount will fail because the filesystem
implementation never becomes available. The combination of install /bin/true and blacklist ensures that neither direct
modprobe calls in user space nor automatic resolution through modalias can pull these modules in.
A separate block disables network filesystems that could otherwise be used to introduce complex protocol stacks and large code
paths into the kernel. The file defines install and blacklist rules for CIFS, NFS, including explicit nfsv3
and nfsv4 aliases, the in-kernel SMB server ksmbd, and the cluster filesystem gfs2. Systems hardened with this
module therefore cannot mount CIFS or NFS shares, nor can they serve SMB via ksmbd, unless this policy file is
removed or overridden. This choice is a deliberate constraint: it trades the convenience of built-in remote filesystems for the
lower risk profile of a kernel that does not contain these historically vulnerable and feature-rich subsystems.
The configuration also addresses specific devices and miscellaneous drivers. USB mass storage, and the USB Attached SCSI (UAS)
transport are disabled by combining install usb-storage /bin/true, install uas /bin/true with corresponding blacklist
lines. This prevents the system from interacting with USB storage devices, which mitigates a range of data exfiltration, rogue
devices, and untrusted media scenarios. The FireWire core firewire-core is similarly blocked from loading via an install
rule, removing another hot-plug bus traditionally associated with direct memory access capabilities. The file also disables the
vivid video driver, noted in the comment as a testing-only driver with a history of privilege escalation issues, by
replacing its load operation with /bin/true.
In its final part, the module incorporates and extends a set of blacklist conventions originating from a kmod configuration in
a major distribution. It blacklists the evbug input event debugging driver, simple USB input drivers usbmouse, usbkbd
that are typically superseded by more modern subsystems, eth1394 which can create confusing extra network interfaces, and
the pcspkr driver for the legacy PC speaker. These entries do not use install /bin/true and therefore only prevent
automatic loading based on modalias; they do not fully override manual modprobe invocations, which aligns with their purpose
as quality-of-life and clarity improvements rather than hard prohibitions.
Within the overall CISS.debian.live.builder and CISS.debian.installer.secure workflow, this file is purely declarative.
Its inputs are the module names hard-coded in the configuration, and the fixed mapping of those names to either /bin/true or
blacklist semantics, and it has no runtime parameters or external dependencies beyond the standard kmod / modprobe stack. The
principal side effect is systemic: once present in /etc/modprobe.d and read by kmod during module resolution, it constrains,
which kernel modules can ever be introduced into the running kernel via normal loading pathways. This affects the live system
boots produced by the builder as well as installed systems provisioned by the installer, assuming the file is propagated into
the target root filesystem.
The configuration assumes that the target systems do not rely on the disabled protocols, filesystems, or device classes. In
environments where CIFS or NFS mounts, CAN bus interfaces, IEEE 1394 peripherals, or USB mass storage are
operationally required, administrators must explicitly adjust or remove this module. There is no internal mechanism for
conditional activation, staging, or feature detection. From a hardening perspective, the absence of dynamic control is
intentional: the file embodies a closed, conservative policy that removes entire classes of kernel functionality rather than
trying to selectively mediate their use.
There is no error handling logic in the conventional sense, because the file is not an executable script. The only behavioral
nuance lies in the use of /bin/true for the install directives. This design causes callers that request a module to
observe a successful return code from the modprobe even though the module is not present afterward. Some tooling that
naively checks only the exit status might therefore believe that the module was loaded. For the purposes of hardening, this
discrepancy is acceptable: it guarantees that the module never enters the kernel while keeping the calling code simple, at the
cost of possibly opaque failure modes that must be understood by system integrators using this configuration.
no tracking | no logging | no advertising | no profiling | no bullshit