CISS Debian Live Builder

Mein CISS Debian Live Builder nimmt eine Stelle ernst, die erstaunlich viele Administratoren, Distributionen und Hersteller wie eine neutrale Vorstufe behandeln. Das Installationsmedium.

Der blinde Fleck sitzt an einer unangenehmen Stelle. Viele reden mit grosser Pose über sichere Systeme, gehärtete Hosts, Zero Trust, Supply Chain, Attestation, Secure Boot, Remote Management und auditierbare Deployments. Kaum jemand behandelt jedoch das Medium, mit dem ein System überhaupt erst in die Welt gesetzt wird, als eigenes sicherheitsrelevantes Objekt. Der offizielle Debian Live Stack ist sauber dokumentiert und genau dafür da, ISO-hybride Live-Abbilder zu bauen. Er trennt klar zwischen Build-Zeit und Boot-Zeit, zwischen Includes, Hooks und Laufzeitverhalten. Das ist gut, robust und bewusst generisch. Es ist aber eben ein Baukasten, keine ausformulierte Sicherheitsarchitektur.1

An diesem Punkt setzte mein Projekt an. In meinem Beitrag „First of its own“ hatte ich die These bereits formuliert: Neu war für mich nie ein isoliertes Feature, neu war die kohärente Verkettung mehrerer Ebenen zu einer durchgehenden Vertrauenskette.2 CISS.debian.live.builder ist im Repo selbst als seit 2024 entwickelter, sicherheitsgetriebener Debian Trixie Live-ISO-Generator beschrieben, gedacht als Referenzimplementierung für gehärtete, image-basierte Debian-Deployments und als Installationsbasis für den künftigen CISS.debian.installer. Der dokumentierte Anspruch lautet nicht „noch ein Live-USB„, sondern ein deterministischer Build-Lauf, der ein verschlüsseltes, integritätsgeschütztes und bereits in der frühen Bootphase verifizierendes Medium erzeugt.3

Wer das Repo nur oberflächlich ansieht, sieht Shell. Wer genauer hinsieht, sieht Disziplin. Das Einstiegsskript erzwingt Bash ab Version 5.1, root, Nicht-Sourcing, eine Ein-Instanz-Sperre via flock, definierte Exit- und Error-Traps, ein modulartiges Nachladen interner Bibliotheken und eine feste tmpfs-Secrets-Struktur unter /dev/shm/cdlb_secrets.4 5 Das ist kein nebensächliches Detail. Gerade in Shell-Projekten entscheidet sich Seriosität oft nicht an einem grossen kryptographischen Wort, sondern an der Frage, ob der Autor die banalen Fehlerquellen ernst nimmt. Viele tun das nicht. Danach darf man sich dann wundern, dass irgendwo ein Passwort in einer Prozessliste, ein privater Schlüssel in einer Debug-Logdatei oder ein Build-Artefakt in einer halbvergessenen temporären Datei landet. Welch verblüffender Zufall.

Die technische Beobachtung ist klar. Das ISO transportiert nicht einfach ein klassisches filesystem.squashfs, das dann irgendwie gemountet wird. Das zentrale Objekt ist eine Containerdatei, in der das SquashFS-Root liegt, und diese Datei ist in einen LUKS2-Verbund mit dm-integrity eingebettet. Die Boot-Chain-Dokumentation beschreibt das explizit als LUKS2 mit aes-xts-plain64, 4096-Byte-Sektoren, argon2id als PBKDF, dm-integrity mit hmac-sha512 und einer zweistufigen Verifikation über gpgv mit gepinntem Fingerprint.6 Die Linux-Kernel-Dokumentation zu dm-integrity hält fest, dass der Target pro Sektor Integritätsinformationen speichert und in Kombination mit dm-crypt authentifizierte Plattenverschlüsselung bereitstellt, bei der Manipulationen nicht als still akzeptierter Datenmüll, sondern als I/O-Fehler zurückfallen.7 Die cryptsetup-Manpage dokumentiert zugleich, dass die Integritätserweiterung für LUKS2 existiert, aber gegenwärtig weiterhin als experimental markiert ist.8

