CISS.debian.live.builder/docs/documentation/30-ciss-hardening.conf.md

---
gitea: none
include_toc: true
-----------------

# 1. CISS.debian.live.builder

**Centurion Intelligence Consulting Agency Information Security Standard**<br>
*Debian Live Build Generator for hardened live environment and CISS Debian Installer*<br>
**Master Version**: 8.13<br>
**Build**: V8.13.768.2025.12.06<br>

# 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](https://coresecret.eu/)**
<!-- vim: set number et ts=2 sw=2 sts=2 ai tw=128 ft=markdown -->