From 0169f464e9c8f34b63b35a783867bb28551cfc26d3353fa803419b793114ed9f Mon Sep 17 00:00:00 2001 From: "Marc S. Weidner" Date: Thu, 4 Dec 2025 19:59:11 +0100 Subject: [PATCH] V8.13.536.2025.12.04 Signed-off-by: Marc S. Weidner --- README.md | 235 +++++++++++++++++++++++++++--------------------------- 1 file changed, 118 insertions(+), 117 deletions(-) diff --git a/README.md b/README.md index 071de5f..649fd41 100644 --- a/README.md +++ b/README.md @@ -32,6 +32,9 @@ include_toc: true **CISS.debian.live.builder — First of its own.**
**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.
+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)**
-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.
+In compact form, my expectations for the system are:
-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)`.
+* 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.
+These combinations give me a provisioning chain that is auditable, reproducible, and robust against both casual and targeted tampering.
-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 :`. 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: ![CISS.debian.live.builder](/docs/screenshots/CISS.debian.live.builder_preview.jpeg) -## 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.**
-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:
+ +* 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/)**