Der wesentliche Aspekt liegt in der Prüfkette. Die CISS-Dokumentation beschreibt zuerst eine frühe ISO-Rand-Prüfung: sha512sum.txt wird per gpgv gegen einen eingebetteten öffentlichen Schlüssel geprüft, anschliessend wird der VALIDSIG-Fingerprint gegen den zur Build-Zeit gepinnten Fingerprint abgeglichen. Danach folgt eine zweite Stufe im bereits geöffneten Root-Dateisystem, bei der eine weitere Hashliste samt Signatur geprüft wird. Fehlt eine gültige Signatur, passt der Fingerprint nicht, fehlt der Schlüssel oder schlägt die Inhaltsprüfung fehl, bricht der Prozess hart ab. Dieser Punkt ist mir wichtiger als manche grössere Schlagworte aus der Sicherheitsfolklore. Viele Systeme verifizieren irgendwo irgendetwas, aber nur beratend. Hier ist die Verifikation als Fehlermodus gebaut, nicht als freundlicher Hinweis. Das ist genau die richtige Haltung für ein Medium, das später zum Ausgangspunkt einer Installation werden soll.

Das gilt ebenso für die Handhabung von Geheimnissen. Das README dokumentiert, dass sensible Daten ausschliesslich in einem tmpfs-Secrets-Verzeichnis leben, dass jeder Symlink in diesem Pfad als harter Fehler gilt, dass xtrace auf kritischen Pfaden deaktiviert wird, dass temporäre Geheimnisse mit shred -fzu entfernt werden, dass GNUPGHOME nach Signaturvorgängen gewischt wird und dass Passphrasen im Initramfs über benannte Pipes statt über Prozessargumente transportiert werden. Die Boot-Chain-Dokumentation ergänzt, dass der initramfs-Dropbear auf Public-Key-Authentisierung beschränkt ist, ohne Passwörter, ohne Agent-Forwarding, ohne X11-Forwarding, ohne SFTP, mit restriktiver KEX- und Cipher-Auswahl. Dropbear selbst ist seit langem genau für kleine, speichersensible Umgebungen interessant und kompatibel mit ~/.ssh/authorized_keys.9 Das ergibt zusammengenommen kein esoterisches Kunststück, sondern etwas sehr Bodenständiges: Headless-Entschlüsselung, ohne Geheimnisse wie Schrauben auf dem Werkstattboden zu verteilen.

An derselben Stelle sitzt ein zweiter Unterschied, der mir wichtiger ist, als viele merken: die Netzwerkhaltung des Mediums. Das Repo dokumentiert ein Profil, in dem systemd-networkd und systemd-resolved ausschliesslich DNS-over-TLS gegen die eigene Resolver-Infrastruktur sprechen, Klartext-DNS nicht als zur Not eben so akzeptieren, DNSSEC hart validieren und mDNS wie LLMNR global abschalten. Das ist nicht bloss Geschmack. RFC 7858 beschreibt DoT ausdrücklich als Schutz gegen Mithören und On-Path-Manipulation zwischen Stub und rekursivem Resolver.10 RFC 4035 beschreibt DNSSEC als Erweiterung, die dem DNS Datenursprungs-Authentizität und Datenintegrität hinzufügt.11 Die resolved.conf-Dokumentation von systemd sagt klipp und klar, dass DNSOverTLS=true alle Anfragen scheitern lässt, wenn der Server kein DoT mit gültigem Zertifikat bietet, und dass DNSOverTLS=opportunistic ebenso wie DNSSEC=allow-downgrade downgrade-anfällig ist.12 Wer also DoT only und DNSSEC fail-closed baut, setzt nicht etwas Exotisches um, sondern entscheidet sich bewusst gegen den bequemen, aber manipulierbaren Kompatibilitätsmodus.13 14

