Archiv für das Monat: November, 2025

Kritische Sicherheitslücke und ihre Auswirkungen auf Proxmox LXC-Container

In den letzten Tagen hat die Sicherheitslücke CVE-2025-52881 in der Container-Runtime runc für Aufsehen gesorgt. Diese Lücke, die einen Container-Escape und eine Denial-of-Service (DoS) ermöglichen kann, wurde durch ein wichtiges Sicherheitsupdate behoben. Leider führt die Art und Weise, wie dieser Fix implementiert ist – nämlich das erneute Öffnen von Dateideskriptoren (FD reopening) für procfs-Operationen – zu Konflikten mit den standardmäßigen AppArmor-Profilen von LXC-Containern unter Proxmox, insbesondere wenn Sie Docker oder andere Container-Engines innerhalb eines LXC-Containers betreiben (sogenanntes „Nested“ oder verschachteltes Container-Setup).

Was passiert?

Die Fehlermeldung, die Sie möglicherweise beim Starten oder Initialisieren von Containern sehen, sieht in etwa so aus:

open sysctl net.ipv4.ip_unprivileged_port_start file: reopen fd 8: permission denied

Dies tritt auf, weil der Sicherheitspatch in runc (oder einer abhängigen Komponente wie containerd.io, die durch das Update auf eine anfällige Version aktualisiert wurde) versucht, eine Systemdatei unter /proc/sys/net/ipv4/ip_unprivileged_port_start zu öffnen. Das AppArmor-Profil des Proxmox LXC-Containers blockiert jedoch diesen Zugriff, da es Schreibvorgänge auf die meisten /sys-Dateien unterbindet. Da /proc/sys oft auf /sys/ gemappt wird, interpretiert AppArmor den Zugriff als verbotenen /sys-Schreibvorgang.
Siehe auch: https://github.com/opencontainers/runc/issues/4968#issue-3593655843

️ Lösungsmöglichkeiten unter Proxmox

Da die Deaktivierung des Sicherheitsupdates keine Option ist (da es kritische Container-Escape-Schwachstellen behebt), müssen wir die LXC-Konfiguration anpassen. Ich würde euch hier die Lösung 3 eher ans Herz legen.

1. Empfohlene Lösung: Downgrade des betroffenen Pakets (Temporäre Lösung)

Die schnellste Lösung, die das Problem umgeht, besteht darin, das aktualisierte Paket, das den Fix enthält und den Konflikt verursacht, auf eine funktionierende, aber ältere (und potenziell anfällige) Version zurückzusetzen. Dies wird oft für containerd.io beobachtet, das die aktualisierte runc-Bibliothek enthält.

• ⚠️ Wichtig: Beachten Sie, dass dies die Sicherheitslücke CVE-2025-52881 wieder öffnet. Dies ist nur eine temporäre Notlösung, bis eine offizielle Korrektur des AppArmor-Profils in Proxmox/LXC verfügbar ist. Verwenden Sie dies nur, wenn Sie keine andere Wahl haben, und aktualisieren Sie sofort, wenn ein offizieller Fix herauskommt.

Beispiel für Ubuntu/Debian in Ihrem LXC-Container:

1. Prüfen Sie, welche Versionen verfügbar sind (ersetzen Sie das Release, z. B. jammy oder noble):

   Bash

   apt list -a containerd.io
   

2. Installieren Sie die letzte funktionierende Version (z. B. 1.7.28-1 anstelle von 1.7.29-1):
   # Für Ubuntu 22.04 Jammy:
   apt install containerd.io=1.7.28-1~ubuntu.22.04~jammy
   # Für Ubuntu 24.04 Noble:
   apt install containerd.io=1.7.28-1~ubuntu.24.04~noble
   

3. Starten Sie den Dienst neu:
   systemctl restart docker
   

2. Alternative: AppArmor im Container umgehen (Hotfix)

Eine andere schnelle, aber nicht empfohlene Methode als Hotfix ist, Docker vorzugaukeln, dass AppArmor deaktiviert ist. Auch hier gilt: Dies reduziert Ihre Sicherheit.

Führen Sie diesen Befehl im betroffenen LXC-Container aus:

mount --bind /dev/null /sys/module/apparmor/parameters/enabled
systemctl restart docker

Dies bindet /dev/null über die AppArmor-Statusdatei, was den Kernel glauben lässt, AppArmor sei im Container deaktiviert.

3. Die bessere, aber komplexere Lösung: Anpassung der LXC-Konfiguration

Die sicherste Langzeitlösung besteht darin, die AppArmor-Einschränkungen für den Container so anzupassen, dass der Zugriff auf die betroffene sysctl-Datei zugelassen wird, ohne die allgemeine Sicherheit zu stark zu schwächen.

Schritt 1: LXC-Konfigurationsdatei bearbeiten

Bearbeiten Sie auf dem Proxmox Host die Konfigurationsdatei Ihres Containers (ersetzen Sie VMID durch die ID Ihres Containers, z. B. 101):

nano /etc/pve/lxc/VMID.conf

Schritt 2: nesting aktivieren und AppArmor-Regeln hinzufügen

Stellen Sie sicher, dass die Nesting-Funktion aktiviert ist (dies ist oft für Docker in LXC erforderlich) und fügen Sie eine oder beide der folgenden Zeilen hinzu, um die AppArmor-Regeln zu modifizieren:

# Notwendig für verschachtelte Container (Docker in LXC)
features: nesting=1

# Fügen Sie diese Zeile hinzu, um das Schreiben von Sysctls zu erlauben
lxc.apparmor.profile: unconfined

# ODER, spezifischer (nur, wenn 'unconfined' nicht funktioniert oder zu offen ist):
# lxc.apparmor.profile: generated
# lxc.apparmor.allow-incomplete: 1
# lxc.mount.entry: /proc/sys/net/ipv4/ip_unprivileged_port_start proc/sys/net/ipv4/ip_unprivileged_port_start none bind,optional,create=file

Hinweis: unconfined deaktiviert AppArmor für diesen Container. Dies ist aus Sicherheitsgründen nicht ideal, aber eine gängige Lösung für tief verschachtelte Containerprobleme. Die spezifischere Bindung funktioniert möglicherweise nur, wenn AppArmor bestimmte Pfade zulässt.

Schritt 3: Container neu starten

Starten Sie den LXC-Container neu, damit die Änderungen wirksam werden.

pct stop VMID
pct start VMID

Fazit und Ausblick

Das Problem CVE-2025-52881 zeigt einmal mehr die Komplexität des Betriebs von Containern in Containern. Während die Sicherheitsupdates in runc essenziell sind, verursachen sie aufgrund der restriktiven AppArmor-Profile der LXC-Umgebung Probleme unter Proxmox.

Die beste langfristige Lösung ist eine Aktualisierung der Proxmox-Basis oder der LXC-AppArmor-Profile, um den notwendigen Zugriff zu gewähren, ohne die Sicherheit des Hosts zu gefährden. Bis dahin müssen Benutzer möglicherweise eine der genannten Workarounds anwenden und dabei stets das Risiko einer vorübergehenden Sicherheitsminderung im Auge behalten.