Docker-appcontainer versus een speciale LXC voor geprivilegieerde thuisservices: wat brengt meer risico met zich mee?

Kies een Docker-container met minimale privileges wanneer de service als image wordt gedistribueerd en alleen nauwkeurig toegewezen bestanden, poorten, apparaten en capabilities nodig heeft. Kies een toegewijde niet-geprivilegieerde LXC wanneer de service een completere Linux-omgeving, directe systeemintegratie of meerdere verwante processen binnen één afzonderlijk beheerde gast nodig heeft. Geen van beide modellen blijft een betekenisvolle beveiligingsgrens nadat je brede hostmappen, de Docker-socket, onbeperkte apparaten of rootrechten op hostniveau beschikbaar hebt gemaakt.

Vergelijk eerst gelijkwaardige implementatiegrenzen

Docker en LXC zijn beide Linux-containertechnologieën die de hostkernel delen, maar ze verpakken doorgaans verschillende eenheden. Docker isoleert normaal gesproken één applicatie of Compose-stack. LXC maakt een lichtgewicht systeemcontainer met eigen gebruikers, pakketdatabase, services en bestandssysteem van het besturingssysteem.

De eerlijke vergelijking is daarom een Docker-applicatie die rechtstreeks op een Linux-host draait tegenover dezelfde geprivilegieerde homeservice die binnen een toegewijde LXC is geïnstalleerd. Het gaat niet om Docker binnen LXC versus LXC zelf, en ook niet om een van beide containermodellen versus een virtuele machine met een afzonderlijke kernel.

De bestaande ZimaSpace-vergelijking van Docker en native installaties binnen LXC behandelt verpakking en onderhoud. Dit artikel beperkt zich tot de beveiligingskeuze wanneer de service privileges vereist die de gebruikelijke containergrenzen verzwakken.

Begin met exact de privileges die de service nodig heeft

‘Geprivilegieerde thuisservice’ kan verschillende, los van elkaar staande rechten betekenen: een USB-serieel apparaat lezen, een GPU-rendernode gebruiken, een netwerkinterface beheren, een bestandssysteem koppelen, een lage poort binden, Bluetooth gebruiken, SMART-gegevens lezen of andere containers beheren. Deze rechten brengen niet hetzelfde risico voor de host met zich mee.

Geef de kleinste capability, apparaatmachtiging, het smalste pad en de beperktste netwerkmodus waarmee de service werkt. Snyks uitleg over de geprivilegieerde containermodus benadrukt dat volledige geprivilegieerde toegang alle hostapparaten en vrijwel hostgelijkwaardige bevoegdheden blootlegt. Deze modus mag niet dienen als vervanging voor het onderzoeken van de ene ontbrekende toestemming.

Als een service alleen /dev/dri/renderD128, één serieel pad op basis van ID of één alleen-lezen configuratiemap, dan kunnen zowel Docker als LXC die beperkte bron beschikbaar stellen. Het beveiligingsverschil wordt pas relevant wanneer de implementatie brede capabilities of meerdere hostoppervlakken vereist.

Niet-geprivilegieerde LXC creëert een sterkere grens voor roottoewijzing

In een niet-geprivilegieerde LXC wordt UID 0 binnen de gast gekoppeld aan een gewone subordinate UID op de Proxmox-host. Een proces kan binnen de container root lijken, terwijl het buiten zijn user namespace geen identiteit als root op de host heeft. Dit beperkt de gevolgen van veel fouten met bestandsrechten en van sommige container-ontsnappingen.

Het Linux Containers-project beschrijft de roottoewijzing van niet-geprivilegieerde LXC als de belangrijkste beveiligingsgrens van het ontwerp, waarbij AppArmor, seccomp en capabilities verdere beperkingen opleggen aan processen en hostbronnen.

Het voordeel hangt ervan af dat de container zonder uitgebreide rechten blijft draaien. Een geprivilegieerde LXC gebruikt niet dezelfde UID-toewijzing, waardoor root binnen de gast veel directer overeenkomt met root op de host. Overschakelen naar de geprivilegieerde modus uitsluitend om mounts of apparaten eenvoudiger te maken, kan de reden wegnemen waarom LXC veiliger leek.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Docker kan het rootrisico verminderen zonder de applicatie naar LXC te verplaatsen