An dieser Stelle lohnt der Blick auf die Landschaft. Debian live-build ist das offizielle Werkzeug, um Debian-basierte Live-Systeme zu erstellen, ISO-Hybride zu bauen und via Includes und Hooks tief anzupassen. Das Werkzeug ist also gerade nicht mein Gegner, sondern meine Grundlage. KIWI NG ist die grosse Referenz aus einer anderen Familie: ein flexibler Image- und Appliance-Builder, deklarativ per XML, mit Unterstützung für klassische ISOs, virtuelle Maschinen, Cloud-Images, Live-Systeme und sogar Debian als unterstützte Plattform.15 KIWI dokumentiert auch LUKS-verschlüsselte Disk-Images, sowohl mit verschlüsseltem /boot als auch mit separater unverschlüsselter Bootpartition.16 Das ist beeindruckend und ausgereift. Was ich dort nicht finde, ist genau die von mir gesuchte Verdichtung: ein Debian-live-build-naher, CI-tauglicher Generator für ein Live-Medium, das Root-Verschlüsselung, sektorielle Integrität, frühe ISO-Verifikation, späte Root-Attestation und initramfs-Remote-Unlock als eng gekoppelte Provisioning-Kette behandelt.

Tails löst ein anderes Problem. Die offizielle Dokumentation sagt es ohne Umschweife: Alles verschwindet beim Herunterfahren automatisch; wer etwas behalten will, legt eine optionale verschlüsselte Persistent Storage auf dem USB-Stick an.17 Das ist eine amnesische, anonymitätszentrierte Sicherheitslogik, nicht meine. NixOS wiederum dokumentiert explizit den Bau von Live-ISOs und versteht das System als Ergebnis eines rein funktionalen Paket- und Modellsystems.18 Fedora Silverblue beschreibt sich selbst als atomare Desktop-Variante, deren Updates als vollständige Images eines funktionierenden Systems geliefert werden.19 Diese Systeme sind technisch interessant und in ihren jeweiligen Domänen stark. Nur sprechen sie nicht dieselbe Sprache wie mein Projekt. Tails priorisiert Spurenvermeidung und Tor, NixOS priorisiert deklarative Systemerzeugung, Silverblue priorisiert atomare Desktop-Updates. Ich priorisiere eine gehärtete, portable, bereits vor der Installation kryptographisch konsistente Provisioning-Umgebung für Debian.

Auch Keylime und APRON zeigen, wie unscharf viele Vergleiche sind. Keylime beschreibt sich selbst als hochskalierbares, TPM-basiertes Framework für Remote-Boot-Attestation und Laufzeitintegritätsüberwachung; der ganze Ansatz steht auf einer hardwarebasierten Root of Trust, gemessenen Bootpfaden, PCR-Werten und IMA-basierten Prüfungen.20 APRON wiederum arbeitet mit signierten Metadaten, Root-Hash und Merkle-Baum über Systemimages, um beschädigte oder veraltete Image-Blöcke progressiv zu renovieren.21 Beides ist ernsthafte Arbeit, beides ist wertvoll, beides trifft aber eine andere Annahmenwelt. Keylime will attestierbare, persistente Knoten mit TPM-Zugriff. APRON will den sicheren Umgang mit Systemimages und deren Renovierung. Mein Live-Builder will auf heterogener Hardware ein portables Medium bereitstellen, das schon vor der eigentlichen Installation eine konsistente Sicherheitslage erzwingt.

Auf Basis der öffentlich zugänglichen Primärdokumentation von Debian Live, KIWI NG, Tails, NixOS, Keylime und APRON ist mir bislang kein öffentlich dokumentiertes Projekt begegnet, das auf Debian-live-build-Nähe setzt und zugleich in einem zusammenhängenden Workflow ein Live-ISO mit verschlüsselter und integritätsgeschützter Root, zweistufiger GPG-verankerter Verifikation, initramfs-Remote-Entschlüsselung und restriktiver DoT-only/DNSSEC-fail-closed-Netzpolitik als Installations- und Provisioning-Basis bereitstellt. Das ist eine belastbare, begrenzte Aussage.

