First of its own

Ein gewisser Punkt in einem Langzeitprojekt markiert den Moment, an dem aus einer fixen Idee ein eigenständiges technisches Objekt wird. Kein Skriptfragment mehr, kein Experiment auf einem Testserver, sondern ein Werkzeug mit Kontur, Architektur und Anspruch. Genau da befindet sich mein CISS.debian.live.builder1 inzwischen.

Was als pragmatischer Wrapper um Debian live-build2 3 begonnen hat, ist zu einem hoch gehärteten, kryptographisch konsistenten Live ISO Generator geworden, der sich nicht mehr sinnvoll in eine der bekannten Schubladen einordnen lässt.

Ich habe in den letzten ca. 20 Monaten systematisch versucht herauszufinden, ob es draussen bereits etwas Vergleichbares gibt. Nicht einfach einen weiteren Live-USB Baukasten, nicht das x-te remasterte Desktop ISO, sondern einen integrierten Builder, der in einem deterministischen Lauf ein voll verschlüsseltes, dm-integrity4 geschütztes Live-Medium erzeugt, mit LUKS2-Container5 auf dm integrity6, SquashFS7 Root, gehärtetem Kernel und sysctl8 Profil, dropbear9 im Initramfs für Remote Unlock, eigenem Attestationspfad und einem bewusst fail-closed konfigurierten DNS-Stack inklusive DoT10 only und DNSSEC11 hart auf SERVFAIL12. Nach dieser Runde durch den aktuellen Werkzeug und Distro Zoo stand fest: es gibt viel, aber genau dieses Ding existiert schlicht nicht.

Wer heute mit Live-Systemen und image-based Konzepten arbeitet, landet fast automatisch bei einer Handvoll grosser Referenzen. KIWI NG13 taucht sehr schnell auf, sobald es um generische Image Builder geht, die virtuelle Disks, OEM-Images und Live-Medien erzeugen können. Die Dokumentation beschreibt die Unterstützung für vollständig oder teilweise verschlüsselte virtuelle Disk Images mit LUKS; sogar Szenarien, in denen auch /boot innerhalb einer voll verschlüsselten Partition liegt und der Bootloader bereits die Passphrase abfragt, sind dort explizit vorgesehen.14 KIWI NG kann Live-CDs und Live-USB Medien bauen, die sich als Appliance oder als Basis für Cloud Instanzen eignen. Die eigentliche Security Architektur bleibt dabei allerdings relativ generisch, vor allem mit Blick auf initramfs Kette, SSH Härtung oder Remote Entsperrung.

Auf der anderen Seite der Landschaft steht Tails.15 16 Dieses System ist ein Paradebeispiel für eine amnesische, auf Anonymität fokussierte Live-Distribution auf Debian17 Basis, deren gesamter Entwurf darauf ausgerichtet ist, möglichst wenige Spuren zu hinterlassen und jeglichen Traffic durch Tor18 zu leiten. Tails ist sehr konsequent im Umgang mit Persistenz, Browser Hardening und Netzwerkpfad, aber das Speichermodell basiert auf einem klassischen Live-Ansatz mit Overlay19, nicht auf einem voll verschlüsselten SquashFS20 im LUKS-Container mit dm-integrity darunter. Die Designziele überlappen sich in Teilen, sind aber an entscheidenden Stellen orthogonal.

Parallel dazu hat sich eine ganze Familie von sogenannten immutable21 oder image-based22 Linux Systemen entwickelt. Silverblue23 24, Bazzite25 26, Ubuntu Core27, verschiedenste bootc28-basierte Varianten und natürlich NixOS29 30 mit seinen image-based Appliance Profilen stehen für einen Ansatz, bei dem das Root Dateisystem als read-only-Image verwaltet und Aktualisierung als Austausch oder Fortschreiben von Images verstanden wird. Diese Systeme lösen ein anderes Problem, nämlich Reproduzierbarkeit und Update Robustheit im Langzeitbetrieb. Sie liefern ausgezeichnete Ideen, etwa die saubere Trennung von System und Nutzerdaten oder streng versionierte Root-Images. Sie stellen aber keinen konkreten Live-ISO Generator für Debian zur Verfügung, der in einer CI Pipeline in einem Lauf ein verschlüsseltes Live-Medium (für meinen Autoinstallations Workflow) mit der oben skizzierten Kryptographie Architektur baut.

Die Security Szene im engeren Sinn zeigt ebenfalls charakteristische Figuren. Klassische Penetrationstest Distros konzentrieren sich auf Tooldichte und Netzwerkfreigiebigkeit, nicht auf fail-closed by design. Andere Projekte stellen Remote Attestation in den Vordergrund, etwa Keylime31, das als skalierbare TPM32 basierte Remote-Boot-Attestation33 und Laufzeitsintegritätslösung positioniert ist. Keylime verankert Vertrauen im TPM 2.0, verarbeitet UEFI Event Logs, IMA-Messungen34 35 und PCR-Werte36 und kann so Boot Pfad und Dateisystemintegrität überwachen. Aus dieser Richtung kommen spannende Ideen für attestierte Systeme, doch die Erwartungshaltung ist eine ganz andere: persistent installierte Knoten mit TPM-Zugriff, nicht ein Live ISO, das auf beliebiger Hardware läuft und trotzdem so weit wie möglich fail-closed bleiben soll.

Ein Forschungsprojekt wie APRON37 wiederum zeigt, wie man bei image-based Systemen mit authentisierter Buildaktualisierung arbeiten kann, indem ein Root Hash über das gesamte Image gepflegt wird, anstatt für viele kritische Dateien eigene Hashketten zu verwalten. Das geht klar in Richtung verifizierter Images und supply chain Sicherheit, dockt aber eher an Plattformen an, die ohnehin auf Buildverwaltung ausgelegt sind. Für einen Live-Builder, der auf dem offiziellen Debian live-build Stack aufsetzt, bietet APRON mehr Inspiration als fertiges Werkzeug.

All diese Linien füren zu einem ernüchternden, aber auch befreienden Befund. Die Bausteine existieren: LUKS2 verschlüsselte Disk Images, image-based Wurzelsysteme, TPM-basierte Attestation, gehärtete Live Systeme, amnesische Umgebungen. Was fehlte, war ein bewusst eng gezogener, sicherheitsfokussierter Builder für Debian, der diese Elemente gezielt kombiniert und nicht versucht, alle Anwendungsfälle von Desktop bis Cloud Appliance gleichzeitig abzudecken.

Warum ein eigener Live Builder

Der ursprüngliche Anlass für den CISS.debian.live.builder war so schlicht wie unbefriedigend. Ich brauchte ein Live-System als Installationsbasis, als Single Source of Truth, dem ich selbst noch vertrauen kann, nachdem ich sehe, welche Defaults viele Distributionen inzwischen mit sich herumtragen. Klartext DNS ins Internet, opportunistische Sicherheit ohne klar definierte Fehlermodi, SSH Konfigurationen, die eher an eine offene Veranda als an eine durchbruch- und / oder durchschusshemmende Tür erinnern, Kernel Parameter, die grosse Teile der verfügbaren Härtung schlicht ungenutzt lassen. Dazu die skizzierte Notwendigkeit, ein Live-Medium als vollwertige, skriptgesteuerte Installationsbasis für gehärtete Systeme zu benutzen.

Debian live-build ist als Grundlage ein robustes Werkzeug. Es lässt sich in CI Pipelines38 einhängen, reproduzierbare Builds sind erreichbar, das Zusammenspiel mit debootstrap39 und den offiziellen Paketquellen ist sauber. Was fehlt, ist alles, was über die Standarderwartung an ein generisches Live-ISO hinausgeht. Die Default Strukturen rund um filesystem.squashfs auf einem ISO 9660 Medium, ein paar Overlay Schichten und etwas kosmetische Anpassungen reichen schlicht nicht mehr aus, sobald man Anforderungskataloge aus sicherheitskritischen Umgebungen ernst nimmt.

Aus dieser Lücke heraus ist der CISS.debian.live.builder gewachsen. Schritt für Schritt, erst als Shell Wrapper über live build, dann als immer weiter ausgebauter Baukasten, der Module für Kernel Härtung, sysctl Profilierung, cryptsetup Layout, initramfs Anpassung, SSH Härtung und DNS Politik einsammelt. Inzwischen bin ich an einem Punkt, an dem dieses Gebilde eine Eigendynamik entwickelt hat. Es ist nicht mehr nur eine persönliche Toolchain, sondern ein konsistenter, dokumentierter Builder, der als Referenz für eine ganz bestimmte Klasse von Live-Medien dienen kann.

Architekturskizze

Im Kern baut der CISS.debian.live.builder ein ISO, das ein einziges wesentliches Objekt transportiert: eine LUKS2-Containerdatei, die ihrerseits auf einem dm-integrity Ziel liegt und innerhalb dieses Verbundes ein SquashFS-Root Dateisystem enthält. Das ISO ist damit nicht einfach nur ein Datenträger, auf dem bei Bedarf irgendetwas verschlüsselt wird. Das Medium ist selbst Träger einer bereits verschlüsselten und integritätsgeschützten Wurzel.

Die Build Pipeline läuft in mehreren klar getrennten Phasen. Zuerst entsteht in einem chroot Kontext ein klassisches Debian Root Dateisystem mit allen notwendigen Paketen, Kernel, Init System, Tools und Konfiguration. Dieses Root wird in ein SquashFS gepackt. An dieser Stelle könnte man aufhören und wäre auf dem Niveau der meisten Live Medien. Der Builder geht aber weiter, indem er dieses SquashFS nicht direkt als filesystem.squashfs auf das ISO schreibt, sondern in einen LUKS2 Container kapselt, dessen unterliegendes Block Device durch dm-integrity geschützt ist. Der Container landet dann als Datei auf dem ISO.

dm-integrity sorgt in dieser Konstellation für eindeutige Integritätsinformation pro Sektor und schliesst damit ein ganzes Spektrum subtiler Manipulationsangriffe aus, die sich gegen reine Verschlüsselung ohne Integritätsmetadaten richten würden. LUKS2 legt darüber seine Metadaten und stellt starke Kryptographie mit Argon2id40 basierter Schlüsselableitung und AES XTS41 bereit. Das SquashFS im Inneren profitiert von der read-only Semantik und eignet sich hervorragend als Wurzel eines Live Systems, das keine Schreibzugriffe auf den eigentlichen Systembestand zulässt.

Beim Booten betritt das angepasste initramfs die Bühne. An Stelle eines simplen Mounts von filesystem.squashfs greift eine Kette aus eigenen Skripten, die das LUKS2 Volume öffnet, dm-integrity initialisiert und das SquashFS als Root Dateisystem einhängt. Ein dropbear Dienst im Initramfs erlaubt es, diese Entsperrung auch remote vorzunehmen, ohne jemals Passphrasen in klarer Form auf einem lokalen Bildschirm, in Kern Dmesg Ausgaben oder auf einer Commandline zu sehen. Der Transport erfolgt über eine benannte Pipe im Initramfs, nicht über Argumente zu cryptsetup, was die Sichtbarkeit in Prozesslisten weiter reduziert.

Parallel dazu hängt der Builder eine modifizierte Variante von 0030-verify-checksums in die initramfs Kette ein, um ISO-Edge-Verifikation und Root-Attestation zusammenzuführen. GPG Signaturen und Hashwerte werden so genutzt, dass Manipulationen am Medium oder an der Wurzel bei jedem Boot offengelegt werden. Diese Attestationslogik bleibt bewusst ohne TPM oder hardwaregebundene Vertrauensanker, um das Live-System auf beliebiger Hardware nutzbar zu halten, ohne den Anspruch auf Integrität zu opfern.

Netzwerk und DNS: DoT only, DNSSEC fail closed

Ein Live System, das in sicherheitskritischen Kontexten eingesetzt wird, darf sich im Netz nicht wie ein auffällig unauffälliger Standarddesktop verhalten. Es war von Anfang an klar, dass ich den Resolver Stack nicht dem Zufall überlassen werde. In der Variante, in der das ISO mit einer Centurion Profil Option gebaut wird, sind systemd networkd und systemd resolved so vorkonfiguriert, dass ausschliesslich DNS over TLS gegen die eigene CenturionDNS42 Infrastruktur verwendet wird. Der Versuch, auf Klartext DNS zurückzufallen, wird nicht als freundliche Degradation, sondern als Fehler gewertet.

DNSSEC Validierung ist in diesem Setup fail-closed. Fehlerhaft signierte oder gebrochene Zonen liefern SERVFAIL und werden nicht hinter dem Rücken des Nutzers als vermeintlich harmlose Unsicherheit akzeptiert. Lokale Multicast Mechanismen wie mDNS43 oder LLMNR44 bleiben konsequent deaktiviert, weil der potenzielle Erkenntnisgewinn für ein hochgehärtetes Live System in keinem vernünftigen Verhältnis zur zusätzlichen Angriffsoberfläche steht.

Diese Haltung passt gut zur generellen Bewegung rund um image based Linux, in der vermehrt versucht wird, Transport und Integrität von Systemkomponenten stärker zu kontrollieren. Die Diskussionen rund um Ubuntu Core, bootc basierte Plattformen oder auch die Image Based Linux Summit Treffen zeigen, dass viele Beteiligte ahnen, wie fragil das klassische, unendlich mutable Systembild inzwischen ist.45 Mein CISS.debian.live.builder schlägt hier eine eigene Schneise, indem er sich auf DNS und erste Netzwerkphasen konzentriert und dort bewusst keinerlei Kompromisse eingeht.

Secret Handling

Ein Builder, der mit Schlüsseln, Passphrasen, GPG Artifacts und diversen temporären Geheimnissen hantiert, kann sich keine lässige Haltung gegenüber Artefaktlebenszyklen leisten. Einer der entwicklungstechnisch aufwändigeren Teile des CISS.debian.live.builder ist deshalb die Secret Handling Pipeline.

Sensible Daten landen ausschliesslich in einem tmpfs unter /dev/shm/cdlb_secrets. Dieser Pfad wird bei Start und Ende des Runs kontrolliert, alle Objekte im Inneren erhalten restriktive Rechte, 0400 für root:root. Sobald im Secrets Pfad ein Symlink auftaucht, bricht der Builder den Run ab und behandelt dies als potentielle Manipulation. Shred Routinen zerlegen und überschreiben temporäre Dateien, sofern sie nicht ohnehin nur im Speicher existieren. GPG Verzeichnisse, die für Signaturvorgänge genutzt werden, werden nach Abschluss der Operation systematisch gelöscht.

Parallel dazu existiert eine klare Trennlinie zum Debugger. Bash xtrace wird auf kritischen Pfaden deaktiviert, bevor Passphrasen oder Schlüssel in Variablen fliessen. Die Debug Ausgaben dokumentieren Kontrollfluss, Entscheidungen, Hashwerte von nicht geheimen Daten und Laufzeitinformationen, aber niemals Rohgeheimnisse. Im Initramfs gilt ein vergleichbares Paradigma. Passwörter für LUKS Container fliessen in eine Pipe und erreichen cryptsetup nicht als Kommandozeilenargumente, sondern als Datenstrom, der sich nach Gebrauch verflüchtigt.

Dieses Secret Management hat einen weiteren, vielleicht auf den ersten Blick unspektakulären Effekt. Der Builder selbst bleibt in einem Zustand, in dem man ihn gefahrlos in CI Pipelines mit längeren Logs betreiben kann, ohne fürchten zu müssen, dass irgendwo in einem Anhang oder in einem Artefakt dump ein Klartextschlüssel auftaucht. Das verringert nicht nur die Angriffsoberfläche, sondern senkt auch die kognitive Last bei Audits.

Vergleich

Die naheliegende Frage lautet: könnte man all das nicht einfach mit KIWI NG oder einem der grossen Image Builder umsetzen. Die Antwort ist theoretisch ja, praktisch sehr viel weniger trivial. KIWI kann LUKS verschlüsselte Disk-Images erzeugen und sogar voll verschlüsselte Szenarien abbilden, in denen /boot innerhalb des verschlüsselten Volumes liegt.46 Die Dokumentation zeigt auch die Möglichkeit, Live Images und Cloud Appliances zu generieren. Trotzdem bleiben wesentliche Aspekte offen, etwa die enge Verzahnung mit Debians live-build Mechanik, die natürlich in der SUSE Welt keine Priorität hat, oder eine dropbear-basierte Remote Entsperrung im Initramfs mit strikt kontrollierter Attestationskette für ein Live Medium.

NixOS verfolgt einen radikal deklarativen Ansatz, bei dem das gesamte System als Ausdruck in einer funktionalen Konfigurationssprache beschrieben und der resultierende Zustand als Image materialisiert wird.47 Der Gewinn an Reproduzierbarkeit und Rollback Fähigkeit ist unbestritten. Wer allerdings ein Debian Live Environment mit bestehenden Paketquellen, gewohnter Toolchain und vertrautem Ecosystem sucht, landet mit NixOS nicht am Ziel, sondern in einer anderen Welt mit ihren eigenen, durchaus interessanten Regeln.

Auch bei den immutablen Varianten der grossen Distributionen ist das Bild ähnlich. Fedora Silverblue oder diverse Bluefin Abkömmlinge setzen auf read-only-Root und OSTree, um Update Robustheit zu erhöhen, und werden in einschlägigen Artikeln explizit als Antwort auf fragilere, paketbasierte Update Pfade angeführt.48 Der Fokus liegt aber klar auf einem Desktop System, das sich über längere Zeit auf einer Maschine hält, nicht auf einem streng gehärteten Live ISO Generator mit dem Ziel als Installationsbasis für Server zu sein.

Zuletzt bleibt die Frage nach Attestation. Keylime und ähnliche Systeme bieten sehr beachtliche Möglichkeiten, Boot Pfade, IMA Logs und PCR Zustandsräume zu validieren und so Kontinuität von Vertrauenseigenschaften im Lebenszyklus eines Systems zu sichern.49 Die Voraussetzung ist jedoch ein vertrauenswürdiges TPM, eine kontrollierbare Hardwareumgebung und eine Infrastruktur, die Messwerte erfasst, aggregiert und bewertet. Ein Live ISO, das auf sehr heterogener Hardware laufen soll und gerade erst den ersten Boot erlebt, ist ein anderes Biest. Aus diesem Grund beschränke ich mich bewusst auf eine Attestationsform, die an GPG Signaturen, Hashwerte und dm-integrity gekoppelt ist, ohne einen TPM Zwang zu erzeugen.

First of its own

Nach dieser Tour durch die Landschaft ist mir klar geworden, warum der CISS.debian.live.builder eine eigene Kategorie verdient. Er ist kein generischer Image-Builder, kein vollständiges image-based Betriebssystem, keine Privacy-Distro und kein akademisches Attestationsframework. Er ist ein sehr spezifisches Werkzeug für Administratoren, Kryptographie Interessierte und Sicherheitsingenieure, die ein Live-Medium brauchen, das sich wie ein gehärteter Server verhält und gleichzeitig die Flexibilität eines ISO-Images mitbringt.

Das beginnt bei Kleinigkeiten wie der konsequenten Deaktivierung von mDNS und LLMNR, führt über DoT only Resolverpolitik und DNSSEC fail-closed, zieht sich durch das Härtungsprofil des Kernels mit Parametern wie lockdown=integrity, init_on_alloc=1, page_poison=1 und strengen Audit Settings, endet bei einem fertig provisionierten, verschlüsselten und damit über unsichere Netze zu transportierendem Artifact, das mittels dropbear hochgesichert ebenso bequem entschlüsselt werden kann, und schliesst mit der Tatsache, dass der Builder selbst kein Geheimnis auf Platte lässt, das nicht explizit für die Endstruktur gebraucht wird. Der Weg dahin war länger, als es von aussen vielleicht wirkt. Viele Iterationen, zahllose Testboots in KVM und auf Bare Metal, ein stetiges Ringen mit live-build Eigenheiten, initramfs Fallstricken und den Feinheiten von dm-integrity.

Das Ergebnis ist ein Werkzeug, das mir eine schlichte, aber wichtige Möglichkeit gibt. Ich kann zu einem beliebigen Zeitpunkt ein ISO bauen, dessen kryptographisches und sicherheitstechnisches Profil ich nicht nur konzeptionell verstehe, sondern Zeile für Zeile nachvollziehen kann. Dieses ISO existiert nicht als marketinggetriebene Security Distribution, sondern als Bestandteil einer eigenen Infrastruktur aus Installer, Resolvern, Nameservern und gehärteten Serverprofilen. Gerade dadurch entsteht eine Kohärenz, die sich in anderen Kontexten nur schwer herstellen lässt.

Am Ende steht ein Anspruch, der vielleicht etwas altmodisch klingt. Ein System, das Sicherheit ernst nimmt, sollte nicht nur aus Komponenten bestehen, die einzeln beeindruckend sind. Es sollte in sich stimmig sein. CISS.debian.live.builder ist mein Versuch, dieses Prinzip auf die Sphäre der Live Medien anzuwenden. Nicht als universelle Lösung für alle, sondern als bewusst zugespitztes Werkzeug. Eben: First of its own.

  1. https://git.coresecret.dev/msw/CISS.debian.live.builder ↩︎
  2. https://wiki.debian.org/DebianLive ↩︎
  3. https://live-team.pages.debian.net/live-manual/html/live-manual/index.en.html ↩︎
  4. https://docs.kernel.org/admin-guide/device-mapper/dm-integrity.html ↩︎
  5. https://en.wikipedia.org/wiki/Linux_Unified_Key_Setup ↩︎
  6. Siehe Fn. 4 ↩︎
  7. https://en.wikipedia.org/wiki/SquashFS ↩︎
  8. https://wiki.archlinux.org/title/Sysctl ↩︎
  9. https://matt.ucc.asn.au/dropbear/dropbear.html ↩︎
  10. https://de.wikipedia.org/wiki/DNS_over_TLS ↩︎
  11. https://de.wikipedia.org/wiki/Domain_Name_System_Security_Extensions ↩︎
  12. https://www.cloudns.net/blog/servfail-explained-how-it-affects-your-internet-experience/ ↩︎
  13. https://osinside.github.io/kiwi/ ↩︎
  14. https://documentation.suse.com/appliance/kiwi-9/single-html/kiwi/kiwi.html ↩︎
  15. https://tails.net/ ↩︎
  16. https://de.wikipedia.org/wiki/Tails ↩︎
  17. https://de.wikipedia.org/wiki/Debian ↩︎
  18. https://de.wikipedia.org/wiki/Tor_(Netzwerk) ↩︎
  19. https://wiki.archlinux.org/title/Overlay_filesystem ↩︎
  20. Siehe Fn. 7 ↩︎
  21. https://linuxblog.io/immutable-linux-distros-are-they-right-for-you-take-the-test/ ↩︎
  22. https://media.ccc.de/v/all-systems-go-2023-195-system-and-configuration-extensions-for-image-based-linux-distros-and-beyond ↩︎
  23. https://fedoraproject.org/atomic-desktops/silverblue/ ↩︎
  24. https://de.wikipedia.org/wiki/Fedora_(Linux-Distribution)#Immutable_Varianten:_Fedora_Atomic_Desktop ↩︎
  25. https://bazzite.gg/ ↩︎
  26. https://de.wikipedia.org/wiki/Bazzite ↩︎
  27. https://ubuntu.com/core ↩︎
  28. https://developers.redhat.com/articles/2024/09/24/bootc-getting-started-bootable-containers ↩︎
  29. https://nixos.org/ ↩︎
  30. https://de.wikipedia.org/wiki/NixOS ↩︎
  31. https://keylime.dev/blog/2024/02/07/remote-attestation-blog-part1.html ↩︎
  32. https://de.wikipedia.org/wiki/Trusted_Platform_Module ↩︎
  33. https://docs.system-transparency.org/st-1.3.0/docs/selected-topics/remote-attestation/ ↩︎
  34. https://wiki.gentoo.org/wiki/Integrity_Measurement_Architecture ↩︎
  35. https://www.linux-magazin.de/ausgaben/2011/11/trusted-boot/ ↩︎
  36. https://systemd.io/TPM2_PCR_MEASUREMENTS/ ↩︎
  37. https://www.usenix.org/system/files/atc23-lee.pdf ↩︎
  38. https://www.redhat.com/de/topics/devops/what-cicd-pipeline ↩︎
  39. https://wiki.debian.org/Debootstrap ↩︎
  40. https://de.wikipedia.org/wiki/Argon2 ↩︎
  41. https://de.wikipedia.org/wiki/XTS-AES ↩︎
  42. https://dns01.eddns.eu/ ↩︎
  43. https://en.wikipedia.org/wiki/Multicast_DNS ↩︎
  44. https://de.wikipedia.org/wiki/Link-local_Multicast_Name_Resolution ↩︎
  45. https://techcommunity.microsoft.com/t5/linux-and-open-source-blog/the-2023-image-based-linux-summit/ba-p/4000271 ↩︎
  46. https://documentation.suse.com/appliance/kiwi-9/single-html/kiwi/kiwi.html ↩︎
  47. https://nixos.org/nixos/manual/ ↩︎
  48. https://medium.com/%40otto.p/im-switching-to-fedora-silverblue-for-now-6a4300ae77ee ↩︎
  49. https://keylime.dev/blog/2024/02/07/remote-attestation-blog-part1.html ↩︎

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

You may also like

Search: