Von Debian-Installationen

Ich setze seit Jahren auf Debian. Nicht aus Romantik, sondern aus schlichter Vernunft: stabile Release-Zyklen, solide Paketpflege, enorme Verbreitung, gut verstehbares Ökosystem.

Aber: Was nach der Installation auf der Platte landet, ist sicherheitstechnisch ein schlechter Witz. Ein frisch installiertes Debian ist – freundlich formuliert – offen wie ein Scheunentor.

Gleichzeitig habe ich eine sehr konkrete, sehr unromantische Realität:

• Heterogene Landschaft aus Bare-Metal-Hosts und KVM/QEMU-VMs
• Keine gigantische Infrastruktur, die ein komplettes Cloud-Init- oder Ansible-Universum rechtfertigt
• Hohe Anforderungen an Sicherheit, Kryptographie, Zero-Trust-Fähigkeit
• Sehr spezifische Vorstellungen von Partitionsschema, Verschlüsselung, btrfs-Layout und Boot-Kette

Nach mehreren Runden mit Preseed, angepassten Skrivten und Debian-Installer-Interna war irgendwann der Punkt erreicht, an dem klar war:

Entweder ich baue mir meinen eigenen, reproduzierbaren Live-Builder plus einen komplett neuen Debian-Installer – oder ich verbringe den Rest meines Lebens mit Kämpfen gegen den tradierten Debian-Installationsstack.

Ich habe mich für Variante eins entschieden.

Das Ergebnis heisst:

• CISS.debian.live.builder
• CISS.debian.installer

Meine Umgebung besteht aus einer Mischung aus:

• klassischen Root-Servern / Bare-Metal
• KVM- und QEMU-Umgebungen bei verschiedenen Providern

Ich brauche also ein Werkzeug, das:

• sowohl im Rechenzentrum als auch in der Cloud identische Zustände herstellen kann
• unabhängig vom jeweiligen Hypervisor funktioniert
• alle sicherheitskritischen Entscheidungen bereits im Build und im sehr frühen Boot-Stadium erzwingt

Debian ist dabei bewusst gewählt:

• Keine Rolling Releases, also keine Überraschungen im Wochentakt
• Hohe Maturität, sehr gute Langzeitpflege

Aber: Härtung „ab Werk“ existiert praktisch nicht.

Wer sich ernsthaft mit SSH-Härtung, Kernel-Parametern, Filesystem-Mount-Policies, Auditd, Logging, Secure Boot und Kryptographie beschäftigt hat, weiss:

Das Standard-Debian-ISO ist ein Convenience-Produkt, kein sicherer Startpunkt.

Für grosse Umgebungen sind Cloud-Init, MAAS, Ansible & Co. sinnvoll. Meine Realität sieht anders aus:

• Anzahl der Maschinen ist begrenzt, Ansible kommt erst im Step nach Installation ins Spiel
• Ich will Maschinen dennoch deterministisch, reproduzierbar und maximal gehärtet installieren
• Ich will kein weiteres Grossprojekt nur zur Orchestrierung des Installers aufbauen

Damit ist klar:

Der Installer selbst muss so mächtig sein, dass er ohne nachgelagerte „Magie“ ein komplett gehärtetes System ausrollen kann.

Der eigentliche Kipppunkt war im November 2024.

Ich habe damals einen vollen Monat damit verbracht, die Preseed-Konfiguration und den Parser so zu verbiegen, dass das gewünschte CISS-Partitionsschema möglich wird:

• Vollverschlüsselung mit LUKS2
• getrennte Partitionen
• btrfs mit sauber getrennten Subvolumes für /.snapshots
• ohne „LVM for all“-Zwang
• flexible Anzahl Devices und Partitionen

Das Problem:

• Die komplette Debian-Installer-Logik basiert auf alten Annahmen und ist nur begrenzt anpassbar
• Die Partitionierungsmodule laufen in alte Default-Muster, die nicht zu einem modernen FDE-/btrfs-Design passen
• Preseed hilft nur, solange man brav innerhalb der vorgesehenen Schienen bleibt

Nach unzähligen Anpassungen, Tests und Fehlversuchen war die Erkenntnis simpel:

Der Debian-Installer ist nicht dafür gebaut, hochgradig flexible, moderne Crypto- und btrfs-Setups ohne LVM-Zwang abzubilden.

Also: Neustart. Eigenes Framework.

Der CISS.debian.live.builder setzt genau dort an, wo der Standard aufhört: beim Live-System, das als hochvertrauenswürdiges Pre-Installations-Environment dient.

Ziel:

Ein Live-ISO, das von der ersten CPU-Instruktion, die mein ISO betrifft, bis zum Start des Installers eine durchgehende, kryptographisch abgesicherte Vertrauenskette etabliert, gerade in einer Zero-Trust-Remote-Situation.

Kernprinzipien:

1. Vertrauensanker am ISO-Rand, nicht erst „irgendwo im System“
2. Zwei-stufige Verifikationskette:
   • Frühe Prüfung des ISO-Contents, bevor überhaupt etwas Wesentliches gemountet wird
   • Späte Attestation des entschlüsselten Root-Filesystems
3. Speicher- und Blocklayer-Härtung
   • LUKS2 mit AES-XTS-512
   • dm-integrity mit HMAC-SHA-512 pro Block
4. Remote-unlock über gehärtetes Dropbear in der initramfs, ohne die üblichen SSH-Angriffsflächen
5. Fail-closed statt „wird schon gutgegangen sein“

Die technische Dokumentation zur Boot- und Vertrauenskette habe ich im Repository kurz mittels Diagrammen skizziert:

https://git.coresecret.dev/msw/CISS.debian.live.builder/src/branch/master/docs/MAN_CISS_ISO_BOOT_CHAIN.md

Boot- und Vertrauenskette im Überblick

1. Secure Boot, wenn verfügbar

Wenn die Hardware es zulässt, arbeitet die Kette so:

1. UEFI Secure Boot lädt und prüft shim
2. shim prüft und lädt GRUB
3. GRUB lädt Kernel und initramfs des CISS.debian.live.builder-Live-Systems

Damit beginnt meine Kontrolle bereits in der Secure-Boot-Kette.

Falls kein Secure Boot verfügbar ist, verschiebt sich der Vertrauensanker konsequent nach vorne an den ISO-Rand (siehe unten), bleibt aber kryptographisch sauber.

2. LUKS-verschlüsseltes SquashFS im Container

Der eigentliche Live-Rootfs liegt nicht unverschlüsselt als filesystem.squashfs herum, sondern:

1. ISO-Filesystem → Containerdatei (z. B. live/ciss_rootfs.crypt)
2. dm-integrity-Schicht mit HMAC-SHA-512
3. LUKS2 (aes-xts-plain64, 512 Bit Key, 4 KiB Sektoren, argon2id)
4. Darin: SquashFS mit dem eigentlichen Live-Rootfs

Damit habe ich funktional ein AEAD-artiges Verhalten auf Blockebene:
Manipulationen führen nicht zu „merkwürdigem Verhalten“, sondern zu klaren, harten I/O-Fehlern.

3. Frühe ISO-Edge-Verifikation

Noch bevor der LUKS-Container geöffnet wird, passiert im initramfs:

• Verifikation einer Signaturdatei (z. B. sha512sum.txt.sig) mit gpgv
• Verifikation der dazugehörigen Hashliste
• Fingerprint-Pinning: Nur der exakt erwartete GPG-Fingerprint wird akzeptiert

Damit ist sichergestellt:

Wenn das ISO oder seine Kernartefakte manipuliert wurden, bootet die Umgebung gar nicht erst in einen „halb vertrauenswürdigen“ Zustand, sie bleibt korrekt stehen.

4. Späte Rootfs-Attestation

Nachdem der LUKS-Container geöffnet und das SquashFS gemountet wurde, folgt die zweite Stufe:

• Attestation-Dateien im Rootfs werden gegen signierte Hashlisten geprüft
• Erneute FPR-Prüfung gegen den eingebetteten Keyring
• Überprüfung der tatsächlichen dmsetup-Topologie (Crypt und Integrity, wie erwartet)

Damit wird nicht nur der ISO-Rand, sondern auch der innere Zustand der Live-Rootfs-Schicht kryptographisch abgesichert.

5. Gehärtetes Dropbear für Remote-Unlock

Remote-Installationen sind inhärent Zero-Trust:

• Ich kontrolliere den Hypervisor oft nicht
• Ich traue dem Netzwerk erst recht nicht

Deshalb läuft in der initramfs-Phase ein gehärteter Dropbear, der:

• ausschliesslich Public-Key-Authentifikation zulässt
• nur moderne KEX-/Cipher-Kombinationen verwendet
• kein Agent-, X11- oder TCP-Forwarding zulässt
• auf einem dedizierten Port lauscht
• bei Fehlern sauber und hart terminiert

Damit kann ich:

• Live-ISO remote booten
• mich sicher in der initramfs-Phase einloggen
• LUKS-Container öffnen
• Installation steuern

ohne den üblichen SSH-Ballast und ohne, dass das System jemals „unklar signiert“ durchstartet.

Warum ein eigener Installer?

Der zweite Teil des Projekts ist der CISS.debian.installer, der auf dieser Live-Umgebung aufbaut.

Die Anforderungen sind bewusst ehrgeizig:

1. Maximale Flexibilität bei der Partitionierung
   • Beliebige Anzahl Devices und Partitionen
   • Frei definierbare Rollen (z. B. Root, Log, Audit, Snapshots, Scratch)
   • Kein erzwungenes LVM, insbesondere nicht als Voraussetzung für FDE
   • Native Unterstützung für btrfs-Subvolumes in der von mir bevorzugten Struktur
2. Deklarative Steuerung der Installation
   • Konfiguration per YAML-Dateien
   • Klar definierte Schema-Validierung
   • Reproduzierbare Ergebnisse quer über verschiedene Maschinen und Provider hinweg
3. Sicherheit als Default, nicht als nachträglicher Hack
   • FDE als Normalfall, nicht als Option
   • Separierung kritischer Verzeichnisse (/var/log, /var/log/audit, /var/tmp, /.snapshots)
   • Sichere Mount-Optionen (noexec, nodev, nosuid, zstd-Kompression, discard-Strategien etc.)
   • Bereits im Installer verankerte Härtung von Kernel-Parametern, SSH, Logging, Auditing
4. Zero-Trust-tauglicher Installationspfad
   • Die gesamte Chain von ISO-Build über Boot bis Installer bleibt kryptographisch nachvollziehbar
   • Integrity- und Authenticity-Checks greifen, bevor auch nur ein Byte „Produktion“ geschrieben wird
5. Keine Calamares-Abhängigkeit
   Calamares ist bewusst kein Teil des Setups.
   Ich habe keine Lust, einen sicherheitskritischen Installer zu verwenden, dessen Entwicklungskultur sichtbare ideologische Prioritäten über fachliche Stringenz stellt.

Praktische Auswirkungen: Von der ersten Sekunde an gehärtet

Die Live-Umgebung, die aus dem CISS.debian.live.builder herausfällt, ist kein „mal schnell zusammengeklicktes“ ISO, sondern:

• Lynis-Audit um die 96 % für das Live-System
• SSH-Konfiguration, die bei spezialisierten Audits stabil im 100 %-Bereich liegt
• Verschärfte Kernel-Parameter, restriktive iptables/nftables-Policies und Logging
• Möglichst minimaler Dienstumfang, minimale Angriffsoberfläche

Der entscheidende Punkt:

Diese Härtung beginnt nicht erst nach der Installation, sondern mit dem Boot der Live-Umgebung selbst.

Das unterscheidet den CISS.debian.live.builder fundamental von einem normalen Debian-Installer-ISO.

Warum sich der Aufwand lohnt

Ja, es wäre bequemer gewesen, sich mit den Limitierungen des Debian-Installers abzufinden, drei Lagen Ansible drumherum zu wickeln und das Ganze als „good enough“ abzuhaken.

Ich habe mich bewusst dagegen entschieden, aus drei Gründen:

1. Sicherheit muss deterministisch sein
   Ich will eine Kette von Artefakten (ISO, Signaturen, Hashlisten, Attestationsdateien) haben, die ich jederzeit kryptographisch nachprüfen kann.
2. Flexible Kryptographie- und Partitionsarchitektur ist kein Luxus
   Btrfs-Layouts, FDE-Designs und Bootketten sind keine Nebensächlichkeiten, sondern die tragenden Pfeiler der Systemarchitektur. Wer hier Kompromisse eingeht, baut mittelfristig auf Sand.
3. Zero-Trust heisst: Ich traue dem Hypervisor nicht
   Ich muss davon ausgehen, dass Cloud-Provider, Zwischenknoten und Dritte nicht meine Freunde sind.
   Deshalb ist es nicht verhandelbar, dass der Installer selbst in einem maximal gehärteten, attestierten Umfeld läuft.

Fazit

Der CISS.debian.live.builder ist nicht „noch ein Live-ISO-Generator“, sondern:

• eine bewusst gehärtete Kombination aus Build-Framework, Kryptographie-Stack, Boot- und Vertrauenskette,
• die eine vollständig abgesicherte Live-Umgebung bereitstellt,
• welche wiederum Grundlage für einen flexiblen, deklarativen, sicherheitszentrierten Debian-Installer bildet.

Das Ziel ist simpel formuliert, aber technisch anspruchsvoll:

Neue Maschinen, ob Bare-Metal oder VM, sollen sich aus einem einzigen, wohldefinierten ISO heraus reproduzierbar, kryptographisch attestierbar und von der ersten Sekunde an gehärtet aufsetzen lassen.

Alles andere ist für meine Zwecke schlicht keine Option.