LXC

1 📦 LXC (Linux Containers)

Um LXC in deinem Obsidian-Vault logisch einzuordnen, müssen wir die Virtualisierungswelt strikt in drei Kategorien unterteilen: Auf der einen Seite stehen Vollvirtualisierungen (wie KVM/QEMU, VirtualBox), die ein komplettes Betriebssystem inklusive eigenem Kernel und emulierter Hardware simulieren. Auf der anderen Seite stehen Anwendungs-Container (wie Docker, Podman), die darauf optimiert sind, eine einzige, spezifische Applikation (z. B. einen Webserver) isoliert auszuführen.

LXC schließt genau die Lücke dazwischen: Es ist ein System-Container.

Ein LXC-Container emuliert keine Hardware und bootet keinen eigenen Kernel. Stattdessen nutzt er die Kernfunktionen des Host-Kernels, startet darin aber ein vollständiges, isoliertes Init-System (wie systemd). Für den Admin fühlt sich ein LXC-Container exakt so an wie eine eigenständige Debian-, Arch- oder openSUSE-Installation, auf der man sich per SSH einloggen, Benutzer verwalten und Dienste installieren kann.

Die Kernphilosophie von LXC lautet:

„Biete die vollständige Isolation und das Look-and-Feel einer virtuellen Maschine, kombiniert mit der rasanten Geschwindigkeit und der minimalen Ressourcenlast eines nativen Prozesses.“

2 🏗️ DIE ARCHITEKTONISCHEN SÄULEN

LXC basiert direkt auf den Sicherheits- und Isolationsmechanismen des Linux-Kernels. Es benötigt keine Hypervisor-Software, sondern steuert zwei Kernfeatures des Kernels an:

2.1 1️⃣ Namespaces (Die Isolationsmauer)

Namespaces sorgen dafür, dass ein Prozess im Container glaubt, er sei völlig allein auf dem System. Sie isolieren die Sichtweise auf die Systemressourcen:

• pid (Prozess-IDs: Der Container hat seine eigene Prozess-ID 1/init).
• net (Netzwerk: Eigene virtuelle Netzwerkkarten, IP-Adressen und Routing-Tabellen).
• mnt (Dateisystem: Der Container sieht nur sein eigenes Root-Dateisystem via Chroot/Pivot_root).
• uts (Eigener Hostname).
• user (Zuweisung von Benutzer-IDs, wichtig für unprivilegierte Container).

2.2 2️⃣ Control Groups / cgroups (Die Ressourcen-Bremse)

Während Namespaces für die Isolation sorgen, regeln cgroups die Zuweisung und Begrenzung physikalischer Ressourcen. Hierdurch legt der Admin fest, wie viel RAM, wie viele CPU-Kerne oder wie viel Festplatten-I/O ein LXC-Container maximal vom Host-System beanspruchen darf. Ein Amok laufender Prozess im Container kann dadurch niemals den gesamten Host lahmlegen.

3 📊 KONTRAST-MATRIX: LXC VS. DOCKER

4 🛠️ DER SPICKZETTEL (LXC-CLI-WORKFLOW)

Die Interaktion mit LXC erfolgt unter Linux direkt im Terminal über die lxc-* Befehlskette (Hinweis: Für fortgeschrittenes Clustering und REST-API-Steuerung greift man heute oft auf den modernen Aufsatz LXD / Incus zurück, die Befehlsbasis im Kern bleibt jedoch ähnlich).

4.1 1️⃣ Einen neuen Debian-Container erstellen:

sudo lxc-create -n mein-debian-container -t download -- -d debian -r trixie -a amd64

(Der Parameter -t download lädt ein minimales, vorkonfiguriertes Root-Dateisystem direkt von den offiziellen LXC-Servern).

4.2 2️⃣ Den Container im Hintergrund starten:

sudo lxc-start -n mein-debian-container -d

4.3 3️⃣ Den Status aller Container abfragen:

sudo lxc-ls -f

4.4 4️⃣ Direkt in die Konsole des Containers springen (ohne SSH):

sudo lxc-attach -n mein-debian-container

(Du bist sofort als root im Container und kannst wie gewohnt mit apt update arbeiten).

4.5 5️⃣ Den Container stoppen:

sudo lxc-stop -n mein-debian-container

5 ⚠️ DIE TYPISCHEN LXC-STOLPERSTEINE

5.1 Das Sicherheits-Dilemma: Unprivilegierte vs. Privilegierte Container

• Das Problem:
  Ein Nutzer stellt fest, dass der Benutzer root (UID 0) innerhalb des LXC-Containers die exakt selbe UID hat wie der root-Nutzer auf dem Host-System. Er macht sich Sorgen um die Sicherheit.
• Die Ursache:
  Der Nutzer hat einen privilegierten Container erstellt. Gelingt es einem Angreifer, aus dem Container auszubrechen (Sicherheitslücke im Kernel), hat er sofort vollen Root-Zugriff auf das gesamte Host-System.
• Die Lösung:
  Dringender Wechsel auf Unprivilegierte Container (Unprivileged Containers). Hierbei wird das Kernel-Feature User Namespaces genutzt. Die UID 0 (root) im Container wird auf eine völlig unbedeutende, hohe UID (z. B. UID 100000) auf dem Host-System gemappt. Bricht der Angreifer aus, ist er auf dem Host ein absolut einflussloser Standard-Niemand ohne jegliche Rechte.

5.2 Das Mount-Problem: „Ich kann im LXC-Container kein NFS oder Samba-Share mounten“

• Das Problem:
  Ein Admin möchte innerhalb seines LXC-Containers ein Netzlaufwerk via NFS oder SMB einbinden. Der Befehl mount -t nfs ... schlägt jedoch mit einem Permission Denied oder Operation not permitted fehl, obwohl er als root im Container agiert.
• Die Ursache:
  Aus Sicherheitsgründen blockiert der Linux-Kernel standardmäßig das direkte Mounten von Netzwerkdateisystemen innerhalb unprivilegierter Container, da die dafür notwendigen Kernel-Treiber tiefe Systemrechte erfordern.

• Tipp:
  Das Problem wird nicht im Container gelöst, sondern auf dem Host-System. Das Netzlaufwerk direkt auf dem LXC-Host mounten und das Verzeichnis anschließend einfach per Bind-Mount in den Container durchreichen. Dazu editiert man die Konfigurationsdatei des Containers (z. B. /var/lib/lxc/mein-container/config) und fügt folgende Zeile hinzu:

  Code

  lxc.mount.entry = /mnt/host-nfs-freigabe mnt/container-zielordner none bind,create=dir 0 0

  Nach einem Neustart des Containers stehen die Daten sicher, performant und ohne Sicherheitsrisiko im Container zur Verfügung.

6 📝 FAZIT

LXC ist das absolute Schweizer Taschenmesser für Admins, die das Maximum an Dichte und Performance aus ihrer Hardware herausholen wollen. Wo eine Vollvirtualisierung (KVM) gigantischen Overhead erzeugt, laufen auf einem einzigen Host problemlos dutzende LXC-System-Container nebeneinander, da sie sich den Host-Kernel teilen.