Docker-App-Container vs. dedizierter LXC-Container für privilegierte Home-Services: Was birgt mehr Risiko?

Wählen Sie einen Docker-Container mit den geringstmöglichen Berechtigungen, wenn der Dienst als Image bereitgestellt wird und nur eng begrenzt zugeordnete Dateien, Ports, Geräte und Capabilities benötigt. Wählen Sie einen dedizierten unprivilegierten LXC, wenn der Dienst eine umfassendere Linux-Umgebung, eine direkte Systemintegration oder mehrere verwandte Prozesse innerhalb eines separat verwalteten Gasts benötigt. Keines der beiden Modelle bleibt eine sinnvolle Sicherheitsgrenze, sobald Sie weitreichende Hostverzeichnisse, den Docker-Socket, uneingeschränkte Geräte oder Root-Rechte auf Host-Ebene bereitstellen.

Zuerst gleichwertige Bereitstellungsgrenzen vergleichen

Docker und LXC sind beides Linux-Containertechnologien, die den Host-Kernel gemeinsam nutzen, verpacken jedoch normalerweise unterschiedliche Einheiten. Docker isoliert üblicherweise eine einzelne Anwendung oder einen Compose-Stack. LXC erstellt einen schlanken Systemcontainer mit eigenen Benutzern, einer eigenen Paketdatenbank, eigenen Diensten und einem eigenen Dateisystem für das Betriebssystem.

Der faire Vergleich ist daher eine Docker-Anwendung, die direkt auf einem Linux-Host läuft, mit demselben privilegierten Heimdienst, der innerhalb eines dedizierten LXC installiert ist. Es geht nicht um Docker innerhalb von LXC im Vergleich zu LXC selbst und auch nicht um eines der beiden Containermodelle im Vergleich zu einer virtuellen Maschine mit einem separaten Kernel.

Der bestehende ZimaSpace-Vergleich von Docker- und nativen Installationen innerhalb von LXC behandelt Verpackung und Wartung. Dieser Artikel grenzt die Sicherheitsentscheidung ab, wenn der Dienst Berechtigungen anfordert, die gewöhnliche Containergrenzen schwächen.

Mit den genau erforderlichen Berechtigungen des Dienstes beginnen

„Privilegierter Heimdienst“ kann mehrere voneinander unabhängige Berechtigungen bedeuten: ein USB-Seriellgerät lesen, einen GPU-Renderknoten verwenden, eine Netzwerkschnittstelle steuern, ein Dateisystem mounten, einen niedrigen Port binden, auf Bluetooth zugreifen, SMART-Daten lesen oder andere Container verwalten. Diese Berechtigungen bergen nicht dasselbe Risiko für den Host.

Gewähren Sie die kleinste Capability, den kleinsten Gerätezugriff, den engsten Pfad und den eingeschränktesten Netzwerkmodus, mit denen der Dienst funktioniert. Snyks Erklärung des privilegierten Containermodus betont, dass der uneingeschränkte privilegierte Zugriff alle Host-Geräte und nahezu hostgleiche Berechtigungen offenlegt. Er sollte nicht die Untersuchung der einen fehlenden Berechtigung ersetzen.

Wenn ein Dienst nur /dev/dri/renderD128, einen Pfad für eine serielle Schnittstelle anhand der ID oder ein schreibgeschütztes Konfigurationsverzeichnis benötigen, können sowohl Docker als auch LXC diese begrenzte Ressource bereitstellen. Der Sicherheitsunterschied wird relevant, wenn die Bereitstellung weitreichende Berechtigungen oder mehrere Host-Schnittstellen erfordert.

Unprivilegiertes LXC schafft eine stärkere Grenze bei der Root-Zuordnung

In einem unprivilegierten LXC wird die UID 0 innerhalb des Gasts einer gewöhnlichen untergeordneten UID auf dem Proxmox-Host zugeordnet. Ein Prozess kann innerhalb des Containers als Root erscheinen, ohne außerhalb seines User-Namespaces die Identität des Host-Root zu besitzen. Dadurch werden die Folgen vieler Fehler bei Dateiberechtigungen und einiger Container-Ausbrüche reduziert.

Das Linux-Containers-Projekt beschreibt die Root-Zuordnung in unprivilegiertem LXC als primäre Sicherheitsgrenze des Designs; AppArmor, seccomp und Capabilities fügen zusätzliche Einschränkungen für Prozesse und Host-Ressourcen hinzu.

Der Vorteil hängt davon ab, dass der Container unprivilegiert bleibt. Ein privilegiertes LXC verwendet nicht dieselbe UID-Neuzuordnung, sodass Root innerhalb des Gasts viel direkter Root auf dem Host entspricht. Die Umstellung auf den privilegierten Modus allein zur Vereinfachung von Mounts oder Geräten kann den Grund beseitigen, aus dem LXC sicherer erschien.

-15% OFF

ZimaBoard 2 – Mini-Heimserver für Ihre große Idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Docker kann das Root-Risiko reduzieren, ohne die Anwendung in LXC zu verschieben

Docker-Container müssen nicht mit einem uneingeschränkten Root-Daemon und einem Root-Anwendungsbenutzer ausgeführt werden. Ein Container-Image kann einen Nicht-Root-Benutzer festlegen, die Laufzeitumgebung kann Berechtigungen entziehen, Dateisysteme können schreibgeschützt sein, und User-Namespaces können Container-Identitäten neu zuordnen.

Der Rootless-Modus von Docker führt sowohl den Daemon als auch die Container ohne Root-Rechte auf dem Host aus. Dies kann das Risiko durch Daemon und Laufzeitumgebung verringern, wenn die Anwendung und die benötigten Speicher- oder Netzwerkfunktionen die Einschränkungen des Rootless-Modus unterstützen.

Docker bleibt die bessere Abgrenzung, wenn die Anwendung bereits gut paketiert ist und nur eine eng begrenzte Berechtigung benötigt. Wird sie in einen vollständigen LXC-Container verschoben, kommt ein weiteres zu wartendes Betriebssystem hinzu, ohne dass sich dadurch automatisch die dem kompromittierten Prozess zugeordnete Ressource verringert.

Der Docker-Socket kann die Anwendungsgrenze aufheben

Einige Dashboards, Tools zur automatischen Aktualisierung, Sicherungstools und Überwachungsdienste fordern Zugriff auf /var/run/docker.sock. Über den Socket kann ein Client den Docker-Daemon des Hosts anweisen, Container zu erstellen, Host-Pfade einzubinden, Geräte bereitzustellen und Netzwerke zu ändern. Ein kompromittierter Dienst kann den Host daher indirekt kontrollieren, ohne einen Kernel-Ausbruch auszunutzen.

Die Analyse von Netdata erklärt, warum sich der Docker-Socket-Zugriff wie eine Host-Administration verhält: Der Prozess fordert den privilegierten Daemon auf, in seinem Namen mächtige Aktionen auf dem Host auszuführen, ohne dass ein herkömmlicher Ausbruch aus dem Container erforderlich ist.

Dies ist die erste Abgrenzung. Wenn der Dienst uneingeschränkten Zugriff auf den Docker-Socket benötigt, ist ein Vergleich zwischen normaler Docker-Isolierung und normaler LXC-Isolierung irreführend. Behandle den Dienst wie einen Host-Administrator, beschränke seine API nach Möglichkeit durch einen speziell entwickelten Proxy, isoliere ihn von nicht vertrauenswürdigen Netzwerken und schütze seine Zugangsdaten entsprechend.

Die Gerätezuordnung spricht für das Modell mit weniger Berechtigungsebenen

Eine GPU, ein USB-Controller, ein Tuner, ein Coral-Beschleuniger, eine USV oder ein serieller Adapter kann an beide Bereitstellungen weitergegeben werden. Bei direktem Docker stellt der Host das Gerät dem Anwendungscointainer bereit. Bei LXC stellt Proxmox das Gerät dem System-Container bereit, der den Dienst anschließend nativ ausführt oder ihn zur weiteren Weitergabe an verschachteltes Docker übergeben kann.