Docker-containers hoeven niet te draaien met een daemon met onbeperkte rootrechten en een rootgebruiker voor de applicatie. Een containerimage kan een niet-rootgebruiker opgeven, de runtime kan capabilities laten vervallen, bestandssystemen kunnen alleen-lezen zijn en user namespaces kunnen containeridentiteiten opnieuw toewijzen.

De rootless-modus van Docker voert zowel de daemon als de containers uit zonder rootrechten op de host. Dit kan de risico's van de daemon en runtime beperken wanneer de applicatie en de vereiste opslag- of netwerkfuncties de beperkingen van rootless ondersteunen.

Docker blijft de betere isolatiegrens wanneer de app al goed is verpakt en slechts één nauwkeurig afgebakend privilege nodig heeft. Door de app naar een volledige LXC te verplaatsen voeg je een extra besturingssysteem toe dat moet worden bijgewerkt, zonder automatisch de aan de gecompromitteerde applicatie gekoppelde resource te beperken.

De Docker-socket kan de applicatiegrens tenietdoen

Sommige dashboards, automatische updaters, back-uptools en monitoringservices vragen toegang tot /var/run/docker.sock. Via de socket kan een client de Docker-daemon van de host opdracht geven containers te maken, hostpaden te koppelen, apparaten beschikbaar te stellen en netwerken te wijzigen. Een gecompromitteerde service kan de host daardoor indirect beheren zonder een kernel-escape uit te buiten.

De analyse van Netdata legt uit waarom toegang tot de Docker-socket zich gedraagt als hostbeheer: het proces vraagt de bevoorrechte daemon om namens het proces krachtige hostacties uit te voeren, zonder een conventionele ontsnapping uit de container.

Dit is de eerste grens waarbij je moet stoppen. Als de service onbeperkte toegang tot de Docker-socket vereist, is een vergelijking tussen normale Docker-isolatie en normale LXC-isolatie misleidend. Behandel de service als een hostbeheerder, beperk de API indien mogelijk via een speciaal daarvoor gebouwde proxy, isoleer de service van niet-vertrouwde netwerken en bescherm de bijbehorende inloggegevens dienovereenkomstig.

Apparaatkoppeling bevoordeelt het model met minder toestemmingslagen

Een GPU, USB-coördinator, tuner, Coral-accelerator, UPS of seriële adapter kan aan beide implementaties worden doorgegeven. Bij directe Docker stelt de host het apparaat beschikbaar aan de applicatiecontainer. Bij LXC stelt Proxmox het apparaat beschikbaar aan de systeemcontainer, die de service vervolgens native uitvoert of het apparaat opnieuw kan doorgeven aan geneste Docker.

De toegewezen LXC kan overzichtelijker zijn wanneer meerdere gerelateerde processen hetzelfde apparaat nodig hebben en Linux-gebruikers of -groepen de toegang moeten beheren. Docker kan overzichtelijker zijn wanneer één image één apparaat nodig heeft en de koppeling rechtstreeks in Compose wordt beschreven.

Geef geen van beide containertypen toegang tot alle apparaten alleen omdat één apparaatmachtiging lastig is. Proxmox merkt op dat LXC-beveiliging namespaces, AppArmor, seccomp en apparaatbeperkingen combineert. Brede apparaattoegang verwijdert een deel van die gelaagde grens, net zoals de geprivilegieerde modus van Docker.

Host-bindkoppelingen dragen risico's in verschillende richtingen over

Een Docker-bindkoppeling stelt het geselecteerde hostpad rechtstreeks beschikbaar aan de applicatie. Een schrijfbare koppeling met foto's, back-ups, configuratie of de status van andere applicaties geeft een gecompromitteerde container dezelfde wijzigingsrechten op dat pad als de toegewezen hostgebruiker.

Een LXC-bindkoppeling stelt het pad beschikbaar aan de gast, waar meerdere services en beheerders er toegang toe kunnen hebben volgens de UID- en GID-toewijzingen. De extra systeemgrens kan helpen bij het organiseren van machtigingen, maar vergroot ook de groep processen binnen de gast die de gegevens kunnen bereiken.

