V8.13.536.2025.12.04
All checks were successful
🛡️ Shell Script Linting / 🛡️ Shell Script Linting (push) Successful in 1m30s
All checks were successful
🛡️ Shell Script Linting / 🛡️ Shell Script Linting (push) Successful in 1m30s
Signed-off-by: Marc S. Weidner <msw@coresecret.dev>
This commit is contained in:
235
README.md
235
README.md
@@ -32,6 +32,9 @@ include_toc: true
|
||||
**CISS.debian.live.builder — First of its own.**<br>
|
||||
**World-class CIA designed, handcrafted and powered by Centurion Intelligence Consulting Agency.**
|
||||
|
||||
Developed and maintained as a one-man, security-driven engineering effort since 2024, **CISS.debian.live.builder** is designed
|
||||
to serve as a reference implementation for hardened, image-based Debian deployments.
|
||||
|
||||
This shell wrapper automates the creation of a Debian Trixie live ISO hardened according to the latest best practices in server
|
||||
and service security. It integrates into your build pipeline to deliver an isolated, robust environment suitable for cloud
|
||||
deployment or unattended installations via the forthcoming `CISS.debian.installer`. Additionally, automated CI workflows based
|
||||
@@ -45,7 +48,7 @@ with a hardened initramfs chain including a dedicated Dropbear build pipeline fo
|
||||
with a hardened kernel configuration, strict sysctl and network tuning, pre-configured SSH hardening and fail2ban, and a
|
||||
customised `verify-checksums` path providing both ISO-edge verification and runtime attestation of the live root. All components
|
||||
are aligned with the `CISS.debian.installer` baseline, ensuring a unified cryptographic and security posture from first boot to
|
||||
an installed system. For an overview over the entire build process, see:
|
||||
an installed system. For an overview of the entire build process, see:
|
||||
**[MAN_CISS_ISO_BOOT_CHAIN.md](docs/MAN_CISS_ISO_BOOT_CHAIN.md)**
|
||||
|
||||
Check out more leading world-class services powered by Centurion Intelligence Consulting Agency:
|
||||
@@ -59,13 +62,14 @@ Check out more leading world-class services powered by Centurion Intelligence Co
|
||||
* [Contact the author](https://coresecret.eu/contact/)
|
||||
|
||||
**Legal Disclaimer:**
|
||||
* This project is not affiliated with, authorized, maintained, sponsored, or endorsed by [Debian Project](https://www.debian.org/)
|
||||
* [Centurion Imprint](https://coresecret.eu/imprint/)
|
||||
* [Centurion Privacy](https://coresecret.eu/privacy/)
|
||||
* This project is not affiliated with, authorized, maintained, sponsored, or endorsed by the [Debian Project](https://www.debian.org/)
|
||||
* [Centurion Imprint & Legal Notice](https://coresecret.eu/imprint/)
|
||||
* [Centurion Privacy Policy](https://coresecret.eu/privacy/)
|
||||
|
||||
## 1.1. Preliminary Remarks
|
||||
|
||||
### 1.1.1. HSM
|
||||
|
||||
Please note that all my signing keys are stored in an HSM and that the signing environment is air-gapped. The next step is to
|
||||
move to a room-gapped environment. ^^
|
||||
|
||||
@@ -77,57 +81,48 @@ add_header Expect-CT "max-age=86400, enforce"
|
||||
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
|
||||
````
|
||||
|
||||
* Additionally, the entire zone is dual-signed with **DNSSEC**. See the current **DNSSEC** status at: **[DNSSEC Audit Report](/docs/AUDIT_DNSSEC.md)**
|
||||
* A comprehensive TLS audit of the **`git.coresecret.dev`** Gitea server is also available. See: **[TLS Audit Report](/docs/AUDIT_TLS.md)**
|
||||
* The infrastructure of the **`CISS.debian.live.builder`** building system is visualized here. See: **[Centurion Net](/docs/CNET.md)**
|
||||
* The zones behind this project are dual-signed with **DNSSEC**. The current validation state is documented in the **[DNSSEC Audit Report](/docs/AUDIT_DNSSEC.md)**
|
||||
* The TLS surface of **``git.coresecret.dev``** is independently audited, and the findings are held in the **[TLS Audit Report](/docs/AUDIT_TLS.md)**
|
||||
* The topology of the underlying **`CISS.debian.live.builder`** building infrastructure is described in **[Centurion Net](/docs/CNET.md)**
|
||||
|
||||
### 1.1.3. Gitea Action Runner Hardening
|
||||
|
||||
The CI runners operate on a dedicated host system located in a completely separate Autonomous System (AS). This host is solely
|
||||
dedicated to providing CI runners and does not perform any other tasks. Each runner is hermetically isolated from others using
|
||||
non-privileged, shell-less user accounts with no direct login capability. Additionally, each runner executes within its own
|
||||
separate directory tree, employs `DynamicUser` features, and adheres to strict systemd hardening policies (achieving a ``systemd-analyze security``
|
||||
rating of **``2.6``**). Docker containers used by runners do not run in privileged mode. Security is further enhanced through the use
|
||||
of both UFW software firewalls and dedicated hardware firewall appliances.
|
||||
The CI runners live on a host in a separate autonomous system, and that host has exactly one purpose: run Gitea Actions runners.
|
||||
Each runner receives its own service account without a login shell, is bound to a separate directory tree, and inherits a
|
||||
hardened systemd unit with ``DynamicUser``, reduced capabilities, and restrictive sandboxing. A ``systemd-analyze security`` score
|
||||
of around **``2.6``** is the baseline, not an aspiration. Traffic from those runners traverses both a software firewall (UFW)
|
||||
and dedicated hardware firewall appliances. Docker, where used, runs unprivileged.
|
||||
|
||||
## 1.2. Match Host and Target Versions
|
||||
|
||||
Build, for example, a Debian Trixie live image only on a Debian Trixie host. The build toolchain and boot artifacts are
|
||||
release-specific: ``live-build``, ``live-boot``, ``live-config``, ``debootstrap``, ``kernel/initramfs`` tools, ``mksquashfs``,
|
||||
``GRUB/ISOLINUX``, and even ``dpkg/apt`` often change defaults and formats between releases (e.g., compression modes, SquashFS
|
||||
options, hook ordering, systemd/udev behavior). Building on a different host release commonly yields non-reproducible or even
|
||||
unbootable ISOs (missing modules/firmware, ABI mismatches, divergent paths). Keeping host and target on the same version ensures
|
||||
reproducible builds, matching dependencies, and compatible boot artifacts.
|
||||
I always build a Debian Trixie live image on a Debian Trixie host. The toolchain and all boot components that matter to
|
||||
reproducibility are release-specific: ``live-build``, ``live-boot``, ``live-config``, ``debootstrap``, ``mksquashfs``, ``grub``,
|
||||
the ``kernel``, ``initramfs`` tooling, and even ``dpkg`` and ``apt`` defaults evolve from one release to the next. Mixing
|
||||
generations produces fragile or outright broken ISOs, sometimes subtly, sometimes catastrophically. Keeping host and target in
|
||||
lockstep avoids those mismatches and gives me predictable artifacts across builds.
|
||||
|
||||
## 1.3. Immutable Source-of-Truth System
|
||||
## 1.3. Immutable Source-of-Truth System and Encrypted Live Root
|
||||
|
||||
This live ISO establishes a secure, fully deterministic, integrity self-verifying boot environment based entirely on static
|
||||
source-code definitions. All configurations, system components, and installation routines are embedded during build time and
|
||||
locked for runtime immutability. This ensures that the live environment functions as a trusted **Source of Truth** — not only
|
||||
for boot-time operations, but for deploying entire systems in a secure and reproducible way.<br>
|
||||
The live ISO acts as a sealed, immutable execution environment. All relevant configuration, all installation logic, and all
|
||||
security decisions are rendered into the image at build time and treated as read-only at runtime. On top of that logical
|
||||
immutability, I now layer cryptographic protection of the live root file system itself. The live image contains a LUKS2 container
|
||||
file with dm-integrity that wraps the SquashFS payload. The initramfs knows how to locate this container, unlock it, verify its
|
||||
integrity, and then present the decrypted SquashFS as the root component of an OverlayFS stack. The detailed boot and
|
||||
verification chain is documented separately in **[CISS ISO Boot Chain](docs/MAN_CISS_ISO_BOOT_CHAIN.md)**<br>
|
||||
|
||||
Once booted, the environment optionally launches a fully scripted installer, via the forthcoming `CISS.debian.installer`,
|
||||
yet to deploy, that provisions the target system (the hardware the DVD is running on). The installer pulls no external
|
||||
dependencies besides of the necessary Debian debootstrap and Debian Packages and never exposes the target system in a not
|
||||
secure manner to the internet during installation. It operates strictly from within the verified image content, providing fully
|
||||
secured provisioning. Combined with checksum verification, **activated by default**, at boot and strict firewall defaults, this
|
||||
architecture guarantees that what is executed has not been tampered with and corresponds exactly to the intended source definition.<br>
|
||||
In compact form, my expectations for the system are:<br>
|
||||
|
||||
An even more secure deployment variant — an unattended and headless version — can be built without any active network interface
|
||||
or shell-access, also via the forthcoming `CISS.debian.installer`. Such a version performs all verification steps autonomously,
|
||||
provisions the target device from embedded source artifacts, and reboots into a fully encrypted system image. The system then
|
||||
awaits the decryption passphrase input via an embedded Dropbear SSH server (SSH PubKey only) in the initramfs, exposing no ports
|
||||
without cryptographic hardened access, while also the `/boot` partition could be encrypted via the built-in support of
|
||||
`grub2 (2.12-9)`.<br>
|
||||
* Every bit that matters for boot and provisioning is covered by checksums that I control and that are signed with keys under my solely authoritative HSM.
|
||||
* The live root runs out of a LUKS2 dm-integrity container so that a tampered or bit-rotted SquashFS never becomes a trusted root.
|
||||
* Verification steps are not advisory. Any anomaly causes a hard abort during boot.
|
||||
* After the live environment has reached a stable, verified state, it can hand off to ``CISS.debian.installer``. The installer operates from the same image, does not pull random payloads from the internet, and keeps the target system behind a hardened firewall until the entire provisioning process has completed.
|
||||
* For unattended, headless scenarios I also support builds where the target system is installed without ever exposing a shell over the console. After installation and reboot, the machine waits for a decryption passphrase via an embedded Dropbear SSH instance in the initramfs, limited to public key authentication and guarded by strict cryptographic policies. In such variants even ``/boot`` can be encrypted, with GRUB taking care of unlocking the boot partition.
|
||||
|
||||
This approach provides a fully reproducible, audit-friendly, and tamper-resistant provisioning workflow rooted entirely in
|
||||
source-defined infrastructure logic.<br>
|
||||
These combinations give me a provisioning chain that is auditable, reproducible, and robust against both casual and targeted tampering.<br>
|
||||
|
||||
After build and configuration, the following audit reports can be generated:
|
||||
Once the system is up, I can trigger a set of audits from within the live environment:
|
||||
|
||||
* **Haveged Audit Report**: Validates entropy daemon health and confirms `/dev/random` seeding performance.
|
||||
Type `chkhvg` at the prompt. See example report: **[Haveged Audit Report](/docs/AUDIT_HAVEGED.md)**
|
||||
* **Lynis Audit Report**: Outputs a detailed security score and recommendations, confirming a 91%+ hardening baseline.
|
||||
* **Lynis Audit Report**: Outputs a detailed security score and recommendations, confirming a 93%+ hardening baseline.
|
||||
Type `lsadt` at the prompt. See example report: **[Lynis Audit Report](/docs/AUDIT_LYNIS.md)**
|
||||
* **SSH Audit Report**: Verifies SSH daemon configuration against the latest best-practice cipher, KEX, and MAC recommendations.
|
||||
Type `ssh-audit <IP>:<PORT>`. See example report: **[SSH Audit Report](/docs/AUDIT_SSH.md)**
|
||||
@@ -136,36 +131,27 @@ After build and configuration, the following audit reports can be generated:
|
||||
|
||||
|
||||
|
||||
## 1.5. Caution. Significant information for those considering using D-I.
|
||||
|
||||
## 1.5. Caution. Debian Installer and Security Context
|
||||
**The Debian Installer (d-i) will ALWAYS boot a new system.**<br>
|
||||
|
||||
Regardless of whether you start it:
|
||||
* via the boot menu of your Live ISO (grub, isolinux) like **CISS.debian.live.builder**,
|
||||
* via kexec in the running system,
|
||||
* via the debian-installer-launcher package,
|
||||
* or even via a graphical installer shortcut.
|
||||
The classical Debian Installer (d-i) always boots its own kernel and its own initramfs. That effect is independent of the way it
|
||||
is launched:
|
||||
|
||||
The following happens in all cases:
|
||||
* The installer kernel (/install/vmlinuz) + initrd.gz are started.
|
||||
* The existing live system is exited.
|
||||
* The memory is overwritten.
|
||||
* All running processes - e.g., firewall, hardened SSH access, etc. pp. - cease to exist.
|
||||
* from a GRUB entry on the live medium,
|
||||
* from within a running live session via a graphical shortcut,
|
||||
* through kexec,
|
||||
* or via helper packages such as debian-installer-launcher.
|
||||
|
||||
The Debian Installer loads:
|
||||
* its own kernel,
|
||||
* its own initramfs,
|
||||
* its own minimal root filesystem (BusyBox + udeb packages),
|
||||
* no SSH access (unless explicitly enabled via preseed)
|
||||
* no firewall, AppArmor, logging, etc. pp.,
|
||||
* it disables all running network services, even if you were previously in the live system.
|
||||
In all of these cases the running live system is discarded. The memory contents of the hardened live environment vanish, the
|
||||
firewall disappears, the hardened SSH daemon is terminated, and the hardened kernel is replaced by the installer kernel. The
|
||||
installer brings its own minimal root file system, usually BusyBox plus a limited set of udeb packages, and it does not
|
||||
implement my firewall, my AppArmor profiles, my logging configuration, or my remote access policies, unless I explicitly
|
||||
reintroduce those elements via preseed.
|
||||
|
||||
This means function status of the **CISS.2025.debian.live.builder** ISO after d-i start:
|
||||
* ufw, iptables, nftables ✘ disabled, not loaded,
|
||||
* sshd with hardening ✘ stopped (processes gone),
|
||||
* the running kernel ✘ replaced,
|
||||
* Logging (rsyslog, journald) ✘ not active,
|
||||
* preseed control over the network is possible (but without any protection).
|
||||
In that phase the security properties are therefore those of d-i, not those of CISS.debian.live.builder. This is not a defect in
|
||||
Debian, it is a property of how any installer that boots its own kernel behaves. It is important to keep this distinction in
|
||||
mind when deciding whether a workflow must stay inside the hardened live context or may trade that environment for the standard
|
||||
installer toolchain.
|
||||
|
||||
## 1.6. Versioning Schema
|
||||
|
||||
@@ -187,59 +173,62 @@ and only when, they appear in all capitals, as shown here.
|
||||
|
||||
# 2. Features & Rationale
|
||||
|
||||
Below is a breakdown of each hardening component, with a summary of why each is critical to your security posture.
|
||||
Below I walk through the major hardening components, with a focus on why I implemented them the way I did and how they interact.
|
||||
I treat this builder as a reference implementation for my own infrastructure; **it is not a toy**.
|
||||
|
||||
## 2.1. Kernel Hardening
|
||||
|
||||
### 2.1.1. Boot Parameters
|
||||
### 2.1.1. Unified Hardened Boot Parameters
|
||||
|
||||
* **Description**: Customizes kernel command-line flags to disable unused features and enable mitigations.
|
||||
* **Key Parameters**:
|
||||
* `audit_backlog_limit=8192`: Ensures the audit subsystem can queue up to 8192 events to avoid dropped logs under heavy loads.
|
||||
* `audit=1`: Enables kernel auditing from boot to record system calls and security events.
|
||||
* `cfi=kcfi`: Activates kernel control-flow integrity using kCFI to protect against control-flow hijacking.
|
||||
* `debugfs=off`: Disables debugfs to prevent non-privileged access to kernel internals.
|
||||
* `efi=disable_early_pci_dma`: Stops early PCI DMA under EFI to mitigate DMA-based attacks during boot.
|
||||
* `efi_no_storage_paranoia`: Disables extra EFI storage checks to streamline boot without compromising expected storage integrity.
|
||||
* `hardened_usercopy=1`: Enables stringent checks on copy operations between user and kernel space to prevent buffer overflows.
|
||||
* `ia32_emulation=0`: Turns off 32-bit compatibility modes to reduce attack surface on 64-bit hosts.
|
||||
* `init_on_alloc=1`: Zeroes memory on allocation to prevent leakage of previous data.
|
||||
* `init_on_free=1`: Initializes memory on free to catch use-after-free bugs.
|
||||
* `iommu=force`: Enforces IOMMU for all devices to isolate DMA-capable hardware.
|
||||
* `kfence.sample_interval=100`: Configures the kernel fence memory safety tool to sample every 100 allocations.
|
||||
* `kvm.nx_huge_pages=force`: Enforces non-executable huge pages in KVM to mitigate code injection.
|
||||
* `l1d_flush=on`: Flushes L1 data cache on context switch to mitigate L1D vulnerabilities.
|
||||
* `lockdown=confidentiality`: Puts the kernel in confidentiality lockdown to restrict direct hardware access.
|
||||
* `loglevel=0`: Suppresses non-critical kernel messages to reduce information leakage.
|
||||
* `mce=0`: Disables machine check exceptions to prevent side-channel data leaks from hardware error reporting.
|
||||
* `mitigations=auto,nosmt`: Enables all automatic CPU mitigations and disables SMT to reduce side-channel risks.
|
||||
* `mmio_stale_data=full,nosmt`: Ensures stale MMIO data is fully flushed and disables SMT for added protection.
|
||||
* `oops=panic`: Forces a kernel oops to trigger a panic, preventing the system from running in an inconsistent state.
|
||||
* `page_alloc.shuffle=1`: Randomizes physical page allocation to hinder memory layout prediction attacks.
|
||||
* `page_poison=1`: Fills freed pages with a poison pattern to detect use-after-free.
|
||||
* `panic=-1`: Disables automatic reboot on panic to preserve the system state for forensic analysis.
|
||||
* `pti=on`: Enables page table isolation to mitigate Meltdown attacks.
|
||||
* `random.trust_bootloader=off`: Prevents trusting entropy provided by the bootloader.
|
||||
* `random.trust_cpu=off`: Disables trusting CPU-provided randomness, enforcing external entropy sources.
|
||||
* `randomize_kstack_offset=on`: Randomizes the kernel stack offset on each syscall entry to harden against stack probing.
|
||||
* `randomize_va_space=2`: Enables full address space layout randomization (ASLR) for user space.
|
||||
* `retbleed=auto,nosmt`: Enables automatic RETBLEED mitigations and disables SMT for better side-channel resistance.
|
||||
* `rodata=on`: Marks kernel read-only data sections to prevent runtime modification.
|
||||
* `tsx=off`: Disables Intel TSX extensions to eliminate related speculative execution vulnerabilities.
|
||||
* `vdso32=0`: Disables 32-bit vDSO to prevent unintended cross-mode calls.
|
||||
* `vsyscall=none`: Disables legacy vsyscall support to close a potential attack vector.
|
||||
* **Rationale**: Ensures early activation of protections, reducing exposure to CPU vulnerabilities before the system fully boots.
|
||||
Both the ``CISS.debian.live.builder`` LIVE ISO and the ``CISS.debian.installer`` rely on the same kernel command line. I consider
|
||||
a diverging kernel baseline between installer and live system operationally dangerous, because it leads to two distinct sets of
|
||||
expectations about mitigations and attack surface. The boot parameters I apply are:
|
||||
|
||||
````bash
|
||||
apparmor=1 security=apparmor audit_backlog_limit=262144 audit=1 debugfs=off \
|
||||
efi=disable_early_pci_dma hardened_usercopy=1 ia32_emulation=0 \
|
||||
init_on_alloc=1 init_on_free=1 \
|
||||
iommu.passthrough=0 iommu.strict=1 iommu=force \
|
||||
kfence.sample_interval=100 kvm.nx_huge_pages=force \
|
||||
l1d_flush=on lockdown=integrity loglevel=0 \
|
||||
mitigations=auto,nosmt mmio_stale_data=full,force nosmt=force \
|
||||
oops=panic page_alloc.shuffle=1 page_poison=1 panic=0 pti=on \
|
||||
random.trust_bootloader=off random.trust_cpu=off randomize_kstack_offset=on \
|
||||
retbleed=auto,nosmt rodata=on slab_nomerge vdso32=0 vsyscall=none
|
||||
````
|
||||
|
||||
The parameters fall into several categories.
|
||||
|
||||
* The AppArmor-related flags ``apparmor=1``, ``security=apparmor`` guarantee that AppArmor is not an afterthought but an integral part of the security architecture from the first instruction. I do not accept a boot sequence that comes up without LSM enforcement and then attempts to enable it later.
|
||||
* The audit subsystem is configured to be always on ``audit=1`` and to tolerate heavy bursts without dropping events ``audit_backlog_limit=262144``. I treat the audit trail as an evidentiary artifact; truncation because of backlog limits is not acceptable in that model.
|
||||
* The debug surface of the kernel is reduced aggressively. ``debugfs=off`` avoids a traditional footgun that exposes kernel internals in a way that is friendly to attackers and rarely necessary in production.
|
||||
* Memory is hardened on several levels at allocation time and at free time. ``init_on_alloc=1`` and ``init_on_free=1`` provide deterministic zeroing, ``page_poison=1`` fills freed pages with a poison pattern, and ``page_alloc.shuffle=1`` shuffles the allocator so that a process can no longer rely on stable physical patterns. Together these measures raise the cost of use-after-free exploitation and other memory corruption attacks.
|
||||
* The IOMMU is not optional. I force it on ``iommu=force``, disable passthrough ``iommu.passthrough=0`` and require strict behavior ``iommu.strict=``1. Any environment that contains devices capable of DMA must have a correctly configured IOMMU, otherwise the trust model for the CPU and for the memory hierarchy collapses as soon as a hostile device is introduced.
|
||||
* ``kfence.sample_interval=100`` activates KFENCE with a sampling interval that is still usable in production but sensitive enough to catch a meaningful subset of memory safety bugs under real workloads.
|
||||
* Virtualization-specific knobs include ``kvm.nx_huge_pages=force``, to keep huge pages non-executable, and ``l1d_flush=on`` so that context switches flush the L1 data cache where needed.
|
||||
* ``lockdown=integrity`` places the kernel into lockdown mode with an emphasis on integrity. In this project I consider the integrity of the system more critical than the ability to introspect a running kernel from userspace.
|
||||
* Speculative execution and microarchitectural issues are covered by ``mitigations=auto,nosmt``,`` mmio_stale_data=full,force``, and ``retbleed=auto,nosmt``. I combine the automatic mitigation set provided by the kernel with a forced Single Thread mode where it is required because simultaneous multithreading is simply not worth the residual risk profile in many server contexts.
|
||||
* ``nosmt=force`` acts as a guardrail here. It prevents a misconfiguration from quietly re-enabling SMT while the system operator assumes it is disabled.
|
||||
* Fault handling is configured through ``oops=panic`` and ``panic=0``. An oops triggers a panic so that I do not continue to run a kernel in an undefined state. At the same time I instruct the system not to reboot automatically on panic, to preserve the state for post-mortem analysis rather than cutting the ground away under a debugging session.
|
||||
* ``pti=on``, ``rodata=on``, and ``slab_nomerge`` are classical hardening parameters that I still consider essential. Page-table isolation, read-only data segments, and prohibiting slab merging collectively prevent a wide range of exploits, especially under pressure from speculative execution attacks.
|
||||
* To avoid brittle side assumptions, I remove legacy or obsolete interfaces: ``vdso32=0`` and ``vsyscall=none`` shut down the remaining vestiges of 32-bit vDSO and vsyscall support on 64-bit systems. ``ia32_emulation=0`` it again narrows the attack surface by disabling full 32-bit compatibility on 64-bit kernels.
|
||||
* Finally, I do not trust entropy claims either from the bootloader or the CPU itself. I opt out of both with ``random.trust_bootloader=off`` and ``random.trust_cpu=off`` and rely on my own entropy strategy described later.
|
||||
|
||||
All of these parameters are applied in exactly the same way for the live ISO and for the installer environment. That is a
|
||||
deliberate design decision.
|
||||
|
||||
### 2.1.2. CPU Vulnerability Mitigations
|
||||
|
||||
* **Description**: Enables all known kernel-level mitigations (Spectre, Meltdown, MDS, L1TF, etc.).
|
||||
* **Rationale**: Prevents side-channel attacks that exploit speculative execution, which remain a high-risk vector in
|
||||
multi-tenant cloud environments.
|
||||
I build the kernels with the relevant mitigations for Spectre, Meltdown, L1TF, MDS, TAA, Retbleed, and related families activated.
|
||||
The ``mitigations=auto,nosmt`` flag ensures that new mitigations integrated into the mainline kernel become effective as they
|
||||
are added, instead of requiring that I micromanage every single toggle. The residual performance cost is acceptable in the
|
||||
context I am targeting; stale mitigations can be revisited, but missing mitigations will not be.
|
||||
|
||||
### 2.1.3. Kernel Self-Protection
|
||||
|
||||
* **Description**: Activates `CONFIG_DEBUG_RODATA`, `CONFIG_STRICT_MODULE_RWX`, and other self-protections.
|
||||
* **Rationale**: Hardens kernel memory regions against unauthorized writings and enforces stricter module loading policies.
|
||||
I enable the standard set of self-protection options, such as strict module page permissions, read-only data enforcement, and
|
||||
restrictions around kprobes and BPF. The builder is not a kernel configuration tool, but it carries the expectation that the
|
||||
kernels it runs with are compiled according to this hardening profile. I treat deviations from that profile as unsupported.
|
||||
|
||||
### 2.1.4. Local Kernel Hardening
|
||||
|
||||
@@ -443,9 +432,12 @@ predictable script behavior.
|
||||
|
||||
# 4. Prerequisites
|
||||
|
||||
* **Host**: Debian Trixie with `live-build` and ``debootstrap`` packages installed.
|
||||
* **Privileges**: Root or sudo access to execute `ciss_live_builder.sh` and related scripts.
|
||||
* **Network**: Outbound access to Debian repositories and PTB NTPsec pool.
|
||||
To use **``CISS.debian.live.builder``** as intended, the following baseline is expected:<br>
|
||||
|
||||
* The build host runs Debian 13 Trixie, fully updated. Building a Trixie image on an older or newer release is technically possible but explicitly not supported.
|
||||
* The host has the standard live-build stack installed ``live-build``, ``live-boot``, ``live-config``, ``debootstrap`` and the cryptographic tooling required for ``LUKS2``, ``dm-integrity``, ``cryptsetup``, ``gpg``.
|
||||
* Disk space must be sufficient to hold the chroot, the temporary build artifacts, and the final ISO with encrypted root. For comfortable work I assume around 30–40 gigabytes of free space.
|
||||
* The user running the builder has root privileges and understands that the script is capable of creating, mounting, and manipulating block devices.
|
||||
|
||||
# 5. Installation & Usage
|
||||
|
||||
@@ -608,13 +600,22 @@ preview it or run it.
|
||||
|
||||
# 6. Licensing & Compliance
|
||||
|
||||
This repository is fully SPDX-compliant. All source files include appropriate SPDX license identifiers and headers to ensure
|
||||
clear and unambiguous licensing. You can verify compliance by reviewing the top of each file, which follows the SPDX
|
||||
standard for license expressions and metadata.
|
||||
Unless stated otherwise in individual files via SPDX headers, this project is licensed under the European Union Public License (EUPL 1.2).
|
||||
That license is OSI-approved and compatible with internal use in both public sector and private environments. Several files carry
|
||||
dual or multi-license statements, for example **``LicenseRef-CNCL-1.1``** and / or **``LicenseRef-CCLA-1.1``**, where I offer a
|
||||
non-commercial license for community use and a commercial license for professional integration. The SPDX headers in each file
|
||||
are authoritative. If you plan to integrate **``CISS.debian.live.builder``** into a commercial product or a managed service
|
||||
offering, you should treat these license markers as binding and reach out for a proper agreement where required.
|
||||
|
||||
# 7. Disclaimer
|
||||
|
||||
This README is provided "as-is" without any warranty. Review your organization's policies before deploying to production.
|
||||
This repository is designed for well-experienced administrators and security professionals who are comfortable with low-level
|
||||
Linux tooling, cryptography, and automation. It can and will create, format, and encrypt devices. It is entirely possible to
|
||||
destroy data if you use it carelessly. I publish this work in good faith and with a strong focus on correctness and robustness.
|
||||
Nevertheless, there is no warranty of any kind. You are responsible for understanding what you are doing, for validating your
|
||||
own threat model, and for ensuring that this tool fits your regulatory and operational environment. If you treat the builder, and
|
||||
the resulting images with the same discipline with which they were created, you will obtain a hardened, reproducible, and
|
||||
auditable base for serious systems. If you treat them casually, they will not save you from yourself.
|
||||
|
||||
---
|
||||
**[no tracking | no logging | no advertising | no profiling | no bullshit](https://coresecret.eu/)**
|
||||
|
||||
Reference in New Issue
Block a user