Gerade weil ich dieses Projekt ernst nehme, benenne ich auch die aktuell offenen Punkte.

  1. Die cryptsetup-Dokumentation markiert die Integritätserweiterung für LUKS2 weiterhin als experimental. Das heisst nicht, dass der Ansatz wertlos wäre. Es heisst, dass jeder, der dieses Design produktiv übernimmt, Versionsstände, Kernelverhalten und Recovery-Szenarien besonders sauber testen muss.
  2. Meine gegenwärtige Vertrauenskette ist bewusst portabel und läuft laut CISS-Dokumentation bereits ohne Microsoft-db, verankert über gepinnte Fingerprints, Signaturen und die doppelte Verifikation am ISO-Rand und im Root-FS. Das ist elegant, aber nicht dasselbe wie eine hardwaregebundene Root of Trust mit TPM, PCR-Messungen und Measured Boot, wie Keylime sie voraussetzt.
  3. Wer den UEFI-Einstieg zusätzlich absichern will, landet zwangsläufig bei Secure Boot, shim, GRUB und signierten Bootkomponenten. Das shim-Projekt beschreibt sich selbst als triviale erste UEFI-Stufe, die den nächsten Loader über eingebaute Zertifikate validieren und starten kann.22

Der konsequente nächste Schritt für mein Projekt ist deshalb nicht, die bestehende Kette zu ersetzen, sondern sie nach vorn zu verlängern: Firmware prüft shim, shim prüft GRUB, GRUB lädt Kernel und Initramfs, und danach greift meine bestehende zweistufige Verifikation. Dann beginnt die Härte nicht erst im Live-System, sondern schon vor dessen erstem Instruktionssprung.

Noch ein Punkt ist strategisch entscheidend. Das Repo dokumentiert an sehr prominenter Stelle, dass der klassische Debian Installer stets seinen eigenen Kernel und seine eigene Initramfs bootet, unabhängig davon, ob er aus GRUB, aus einer laufenden Live-Sitzung oder über Hilfspakete gestartet wird. In diesem Moment verschwindet die gehärtete Live-Umgebung aus dem Speicher; übrig bleiben die Eigenschaften von d-i, nicht mehr die des Live-Builders. Das ist kein Debian-Fehler, sondern eine Eigenschaft des Modells. Für mich folgt daraus eine schlichte Konsequenz: Wer eine durchgehende Vertrauenskette will, darf die Installationsphase nicht als neutralen Tunnel betrachten. Genau deshalb gehört der CISS.debian.installer logisch zu diesem Projekt und ist nicht bloss ein optionales Anhängsel.

Am Ende bleibt für mich ein sehr einfacher Satz. Sicherheit beginnt nicht erst auf dem installierten Host. Sie beginnt bei dem Medium, dem ich den ersten Zugriff auf Hardware, Speicher, Netz und Schlüsselmaterial überhaupt gestatte. Genau dort setzt CISS.debian.live.builder an. Und genau deshalb ist dieses Projekt für mich nicht bloss ein weiteres Repo, sondern eine technische Positionsbestimmung.

In eigener Sache

Unabhängige Sicherheitsentwicklung dieser Art frisst Zeit, Konzentration, Infrastruktur und Geld. Wer möchte, dass solche Arbeit nicht zwischen politischem Lärm, institutioneller Heuchelei und ökonomischem Druck zerrieben wird, kann meine Arbeit direkt unterstützen. Jede konkrete Hilfe schafft mir Raum, diese Architektur weiter auszubauen, die Secure-Boot-Integration sauber nachzuziehen, den CISS.debian.installer an dieselbe Vertrauenskette zu binden und die Dokumentation so weit zu verdichten, dass daraus nicht nur ein persönliches Werkzeug, sondern eine belastbare Referenz für eine kleine, aber sehr reale Klasse gehärteter Debian-Provisioning-Systeme wird.

Spenden

Mille fois an alle Spender.