Der dedizierte LXC-Container kann übersichtlicher sein, wenn mehrere zusammengehörige Prozesse dasselbe Gerät benötigen und Linux-Benutzer oder -Gruppen den Zugriff verwalten sollen. Docker kann übersichtlicher sein, wenn ein Image ein Gerät benötigt und die Zuordnung direkt in Compose beschrieben wird.

Vermeiden Sie es, einem der beiden Container sämtliche Geräte zu geben, nur weil die Berechtigung für ein einzelnes Gerät schwierig einzurichten ist. Proxmox weist darauf hin, dass die LXC-Sicherheit Namespaces, AppArmor, seccomp und Gerätebeschränkungen kombiniert. Ein umfassender Gerätezugriff hebt einen Teil dieser mehrschichtigen Grenze auf, genau wie der privilegierte Modus von Docker.

Host-Bind-Mounts übertragen Risiken in unterschiedliche Richtungen

Eine Docker-Bind-Mount-Einbindung stellt den ausgewählten Hostpfad direkt für die Anwendung bereit. Eine beschreibbare Einbindung mit Fotos, Backups, Konfiguration oder dem Zustand anderer Anwendungen verleiht einem kompromittierten Container dieselben Änderungsrechte, die der zugeordnete Hostbenutzer für diesen Pfad besitzt.

Eine LXC-Bind-Mount-Einbindung stellt den Pfad dem Gast zur Verfügung, wo mehrere Dienste und administrative Benutzer entsprechend den UID- und GID-Zuordnungen darauf zugreifen können. Die zusätzliche Systemgrenze kann dabei helfen, Berechtigungen zu organisieren, vergrößert aber auch die Menge der Prozesse innerhalb des Gasts, die auf die Daten zugreifen könnten.

Verwenden Sie nach Möglichkeit schreibgeschützte Einbindungen, trennen Sie Konfiguration und Massendaten und vermeiden Sie die Einbindung des Host-Roots, /proc, /sys, /devoder Docker-Datenverzeichnisse allgemein. Wenn der Dienst geschützte NAS-Daten neu schreiben muss, kann die Anwendungsisolierung Snapshots und unabhängige Backups nicht ersetzen.

Netzwerkprivilegien können einen größeren Schadensradius als Dateisystemzugriff schaffen

Heimdienste wie VPN-Gateways, DNS-Filter, Tools zur Netzwerkerkennung, Home-Assistant-Integrationen und Überwachungssysteme können Host-Netzwerk, Raw-Sockets, Paketmitschnitte, Firewall-Änderungen oder Zugriff auf mehrere VLANs anfordern. Diese Fähigkeiten können Datenverkehr offenlegen und dem Dienst ermöglichen, andere Geräte zu beeinflussen.

Ein Docker-Container mit Host-Netzwerk verliert die Trennung auf Portebene, während zusätzliche Capabilities wie NET_ADMIN oder NET_RAW erhöhen, was ein kompromittierter Dienst anrichten kann. Ein LXC mit einer eigenen virtuellen Schnittstelle kann eine separate Adresse und Firewall-Richtlinie bereitstellen, aber ein privilegierter oder weitgehend gebrückter Gast kann weiterhin auf sensible Netzwerke zugreifen.

Wählen Sie die Grenze, mit der sich der Netzwerkpfad am engsten festlegen lässt. Ein separates VLAN, eine dedizierte Adresse, explizite Firewall-Regeln und kein Zugriff auf die NAS-Verwaltung senken das Risiko häufig stärker, als die Container-Technologie zu wechseln und den Dienst weiterhin in jedem vertrauenswürdigen Netzwerk bereitzustellen.

Privilegiertes LXC und privilegiertes Docker versagen auf unterschiedliche Weise

Ein vollständig privilegierter Docker-Container erhält über einen Root-Docker-Daemon umfangreiche Linux-Capabilities und Gerätezugriff. Ein privilegiertes LXC weist dem vollständigen Benutzerbereich des Gasts eine deutlich engere Identitätsbeziehung zum Root-Benutzer des Hosts zu. Keiner von beiden sollte wie ein gewöhnlicher unprivilegierter Anwendungscontainer behandelt werden.

Tigeras Sicherheitsempfehlungen warnen davor, dass der privilegierte Docker-Modus wichtige Isolationskontrollen umgeht. Auch Diskussionen in der Proxmox-Community warnen davor, dass das Aktivieren von Nesting oder eines umfassenden Zugriffs auf das Hostdateisystem innerhalb von LXC bei unvorsichtiger Konfiguration Hostbereiche wie /proc und /sys offenlegen kann.

Wenn der Dienst tatsächlich Berechtigungen benötigt, die denen von Root auf dem Host entsprechen, kann eine VM mit einem dedizierten Kernel eine klarere Begrenzung bieten. Der zusätzliche Speicher- und Speicherplatzbedarf kann gerechtfertigt sein, wenn der Dienst aus dem Internet erreichbar ist, nicht vertrauenswürdige Eingaben verarbeitet, kernelnahe Treiber lädt oder andere Workloads verwaltet.

Updates und Wiederherstellung bestimmen, ob die Isolation praktikabel bleibt

Docker macht das Anwendungspaket ersetzbar. Erstellen Sie den Container aus einem festgelegten Image oder Digest neu, stellen Sie Konfiguration und persistente Daten wieder her und wenden Sie dieselben eng begrenzten Berechtigungen erneut an. Das ist besonders wertvoll, wenn die Sicherheitsrichtlinie in Compose sichtbar ist, anstatt nur aus Shell-Befehlen erinnert werden zu müssen.

Ein dedizierter LXC macht die Betriebsumgebung als einen einzigen Proxmox-Gast ersetzbar. Die Paketdatenbank, Dienstdateien, Benutzer und Gerätemappings können gemeinsam gesichert werden. Die Wiederherstellung ist sauber, wenn Bind-Mounts, UID-Zuordnungen, Hostgeräte und Netzwerkregeln außerhalb des Gasts dokumentiert sind.

Der Vergleich von Docker-VMs und LXC-Gästen pro Anwendung für Wiederherstellungsgrenzen von ZimaSpace bietet den dazugehörigen Praxistest. Eine kleinere Sicherheitsgrenze ist nur dann sinnvoll, wenn sie wiederhergestellt werden kann, ohne umfassende Berechtigungen manuell neu erstellen zu müssen.

Führen Sie einen Test zur Privilegienreduzierung durch, bevor Sie sich für Docker oder LXC entscheiden

1. Listen Sie jedes Gerät, jeden Hostpfad, jede Capability, jedes Netzwerk, jede API und jede Kernel-Funktion auf, die der Dienst anfordert.
2. Entfernen Sie den vollständig privilegierten Modus und fügen Sie Anforderungen einzeln wieder hinzu.
3. Führen Sie die Anwendung als Benutzer ohne Root-Rechte oder, sofern unterstützt, in einem unprivilegierten LXC aus.
4. Ersetzen Sie umfassende beschreibbare Mounts durch eng begrenzte schreibgeschützte oder datensatzspezifische Pfade.
5. Entfernen Sie den Zugriff auf den Docker-Socket oder schalten Sie einen eingeschränkten Proxy zwischen den Dienst und den Daemon.
6. Überprüfen Sie die Annahmen zur Kompromittierung, indem Sie ermitteln, auf welche Hostdateien, Geräte und Netzwerke weiterhin zugegriffen werden kann.
7. Stellen Sie den Dienst auf einem sauberen Docker- oder LXC-Host ausschließlich mit versionierter Konfiguration wieder her.

Bewerten Sie die Sicherheit nicht allein anhand der Anzahl der Ebenen. Bewerten Sie die tatsächlich verfügbaren Berechtigungen, nachdem alle erforderlichen Geräte, Mounts, Capabilities, Sockets und Netzwerke hinzugefügt wurden. Ein einfacher Container mit eng begrenztem Zugriff kann sicherer sein als ein komplexes verschachteltes Design mit mehreren Ausnahmen.

Welche Grenze passt für den privilegierten Heimdienst?

Wählen Sie einen Docker-App-Container, wenn

Wählen Sie Docker, wenn der Dienst als Image verteilt wird, ein oder zwei explizit angegebene Geräte oder Mounts benötigt und ohne --privileged, uneingeschränkten Docker-Socket-Zugriff oder weitreichendes Host-Networking. Fixieren Sie Versionen, entfernen Sie Capabilities, verwenden Sie nach Möglichkeit schreibgeschützte Dateisysteme und halten Sie persistente Daten explizit.

Wählen Sie ein dediziertes unprivilegiertes LXC, wenn

Wählen Sie LXC, wenn der Dienst eine vollständigere Linux-Umgebung, mehrere zusammengehörige Daemons, direkte systemd-Integration oder komplexe Berechtigungen für Gerätegruppen benötigt. Behalten Sie das User-Namespace-Mapping bei, lassen Sie AppArmor- und Seccomp-Beschränkungen aktiviert und dokumentieren Sie jeden Host-Mount und jede Gerätezuordnung.

Wählen Sie stattdessen eine VM, wenn

Verwenden Sie eine VM, wenn die Arbeitslast eine Kontrolle auf Host-Root-Niveau benötigt, ungewöhnliche Treiber lädt, andere Arbeitslasten verwaltet, nicht vertrauenswürdige öffentliche Eingaben akzeptiert oder nicht ohne weitreichende Datei- und Netzwerkberechtigungen ausgeführt werden kann. Ein separater Kernel schafft eine stärkere Grenze, als einem Container mit gemeinsamem Kernel immer mehr Ausnahmen hinzuzufügen.

FAQs

Ist ein privilegiertes LXC sicherer als ein privilegierter Docker-Container?

Nicht als allgemeine Regel. Beide haben wichtige Isolationskontrollen geschwächt, setzen ihre Möglichkeiten jedoch auf unterschiedliche Weise frei. Bewerten Sie UID-Mapping, Geräte, Mounts, Capabilities, Netzwerkzugriff, AppArmor, Seccomp und Daemon-APIs, statt sich auf die Bezeichnung des Containers zu verlassen.

Fügt das Ausführen von Docker in einem unprivilegierten LXC eine weitere Sicherheitsebene hinzu?

Dies kann ein UID-Mapping zwischen dem LXC und dem Proxmox-Host ermöglichen, aber verschachteltes Docker kann Nesting-Funktionen, zusätzliche Capabilities, Ausnahmen für Dateisysteme oder Gerätezuordnungen erfordern. Diese Änderungen können den Vorteil wieder aufwiegen. Eine VM ist klarer, wenn eine starke Trennung vom Host erforderlich ist.

Benötigen LAN-exklusive Heimdienste unprivilegierte Container?

Ja, wenn eine Kompromittierung über ein anderes LAN-Gerät, eine verwundbare Weboberfläche, bösartige Medien- oder Dokumenteingaben, Images aus der Lieferkette oder offengelegte Zugangsdaten erfolgen kann. Eine LAN-exklusive Platzierung verringert zwar einige Angriffsflächen, macht den Root-Zugriff auf den Host jedoch nicht harmlos.

Fazit

Verwenden Sie Docker, wenn eine paketierte Anwendung mit eng definierten Berechtigungen und ohne administrative Host-Schnittstellen ausgeführt werden kann. Verwenden Sie ein unprivilegiertes LXC, wenn ein Dienst ein vollständigeres Linux-System benötigt, während das Root-Mapping und der kontrollierte Gerätezugriff erhalten bleiben. Wenn eines der beiden Designs weitreichende Root-Rechte auf dem Host, uneingeschränkten Socket-Zugriff oder Schreibzugriff auf kritische Daten erfordert, beenden Sie den Containervergleich und verlagern Sie den Dienst hinter eine stärkere VM- oder Separate-Machine-Grenze.