diff --git a/README.md b/README.md index ea69277..705e03a 100644 --- a/README.md +++ b/README.md @@ -286,6 +286,8 @@ For further details see: **[90-ciss-local.hardened.md](docs/documentation/90-cis * **Description**: Disables and blacklists non-essential or insecure kernel modules. * **Rationale**: Minimizes attack surface by preventing loads of drivers or modules not required by the live environment. +For further details see: **[30-ciss-hardening.conf.md](docs/documentation/30-ciss-hardening.conf.md)** + ## 2.3. Network Hardening At the kernel level classical ``sysctl`` settings are applied that defend against spoofing and sloppy network behavior. Reverse path diff --git a/config/hooks/live/zzzz_ciss_crypt_squash.hook.binary b/config/hooks/live/zzzz_ciss_crypt_squash.hook.binary index 3603137..c23309a 100644 --- a/config/hooks/live/zzzz_ciss_crypt_squash.hook.binary +++ b/config/hooks/live/zzzz_ciss_crypt_squash.hook.binary @@ -72,7 +72,7 @@ declare -i VAR_ROOTFS_SIZE=$(stat -c%s -- "${ROOTFS}") # - Filesystem-Slack declare -i OVERHEAD_FIXED=$((64 * 1024 * 1024)) declare -i OVERHEAD_PCT=3 -declare -i ALIGN_BYTES=$(( 4096 * 1024 )) +declare -i ALIGN_BYTES=$(( 1024 * 1024 )) declare -i BASE_SIZE=$(( VAR_ROOTFS_SIZE + OVERHEAD_FIXED + (VAR_ROOTFS_SIZE * OVERHEAD_PCT / 100) )) declare -i VAR_LUKSFS_SIZE=$(( ( (BASE_SIZE + ALIGN_BYTES - 1) / ALIGN_BYTES ) * ALIGN_BYTES )) @@ -107,9 +107,10 @@ while (( TRY < MAX_TRIES )); do CRYPT_RC=0 exec {KEYFD}<&- break + else + CRYPT_RC="$?" fi - CRYPT_RC="$?" exec {KEYFD}<&- printf "\e[93m++++ ++++ ++++ ++++ ++++ ++++ ++ ❌ [cryptsetup failed for size %s (rc=%s), increasing by %s bytes.] \e[0m\n" "${TRY_SIZE}" "${CRYPT_RC}" "${ALIGN_BYTES}" diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md index fcc0d86..0dc9dd9 100644 --- a/docs/CHANGELOG.md +++ b/docs/CHANGELOG.md @@ -13,6 +13,7 @@ include_toc: true # 2. Changelog ## V8.13.544.2025.12.05 +* **Added**: [30-ciss-hardening.conf.md](documentation/30-ciss-hardening.conf.md) * **Added**: [90-ciss-local.hardened.md](documentation/90-ciss-local.hardened.md) * * **Bugfixes**: [zzzz_ciss_crypt_squash.hook.binary](../config/hooks/live/zzzz_ciss_crypt_squash.hook.binary) + Adjusted ``OVERHEAD_PCT`` for Gitea Runner diff --git a/docs/documentation/30-ciss-hardening.conf.md b/docs/documentation/30-ciss-hardening.conf.md new file mode 100644 index 0000000..ee88660 --- /dev/null +++ b/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**
+*Debian Live Build Generator for hardened live environment and CISS Debian Installer*
+**Master Version**: 8.13
+**Build**: V8.13.544.2025.12.05
+ +# 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 /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/)** + diff --git a/docs/documentation/90-ciss-local.hardened.md b/docs/documentation/90-ciss-local.hardened.md index d43f4e8..91d9655 100644 --- a/docs/documentation/90-ciss-local.hardened.md +++ b/docs/documentation/90-ciss-local.hardened.md @@ -10,7 +10,7 @@ include_toc: true **Master Version**: 8.13
**Build**: V8.13.544.2025.12.05
-# 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 diff --git a/docs/documentation/ciss_live_builder.sh.md b/docs/documentation/ciss_live_builder.sh.md index 31504fe..3acd768 100644 --- a/docs/documentation/ciss_live_builder.sh.md +++ b/docs/documentation/ciss_live_builder.sh.md @@ -10,7 +10,7 @@ include_toc: true **Master Version**: 8.13
**Build**: V8.13.544.2025.12.05
-# 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