Ich versuche, Selinux für ein Live-Boot-Debian-System zu konfigurieren.
SELinux ist aufgrund zahlreicher Änderungen während des Builds und der Systemkonfiguration nicht funktionsfähig und erfordert eine Neubezeichnung des gesamten Dateisystems. Dies muss beim Build mit dem Dateisystem als entpackte Squashfs-Datei, innerhalb von Chroot oder systemd-nspawn oder vom Hostsystem aus erfolgen.
Es wurde bisher keine Möglichkeit gefunden, dies erfolgreich durchzuführen. Die Datei /etc/selinux/default/contexts/files/file_contexts.subs_dist soll Dateisystemziele hinter Dateisystemspeicherorten als Alias angeben, aber ein Versuch, diese Dateisystemdatei während der SELinux-Neubenennung zum entpackten Squash-System umzuleiten, funktionierte nicht: SELinux benennt das Host-Dateisystem weiterhin neu, und das Squashfs-Dateisystem wurde als unbekannter Dateityp angegeben.
Gibt es eine einfache Möglichkeit, ein Dateisystem für SELinux in Squashfs neu zu benennen?
Antwort1
Für dieses Problem gibt es derzeit keine bekannte Lösung, die ich finden konnte, ich bin jedoch sicher, dass es möglich sein sollte, SELinux in oder auf einem beschreibbaren, entpackten Squashfs zu betreiben.
Andernfalls besteht eine Live-Build-Lösung darin, manuell mit Debootstrap zu erstellen, zu diesem Zeitpunkt ohne Isolinux und daher ohne Squashfs oder ISO, Kernel und Pakete hinzuzufügen; dann dieses beschreibbare Debian auf einen USB-Stick zu booten oder in einem virtuellen Gast zu booten; dann die SELinux-Neubenennung für das Dateisystem auszuführen. Sobald dies erledigt ist, kann der Build-Prozess von Isolinux zu Squashfs, ISO und dem üblichen, nicht beschreibbaren Hybridsystem fortgesetzt werden.
Die beschreibbare Methode wird hier beschrieben:
https://vdmit.org/linux/debian-live-usb-debootstrap.html
Der vorteilhafte, nicht beschreibbare hybride manuelle Build - die manuelle Methode, die ansonsten mit dem Debian-Live-Build-Skripting automatisiert werden soll - wird hier beschrieben:
https://l3net.wordpress.com/2013/09/21/how-to-build-a-debian-livecd/
Der einzige Nachteil dieser Methode besteht darin, dass die vollständige Konfiguration in der Debootstrap-Phase vorhanden sein muss, wie es im bootfähigen Hybridsystem der Fall sein wird, damit die Beschriftung korrekt ist, und dass keine Methode weiterhin verfügbar ist, um einen entpackten Squash neu zu beschriften, was ich für inakzeptabel halte, da Squashfs nach dem Erstellen möglicherweise bearbeitet werden muss.
Zusätzliche Objekte, die mit Konfigurations-Hooks importiert werden, erfordern natürlich entsprechende oder benutzerdefinierte Kontexte oder permissive Kontexte, die nach dem Booten gekennzeichnet werden, aber dies ist eine kleine Aufgabe mit geringem RAM-Verbrauch.
Ansonsten ist dies noch eine offene Frage.