Quellen

  1. Debian Live Project, Debian Live Manual, Bookworm-Ausgabe, insb. Abschn. 1, 4.3, 7.1, 9.1 und 9.2. https://live-team.pages.debian.net/live-manual/html/live-manual.en.html ↩︎
  2. Marc Weidner, „First of its own“, CenturionBlog, 6. Dezember 2025. https://coresecret.eu/2025/12/06/first-of-its-own/ ↩︎
  3. Marc S. Weidner, CISS.debian.live.builder, Repository-README und Projektübersicht, Stand 6. Dezember 2025, insb. Abschn. 1.3, 1.5, 2.1, 2.3 sowie Beschreibung der Secret-Handling- und Netzwerk-Policy. https://git.coresecret.dev/msw/CISS.debian.live.builder ↩︎
  4. Ebd. ↩︎
  5. Marc S. Weidner, ciss_live_builder.sh, Top-Level-Skript, Stand 27. November 2025, insb. Preliminary Checks, Trap-Handling, Locking und tmpfs-Secrets-Pfad. https://git.coresecret.dev/msw/CISS.debian.live.builder/src/branch/master/ciss_live_builder.sh ↩︎
  6. Marc S. Weidner, „CISS.debian.live.builder – Boot & Trust Chain (Technical Documentation)“, Stand 12. November 2025, insb. Overview, Primitives & Parameters, Failure Policy und Integration Points. https://git.coresecret.dev/msw/CISS.debian.live.builder/src/branch/master/docs/MAN_CISS_ISO_BOOT_CHAIN.md ↩︎
  7. Linux Kernel Documentation, „dm-integrity“, Abschn. Einleitung und Zusammenspiel mit dm-crypt. https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html ↩︎
  8. cryptsetup-luksFormat(8), Linux man-pages, Abschn. –integrity und –integrity-key-size. https://man7.org/linux/man-pages/man8/cryptsetup-luksFormat.8.html ↩︎
  9. Matt Johnston, „Dropbear SSH“, Projektseite, Feature-Übersicht zu Footprint und Public-Key-Authentisierung. https://matt.ucc.asn.au/dropbear/dropbear.html ↩︎
  10. Hu, Zhu, Heidemann, Mankin, Wessels, Hoffman, RFC 7858, „Specification for DNS over Transport Layer Security (TLS)“, IETF, Mai 2016, Abstract. https://datatracker.ietf.org/doc/html/rfc7858 ↩︎
  11. Arends et al., RFC 4035, „Protocol Modifications for the DNS Security Extensions“, IETF, März 2005, Abstract und Einleitung. https://www.rfc-editor.org/rfc/rfc4035.html ↩︎
  12. resolved.conf(5), Linux man-pages/Systemd, Abschn. DNSSEC= und DNSOverTLS=. https://man7.org/linux/man-pages/man5/resolved.conf.5.html ↩︎
  13. Siehe Fn. 3. ↩︎
  14. Arends et al., RFC 4035, „Protocol Modifications for the DNS Security Extensions“, IETF, März 2005, Abstract und Einleitung. https://www.rfc-editor.org/rfc/rfc4035.html ↩︎
  15. KIWI NG Documentation 10.3.0, „Welcome to KIWI NG“, Abschn. Why KIWI? und unterstützte Plattformen. https://osinside.github.io/kiwi/ ↩︎
  16. KIWI NG Documentation 10.3.0, „Image Description for an Encrypted Disk“, Abschn. zu teil- und vollverschlüsselten Images mit LUKS. https://osinside.github.io/kiwi/working_with_images/disk_setup_for_luks.html ↩︎
  17. Tails Documentation, „Persistent Storage“, Abschn. Einleitung und Verschlüsselungsmodell. https://tails.net/doc/persistent_storage/index.en.html ↩︎
  18. NixOS Manual, stabile Ausgabe 25.11, Preface und Abschn. „Building a NixOS (Live) ISO“. https://nixos.org/manual/nixos/stable/ ↩︎
  19. Fedora Project, „Fedora Silverblue“ beziehungsweise „Fedora Atomic Desktops“, offizielle Projektbeschreibung zur atomaren Desktop-Variante und image-basierten Updates. https://silverblue.fedoraproject.org/ ↩︎
  20. Keylime, „A Hitchhikers Guide to Remote Attestation“, Abschn. zu Secure Boot, Measured Boot, TPM und Keylime als TPM-basiertem Attestationsframework. https://keylime.dev/blog/2024/02/07/remote-attestation-blog-part1.html ↩︎
  21. Lee et al., „Authenticated and Progressive System Image Renovation“, USENIX ATC 2023, Abschn. 4.1 und Systemmodell mit Root-Hash, Signatur und Merkle-Baum. https://www.usenix.org/system/files/atc23-lee.pdf ↩︎
  22. rhboot/shim, Projekt-README, Beschreibung von shim als erster UEFI-Bootloader-Stufe und Validierung nachgelagerter Komponenten. https://github.com/rhboot/shim ↩︎

Categories: Digitalisierung, IT, IT-Security, Linux
Tags: , , , ,

You may also like

Search: