Custom Discovery Images für SecureBoot

Im letzten Artikel „orcharhino und SecureBoot“ habe ich erklärt, was SecureBoot ist, wie es funktioniert und welche Möglichkeiten es gibt, es in orcharhino zu implementieren. Dazu wurden am Ende verschiedene Möglichkeiten und Lösungen aufgezeigt, wobei hier auf Option 2 näher eingegangen werden soll. Ich empfehle diesen Blog Post vorab zu lesen für ein besseres Verständnis des Folgenden.

Das Foreman Discovery Image

Das Foreman Discovery Image (FDI) ist ein „kleines RedHat-basiertes Image welches via PXE in den Arbeitsspeicher geladen wird, alle Netzwerkinterfaces initialisiert und via systemd ein Skript namens „discovery-register“ ausführt.“ (vgl. [1]). Dieses Skript kontaktiert den orcharhino Server mittels einer mitgegebenen URL und lädt dort die Host-Facts hoch um den Host im orcharhino Server als Discovered-Host einzutragen. Ist der Host dann dem orcharhino Server bekannt, kann bspw. eine Installation der Ziel-Distribution mittels kexec [2] gestartet werden. Diese Art des Installation benötigt keinen Reboot.

Fertige FDIs können von Index of /discovery/releases bezogen werden.

Diese FDIs unterstützen bereits die Erweiterung um zusätzliche Skripte/Funktionalität zur Laufzeit, in dem ZIP-Archive bspw. von einem TFTP- oder HTTP-Server nachgeladen werden können.

Alternativ kann ein FDI auch lokal gebaut werden.
Gründe dafür sind bspw. aktuellere Paketversionen oder ein aktuellerer Kernel für die Unterstützung neuerer Hardware.

Mit dem Upstream-Repository [3] kann jeder ein FDI lokal selber bauen, allerdings mit den folgenden zwei Einschränkungen:

die Build-Umgebung muss ein Enterprise Linux 8 (EL) System sein, bspw. RedHat Enterprise Linux 8, Rocky Linux 8 oder AlmaLinux 8
das resultierende FDI ist ein entsprechendes EL-basiertes System

Im Kontext von SecureBoot bedeutet Letzteres vereinfacht gesagt, dass mittels kexec nur eine Installation der selben Distribution gestartet werden kann da der Kernel sich im Lockdown befindet (vgl. [4]).

Somit können andere Distributionen wie bspw. Ubuntu, Debian oder SUSE mit aktiviertem SecureBoot in Kombination mit einem EL-basierten FDI nicht installiert werden.

Aufgrund meiner Erfahrungen mit früheren Projekten kam mir ein Tool in den Sinn, mit dem man diese Einschränkungen überwinden kann: KIWI NG.

KIWI NG

KIWI Next Generation (KIWI NG) ist ein Open-Source-Tool zur Erstellung von benutzerdefinierte Images. Es stellt ein Kommandozeilenprogramm bereit und nutzt Konfigurationsdateien, die es Benutzern ermöglichen, die Komponenten und Einstellungen eines gewünschten Images zu definieren. KIWI NG unterstützt verschiedene Image-Formate, darunter ISO und virtuelle Festplatten-Images. Es vereinfacht den Prozess der Erstellung reproduzierbarer und maßgeschneiderter Images für verschiedene Einsatzzwecke, wie Installationsmedien oder Bereitstellung in virtualisierten Umgebungen. KIWI NG wird u.a. im openSUSE Build Service (OBS) [5] eingesetzt.

KIWI NG kann auf verschiedensten Linux-Distributionen entweder über den jeweiligen Paketmanager installiert werden [6] oder via PyPI [7].

Um KIWI NG in einem Container laufen zu lassen sind erweiterte Privilegien nötig, bspw. für die benötigten mount-Syscalls.

Ein KIWI-Image wird durch folgende Dateien/Verzeichnisse konfiguriert:

Eine XML-basierte Konfigurationsdateien, die verschiedene Aspekte des Images festlegen, wie das Basisbetriebssystem, zu installierende Pakete, das Ausgabeformat (z.B. ein ISO-Image), die Dateisystemstruktur, etc.
Ein Bash-Skript welches im Ziel-Image ausgeführt wird und Anpassungen vornehmen kann wie bspw. die Konfiguration von Diensten.
Ein root-Verzeichnis mit allen zusätzlichen Dateien, die später im Wurzelverzeichnis des Images existieren sollen.

Es wird empfohlen ausgehend von Beispiel-Konfigurationen (vgl. [8]), den sogenannten Image-Beschreibungen, sein benutzerdefiniertes Image zu konfigurieren.

Um eine Ubuntu-Installation, bspw. Ubuntu 22.04, via kexec aus einem FDI heraus starten zu können bei aktiviertem SecureBoot, benötigen wir ein Ubuntu-basiertes FDI.

Foreman Discovery Image selber bauen mit KIWI NG

Nach einer Analyse der fertigen FDIs von Upstream und der EL-basierten Build-Skripte fiel auf, dass ein FDI grundsätzlich aus einem Foreman Proxy und zusätzlichen Skripten und Services besteht. Eine Suche ergab, dass der Foreman Proxy als Paket(e) für Ubuntu 20.04 (Focal) unter Index of /dists/focal verfügbar ist. Damit fiel die Wahl des Basisbetriebsystems ebenfalls auf Ubuntu 20.04 (Focal), das gewünschte Image-Format ist ein ISO. Die XML-basierte Konfigurationsdateien wurde um die Repository-URL, das foreman-proxy Paket und andere Pakete erweitert (vgl. [9]).

Die Konfiguration des Images (vgl. [10]) kann größtenteils in das Bash-Skript übernommen werden.
Dort werden u.a. alle benötigten Services konfiguriert und eingeschalten damit diese beim Booten des FDI aktiv sind.

In das root-Verzeichnis werden alle zusätzlichen Skripte kopiert, die nicht über Pakete installiert werden können. Das betrifft u.a. das Discovery-Menu, welches beim Systemstart angezeigt wird und eine manuelle Bedienung des FDI zur Laufzeit erlaubt.

Hat man alles beisammen, kann das Image gebaut werden:

# kiwi-ng --debug system build --description ubuntu/x86_64/ubuntu-focal --target-dir /root/fdi-image

Der Build dauert je nach Build-Umgebung bis zu 30min. Das entstandene ISO kann nun als Boot-Medium genutzt werden, im einfachsten Fall bereitgestellt als virtuelles CD/DVD-Gerät. Nach der Kontaktaufnahme des Ubuntu-basierten FDI zum orcharhino Server kann eine Ubuntu 22.04 Installation via kexec gestartet werden. Das ist möglich, da das über shim (vgl. [14]) gebootete FDI eine Liste von vertrauenswürdigen Schlüsseln vorhält. Dazu gehören vereinfacht gesagt immer die aktuellen Herstellerschlüssel (z.B. von Canonical Ltd.), mit denen auch der Installations-Kernel signiert wurde.

Das hier beschriebene Vorgehen wurde stark vereinfacht zusammengefasst. Das Ergebnis zum Nachbauen eines FDIs mittels KIWI NG wurde auf GitHub veröffentlicht [11]. Neben Ubuntu gibt es auch eine CentOS und AlmaLinux basierende Image-Beschreibung. Die Ubuntu Image-Beschreibung verlangt übrigens den HWE-Kernel [12] um die neuste Hardwareunterstützung zu gewährleisten.

Übrigens: Der OBS kann aktuell nicht ohne weiteres für den Bau des FDIs genutzt werden da der Zugriff auf externe Repositories (hier für die Foreman-Pakete) gesperrt ist. Man könnte versuchen die benötigten Foreman-Pakate ebenfalls im OBS zu bauen und zu paketieren um diese dann nutzen zu können.

Foreman Discovery Image über PXE bereitstellen

Der Einsatz von FDIs erfolgt u.a. in PXE-Umgebungen (Netzwerk-Boot) mittels DHCP- und TFTP-Server. Für ein Standard-Setup (vgl. [13]) in einer PXE-Umgebung wird anstelle der ISO-Datei ein tar-Archiv benutzt. Dieses tar-Archiv beinhaltet neben dem FDI Kernel auch eine Initrd, welche das komplette FDI root-Verzeichnis beinhaltet, und ensteht als zusätzliches Artefakt beim Bau mit dem Upstream-Repository (siehe oben).

Bei KIWI NG erhalten wir nur die ISO-Datei als Artefakt. Die darin enthaltene Initrd enthält nicht das komplette FDI root-Verzeichnis, ist aber in der Lage, die ISO-Datei mittels HTTP herunterzuladen, das darin enthaltene root-Verzeichnis zu mounten und das System zu starten.

Diese Variante wird übrigens von allen FDIs unterstützt und bietet bei PXE-Umgebungen mit TFTP einen erheblichen Zeitgewinn, da das mehrere Hunderte Megabyte große FDI root-Verzeichnis nicht über das langsame TFTP- sondern über das HTTP-Protokoll geladen wird.

Die Vorbereitung auf dem jeweiligen orcharhino Proxy sieht wie folgt aus:

mount /tmp/fdi.iso /mnt/
mkdir /var/lib/tftpboot/boot/fdi-image-slim
cp /mnt/isolinux/{vmlinuz,initrd.img} /var/lib/tftpboot/boot/fdi-image-slim/
umount /mnt
mkdir /var/www/html/pub/fdi-image-slim
mv /tmp/fdi.iso /var/www/html/pub/fdi-image-slim

Das ISO wird gemountet, der Kernel und die Initrd werden in das TFTP-Verzeichnis kopiert. Das ISO selber wird in das HTTP-Verzechnis verschoben, damit es später von Initrd heruntergeladen werden kann.

Zum Schluss muss noch das PXE-Template angepasst werden (pxegrub2_discovery Snippet):

common_slim="rootflags=loop root=live:http://YOURPROXY/pub/fdi-image-slim/fdi.iso rootfstype=auto ro rd.live.image acpi=force rd.luks=0 rd.md=0 rd.dm=0 rd.lvm=0 rd.bootif=0 rd.neednet=0 nokaslr nomodeset proxy.url= proxy.type=proxy BOOTIF=01-$net_default_mac ip=dhcp"

menuentry 'Foreman Discovery Image EFI Slim' --id discovery {
  linuxefi boot/fdi-image-slim/vmlinuz ${common_slim}
  initrdefi boot/fdi-image-slim/initrd.img
}

Dieser Eintrag erlaubt das Booten eines FDI mit kleiner Initrd und dem Nachladen des root-Verzeichnis aus der ISO-Datei (siehe root=live: Parameter). Denkbar ist auch die Verwendung mehrere FDIs parallel die auf unterschiedlichen Distributionen basieren.

Zusammenfassung

Fertige FDIs können aus Onlinequellen heruntergeladen werden. Das Selber bauen von FDIs ermöglicht die Verwendung von aktuelleren Paketständen inkl. dem Kernel, welches zu einer besseren Hardwareunterstützung beiträgt. Ist SecureBoot aktiviert, muss man für jede zu installierende Distribution ein entsprechendes FDI bauen welches auf der jeweiligen Distribution basiert.

Das Bauen von FDIs, speziell für Nicht-EL-basierende Distributionen, gelingt mit KIWI NG. Mittels der Image-Beschreibungen aus [11] kann jeder relativ einfach ein FDI lokal bauen welches auf Ubuntu, CentOS oder AlmaLinux basiert und damit die jeweilige Beschränkung bzgl. SecureBoot erfüllt.

[1]: https://github.com/theforeman/foreman-discovery-image

[2]: https://linux.die.net/man/8/kexec

[3]: https://github.com/theforeman/foreman-discovery-image

[4]: https://wiki.debian.org/SecureBoot#Secure_Boot_limitations

[5]: https://build.opensuse.org/

[6]: https://osinside.github.io/kiwi/installation.html#installation-from-obs

[7]: https://pypi.org/project/kiwi/

[8]: https://github.com/OSInside/kiwi-descriptions

[9]: https://github.com/theforeman/foreman-discovery-image/blob/master/20-packages.ks

[10]: https://github.com/theforeman/foreman-discovery-image/blob/master/22-discovery.ks

[11]: https://github.com/ATIX-AG/foreman-discovery-image-kiwi

[12]: https://www.thomas-krenn.com/de/wiki/Ubuntu_LTS_Hardware_Enablement_Stack