V8.13.544.2025.12.05

Signed-off-by: Marc S. Weidner <msw@coresecret.dev>

docs/documentation/30-ciss-hardening.conf.md

@@ -0,0 +1,88 @@
+---
+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.544.2025.12.05<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 -->

docs/documentation/90-ciss-local.hardened.md

@@ -10,7 +10,7 @@ include_toc: true
 **Master Version**: 8.13<br>
 **Build**: V8.13.544.2025.12.05<br>
 
-# 2. 90-ciss-local.hardened
+# 2. ``90-ciss-local.hardened``
 
 The configuration fragment ``90-ciss-local.hardened`` defines the local kernel and network hardening baseline that CISS systems 
 apply via the Linux ``sysctl`` mechanism. It is written as a conventional ``sysctl.d`` drop-in and is meant to be consumed by early 

docs/documentation/ciss_live_builder.sh.md

@@ -10,7 +10,7 @@ include_toc: true
 **Master Version**: 8.13<br>
 **Build**: V8.13.544.2025.12.05<br>
 
-# 2. ciss_live_builder.sh
+# 2. ``ciss_live_builder.sh``
 
 This module implements the primary orchestration entry point for the ``CISS.debian.live.builder`` toolchain and drives the 
 complete lifecycle of a hardened Debian live ISO build in a single, linear control flow. It is responsible for validating the