Gebruik waar mogelijk alleen-lezenkoppelingen, splits configuratie en bulkgegevens op en vermijd het koppelen van de root van de host, /proc, /sys, /dev, of Docker-gegevensmappen in brede zin. Als de service beveiligde NAS-gegevens moet herschrijven, kan applicatie-isolatie snapshots en onafhankelijke back-ups niet vervangen.

Netwerkprivileges kunnen een grotere impact hebben dan toegang tot het bestandssysteem

Thuisservices zoals VPN-gateways, DNS-filters, tools voor netwerkdetectie, Home Assistant-integraties en monitoringsystemen kunnen hostnetwerken, raw sockets, pakketvastlegging, firewallwijzigingen of toegang tot meerdere VLAN's vereisen. Deze mogelijkheden kunnen verkeer blootleggen en de service in staat stellen andere apparaten te beïnvloeden.

Een Docker-container met hostnetwerken verliest netwerkscheiding op poortniveau, terwijl extra mogelijkheden zoals NET_ADMIN of NET_RAW kunnen de gevolgen van een inbreuk vergroten. Een LXC met een eigen virtuele interface kan een afzonderlijk adres en firewallbeleid bieden, maar een geprivilegieerde of breed overbrugde gast kan nog steeds gevoelige netwerken bereiken.

Kies de grens waarmee u het smalste netwerkpad kunt definiëren. Een afzonderlijke VLAN, een speciaal adres, expliciete firewallregels en geen toegang tot NAS-beheer beperken risico's vaak meer dan het wisselen van containertype terwijl de service op elk vertrouwd netwerk blijft.

Geprivilegieerde LXC en geprivilegieerde Docker falen op verschillende manieren

Een volledig geprivilegieerde Docker-container ontvangt via een rootful Docker-daemon uitgebreide Linux-mogelijkheden en toegang tot apparaten. Een geprivilegieerde LXC geeft een volledige gebruikersruimte van de gast een veel nauwere identiteitsrelatie met de rootgebruiker van de host. Geen van beide moet worden behandeld als een gewone, niet-geprivilegieerde applicatiecontainer.

De beveiligingsrichtlijnen van Tigera waarschuwen dat de geprivilegieerde Docker-modus belangrijke isolatiecontroles omzeilt. Discussies in de Proxmox-community waarschuwen eveneens dat het inschakelen van nesting of brede toegang tot het hostbestandssysteem binnen LXC de hostoppervlakken /proc en /sys kan blootleggen wanneer dit onzorgvuldig wordt geconfigureerd.

Als de service daadwerkelijk rechten nodig heeft die gelijkwaardig zijn aan die van root op de host, kan een VM met een eigen kernel een duidelijkere inperkingsgrens bieden. De extra geheugen- en opslagoverhead kan gerechtvaardigd zijn wanneer de service vanaf internet bereikbaar is, niet-vertrouwde invoer verwerkt, kernel-nabije stuurprogramma's laadt of andere workloads beheert.

Updates en herstel bepalen of isolatie bruikbaar blijft

Docker maakt het applicatiepakket vervangbaar. Maak de container opnieuw aan vanuit een vastgezette image of digest, herstel de configuratie en persistente gegevens en pas dezelfde beperkte privileges opnieuw toe. Dit is waardevol wanneer het beveiligingsbeleid zichtbaar is in Compose in plaats van te worden onthouden uit shellopdrachten.

Een speciale LXC maakt de besturingsomgeving vervangbaar als één Proxmox-gast. De pakketdatabase, servicebestanden, gebruikers en apparaatkoppelingen kunnen samen worden geback-upt. Herstel verloopt schoon wanneer bind-mounts, UID-toewijzingen, hostapparaten en netwerkregels buiten de gast zijn gedocumenteerd.

De vergelijking van ZimaSpace tussen herstelgrenzen van een Docker-VM en een LXC-container per app biedt de bijbehorende operationele test. Een kleinere beveiligingsgrens is alleen nuttig als deze kan worden hersteld zonder brede privileges handmatig opnieuw te moeten aanmaken.

Gebruik een test voor privilegevermindering voordat je Docker of LXC kiest

1. Maak een lijst van elk apparaat, hostpad, capability, netwerk, elke API en kernelvoorziening die de service aanvraagt.
2. Verwijder de volledige geprivilegieerde modus en voeg vereisten één voor één weer toe.
3. Voer de applicatie uit als een niet-rootgebruiker of binnen een onbevoorrechte LXC-container waar dit wordt ondersteund.
4. Vervang brede schrijfbare mounts door beperkte alleen-lezenpaden of paden die specifiek zijn voor een dataset.
5. Verwijder toegang tot de Docker-socket of plaats een beperkte proxy tussen de service en de daemon.
6. Test aannames over een mogelijke inbreuk door te controleren welke hostbestanden, apparaten en netwerken bereikbaar blijven.
7. Herstel de service op een schone Docker- of LXC-host met uitsluitend versiebeheerste configuratie.

Beoordeel beveiliging niet alleen op basis van het aantal lagen. Beoordeel de effectieve rechten die beschikbaar zijn nadat alle vereiste apparaten, mounts, capabilities, sockets en netwerken zijn toegevoegd. Een eenvoudige container met beperkte toegang kan veiliger zijn dan een complex genest ontwerp met meerdere uitzonderingen.

Welke grens past bij de geprivilegieerde thuisservice?

Kies een Docker-appcontainer wanneer

Kies Docker wanneer de service als image wordt gedistribueerd, één of twee expliciete apparaten of mounts nodig heeft en zonder --privileged, onbeperkte toegang tot de Docker-socket of brede hostnetwerken. Zet versies vast, laat capabilities vallen, gebruik waar mogelijk alleen-lezenbestandssystemen en houd persistente gegevens expliciet.

Kies een speciale onprivileged LXC wanneer

Kies LXC wanneer de service een vollediger Linux-omgeving, meerdere gerelateerde daemons, directe systemd-integratie of complexe rechten voor apparaatgroepen nodig heeft. Behoud user-namespace-toewijzing, houd AppArmor- en seccomp-beperkingen actief en documenteer elke host-mount en apparaattoewijzing.

Kies in plaats daarvan een VM wanneer

Gebruik een VM wanneer de workload controle nodig heeft die gelijkwaardig is aan host-rootrechten, ongebruikelijke stuurprogramma's laadt, andere workloads beheert, niet-vertrouwde openbare invoer accepteert of niet kan draaien zonder brede rechten voor bestandssysteem en netwerk. Een afzonderlijke kernel vormt een sterkere grens dan het toevoegen van meer uitzonderingen aan een container met een gedeelde kernel.

Veelgestelde vragen

Is een privileged LXC veiliger dan een privileged Docker-container?

Niet als algemene regel. Beide hebben belangrijke isolatiecontroles verzwakt, maar ze stellen bevoegdheden op verschillende manieren bloot. Beoordeel UID-toewijzing, apparaten, mounts, capabilities, netwerktoegang, AppArmor, seccomp en daemon-API's in plaats van te vertrouwen op het containerlabel.

Voegt Docker draaien binnen een onprivileged LXC een extra beveiligingslaag toe?

Dit kan UID-toewijzing tussen de LXC en de Proxmox-host toevoegen, maar geneste Docker-containers kunnen nestingfuncties, extra capabilities, uitzonderingen voor bestandssystemen of apparaattoewijzingen vereisen. Die wijzigingen kunnen het voordeel tenietdoen. Een VM is duidelijker wanneer sterke scheiding van de host vereist is.

Hebben uitsluitend op het LAN beschikbare thuisservices onprivileged containers nodig?

Ja, wanneer een compromittering kan binnenkomen via een ander apparaat op het LAN, een kwetsbare webinterface, schadelijke media- of documentinvoer, images uit de toeleveringsketen of blootgestelde inloggegevens. Plaatsing uitsluitend op het LAN beperkt een deel van de blootstelling, maar maakt toegang tot host-rootrechten niet ongevaarlijk.

Eindoordeel

Gebruik Docker wanneer een verpakte applicatie kan draaien met nauwkeurig gedeclareerde rechten en zonder administratieve hostinterfaces. Gebruik een onprivileged LXC wanneer een service een vollediger Linux-systeem nodig heeft, terwijl roottoewijzing en gecontroleerde toegang tot apparaten behouden blijven. Als een van beide ontwerpen brede host-rootrechten, onbeperkte sockets of schrijvende toegang tot kritieke gegevens vereist, stop dan met het vergelijken van containers en plaats de service achter een sterkere VM-grens of op een afzonderlijke machine.