Docker-appcontainer kontra dedikerad LXC för privilegierade hemtjänster: vilket innebär större risk?
Välj en Docker-container med minsta möjliga privilegier när tjänsten distribueras som en avbild och bara behöver snävt mappade filer, portar, enheter och funktioner. Välj en dedikerad oprivilegierad LXC när tjänsten behöver en mer komplett Linux-miljö, direkt systemintegration eller flera relaterade processer under en separat hanterad gäst. Ingen av modellerna förblir en meningsfull säkerhetsgräns efter att du har exponerat breda värdkataloger, Docker-socketen, obegränsade enheter eller root-behörigheter på värdnivå.
Jämför motsvarande distributionsgränser först
Docker och LXC är båda Linux-containertekniker som delar värdens kernel, men de paketerar vanligtvis olika enheter. Docker isolerar normalt en enskild applikation eller en Compose-stack. LXC skapar en lättviktig systemcontainer med egna användare, paketdatabas, tjänster och operativsystemets filsystem.
Den rättvisa jämförelsen är därför en Docker-applikation som körs direkt på en Linux-värd jämfört med samma privilegierade hemtjänst installerad i en dedikerad LXC. Det handlar inte om Docker i LXC jämfört med LXC i sig, och inte heller om någon av containermodellerna jämfört med en virtuell maskin med en separat kernel.
Den befintliga ZimaSpace-jämförelsen av Docker och inbyggda installationer i LXC behandlar paketering och underhåll. Den här artikeln isolerar säkerhetsbeslutet när tjänsten begär privilegier som försvagar vanliga containergränser.
| Säkerhetsdimension | Docker-appcontainer | Dedikerad LXC-systemcontainer |
|---|---|---|
| Primär isoleringsenhet | Applikationsprocess och dess paketerade beroenden | Linux-användarutrymme med flera tjänster och användare |
| Värdens kernel | Delas med värden | Delas med värden |
| Root-mappning | Root-behörighet som standard om inte användarnamespaces eller rootless-läge används | Kan vara privilegierad eller mappa containerns root-användare till ett oprivilegierat UID på värden |
| Åtkomst till enheter | Enskilda enheter kan mappas; privilegierat läge exponerar enheter brett | Värdens enhetsnoder och behörigheter kan mappas in i gästen |
| Värdfiler | Bind-monteringar exponerar utvalda värdsökvägar direkt för appen | Bind-monteringar exponerar sökvägar för gästen och varje auktoriserad process inuti den |
| Administrativt API | Docker-socketen kan ge kontroll över Docker-värden | Ingen motsvarande daemon-socket om inte en annan runtime har installerats inuti LXC |
| Bäst lämpad | Paketerad app med strikt begränsade privilegier | Tjänst som behöver OS-integration inom en oprivilegierad gästgräns |
Börja med exakt de privilegier som tjänsten kräver
”Privilegierad hemmaservice” kan innebära flera orelaterade behörigheter: att läsa en seriell USB-enhet, använda en GPU-renderingsnod, styra ett nätverksgränssnitt, montera ett filsystem, binda en låg port, komma åt Bluetooth, läsa SMART-data eller hantera andra containrar. Dessa behörigheter medför inte samma risk för värden.
Bevilja minsta möjliga funktion, enhet, sökväg och nätverksläge som krävs för att tjänsten ska fungera. Snyks förklaring av privilegierat containerläge betonar att fullständig privilegierad åtkomst exponerar alla värdens enheter och nästan värdmotsvarande befogenheter. Det bör inte ersätta en utredning av den enda saknade behörigheten.
Om en tjänst bara behöver /dev/dri/renderD128, en seriell sökväg baserad på ID eller en skrivskyddad konfigurationskatalog kan både Docker och LXC exponera den begränsade resursen. Säkerhetsskillnaden blir betydelsefull när distributionen kräver breda funktioner eller flera kontaktytor mot värden.
Opriviligierad LXC skapar en starkare gräns för root-mappning
I en opriviligierad LXC mappas UID 0 inne i gästen till ett vanligt underordnat UID på Proxmox-värden. En process kan se ut att vara root inne i containern utan att ha värdidentiteten root utanför sin användarnamnsrymd. Detta minskar konsekvenserna av många misstag med filbehörigheter och vissa containerflykter.
Projektet Linux Containers beskriver mappningen av root i opriviligierad LXC som designens främsta säkerhetsgräns, där AppArmor, seccomp och funktioner lägger till ytterligare begränsningar för processer och värdresurser.
Fördelarna beror på att containern förblir opriviligierad. En privilegierad LXC använder inte samma UID-mappning, så root inne i gästen motsvarar mycket mer direkt root på värden. Att konvertera till privilegierat läge enbart för att förenkla monteringar eller enheter kan undanröja anledningen till att LXC verkade säkrare.
Docker kan minska root-risken utan att flytta programmet till LXC
Docker-containrar behöver inte köras med en root-daemon utan begränsningar och en root-användare för programmet. En containeravbildning kan ange en icke-root-användare, körmiljön kan ta bort funktioner, filsystem kan vara skrivskyddade och användarnamnrymder kan mappa om identiteter i containern.
Dockers rootless-läge kör både daemonen och containrarna utan rootbehörighet på värden. Detta kan minska riskerna med daemonen och körmiljön när applikationen och de lagrings- eller nätverksfunktioner som krävs stöder begränsningarna i rootless-läget.
Docker förblir den bättre avgränsningen när appen redan är väl paketerad och bara behöver en enda snävt definierad behörighet. Att flytta den till en fullständig LXC lägger till ytterligare ett operativsystem som måste patchas, utan att automatiskt minska den mappade resurs som den komprometterade applikationen har tillgång till.
Docker-socketen kan radera applikationsgränsen
Vissa instrumentpaneler, automatiska uppdaterare, säkerhetskopieringsverktyg och övervakningstjänster begär åtkomst till /var/run/docker.sock. Socketen gör det möjligt för en klient att instruera värdens Docker-daemon att skapa containrar, montera sökvägar på värden, exponera enheter och ändra nätverk. En komprometterad tjänst kan därför indirekt styra värden utan att utnyttja en kärnflykt.
Netdatas analys förklarar varför åtkomst till Docker-socketen fungerar som systemadministration: processen ber den privilegierade daemonen att utföra kraftfulla åtgärder på värden åt dess räkning utan en konventionell containerflykt.
Detta är den första avgränsningsgränsen. Om tjänsten kräver obegränsad åtkomst till Docker-socketen blir det missvisande att jämföra normal Docker-isolering med normal LXC-isolering. Behandla tjänsten som en systemadministratör, begränsa dess API genom en specialbyggd proxy om möjligt, isolera den från ej betrodda nätverk och skydda dess autentiseringsuppgifter därefter.
Enhetsmappning gynnar den modell som har färre behörighetslager
En GPU, USB-koordinator, TV-mottagare, Coral-accelerator, UPS eller seriell adapter kan skickas vidare till båda distributionsalternativen. Med direkt Docker exponerar värden enheten för applikationscontainern. Med LXC exponerar Proxmox enheten för systemcontainern, som sedan kör tjänsten direkt eller eventuellt skickar den vidare till inbäddad Docker.
Den dedikerade LXC-containern kan vara renare när flera relaterade processer behöver samma enhet och Linux-användare eller -grupper ska hantera åtkomsten. Docker kan vara renare när en avbild behöver en enhet och mappningen beskrivs direkt i Compose.
Undvik att ge någon av containrarna åtkomst till alla enheter bara för att behörigheten till en enskild enhet är svår att konfigurera. Proxmox noterar att LXC-säkerhet kombinerar namnrymder, AppArmor, seccomp och enhetsbegränsningar. Omfattande åtkomst till enheter tar bort en del av den lagerindelade gränsen, precis som privilegierat läge i Docker gör.
Värdens bindmonteringar överför risk på olika sätt
En Docker-bindmontering exponerar den valda värdsökvägen direkt för applikationen. En skrivbar montering som innehåller foton, säkerhetskopior, konfiguration eller tillståndsdata från andra applikationer ger en komprometterad container samma ändringsbehörigheter som den mappade värdanvändaren har till den sökvägen.
En LXC-bindmontering exponerar sökvägen för gästen, där flera tjänster och administratörsanvändare kan komma åt den enligt UID- och GID-mappningarna. Den extra systemgränsen kan bidra till att organisera behörigheter, men den utökar också mängden processer i gästen som kan nå data.
Använd skrivskyddade monteringar när det är möjligt, separera konfiguration från stora datamängder och undvik att mappa värdens rotkatalog, /proc, /sys, /dev, eller Docker-datakataloger i stor omfattning. Om tjänsten måste skriva om skyddade NAS-data kan applikationsisolering inte ersätta ögonblicksbilder och oberoende säkerhetskopior.
Nätverksprivilegier kan skapa en större skadeomfattning än åtkomst till filsystemet
Hemmatjänster som VPN-gateways, DNS-filter, verktyg för nätverksidentifiering, Home Assistant-integrationer och övervakningssystem kan begära värdnätverk, råa sockets, paketinsamling, ändringar av brandväggen eller åtkomst till flera VLAN. Dessa funktioner kan exponera trafik och låta tjänsten påverka andra enheter.
En Docker-container med värdnätverk förlorar separering på portnivå, medan ytterligare funktioner som NET_ADMIN eller NET_RAW öka vad en kompromettering kan göra. En LXC med ett eget virtuellt gränssnitt kan ge en separat adress och brandväggspolicy, men en privilegierad eller brett bryggad gäst kan fortfarande nå känsliga nätverk.
Välj den gräns som låter dig definiera den snävaste nätverksvägen. Ett separat VLAN, en dedikerad adress, uttryckliga brandväggsregler och ingen åtkomst till NAS-hanteringen minskar ofta risken mer än att byta containerteknik samtidigt som tjänsten lämnas på alla betrodda nätverk.
Privilegierad LXC och privilegierad Docker fallerar på olika sätt
En fullt privilegierad Docker-container får omfattande Linux-funktioner och åtkomst till enheter via en root-baserad Docker-daemon. En privilegierad LXC ger ett komplett gästutrymme en betydligt närmare identitetsrelation till värdens root-användare. Ingen av dem bör behandlas som en vanlig oprivilegierad applikationscontainer.
Tigeras säkerhetsvägledning varnar för att privilegierat Docker-läge kringgår viktiga isoleringskontroller. Diskussioner i Proxmox-communityn varnar på liknande sätt för att aktivering av nesting eller bred åtkomst till värdens filsystem i LXC kan exponera värdens /proc- och /sys-ytor när det konfigureras vårdslöst.
Om tjänsten verkligen kräver befogenheter motsvarande root på värden kan en VM med en dedikerad kärna ge en tydligare inneslutningsgräns. Den extra minnes- och lagringskostnaden kan motiveras när tjänsten är internetansluten, behandlar opålitlig indata, laddar kärnnära drivrutiner eller administrerar andra arbetslaster.
Uppdateringar och återställning avgör om isoleringen förblir användbar
Docker gör programpaketet utbytbart. Återskapa containern från en fastställd avbild eller digest, återställ konfigurationen och de beständiga data som behövs och tillämpa samma begränsade privilegier igen. Detta är värdefullt när säkerhetspolicyn framgår av Compose i stället för att vara något man minns från skalkommandon.
En dedikerad LXC gör driftmiljön utbytbar som en enda Proxmox-gäst. Dess paketdatabas, tjänstefiler, användare och enhetsmappningar kan säkerhetskopieras tillsammans. Återställningen blir ren när bind-monteringar, UID-mappningar, värdenheter och nätverksregler dokumenteras utanför gästen.
Jämförelsen från ZimaSpace av återställningsgränser för Docker-VM och LXC per app utgör det närliggande driftstestet. En mindre säkerhetsgräns är bara användbar om den kan återställas utan att breda privilegier måste återskapas manuellt.
Använd ett test för privilegiereduktion innan du väljer Docker eller LXC
- Lista varje enhet, värdsökväg, kapacitet, nätverk, API och kärnfunktion som tjänsten begär.
- Ta bort fullständigt privilegierat läge och lägg tillbaka ett krav i taget.
- Kör programmet som en icke-root-användare eller i en oprivilegierad LXC där det stöds.
- Ersätt breda skrivbara monteringar med begränsade skrivskyddade sökvägar eller sökvägar specifika för dataset.
- Ta bort åtkomsten till Docker-socketen eller placera en begränsad proxy mellan tjänsten och daemonen.
- Testa antaganden om intrång genom att verifiera vilka värdfiler, enheter och nätverk som fortfarande är nåbara.
- Återställ tjänsten på en ren Docker- eller LXC-värd med endast versionshanterad konfiguration.
Bedöm inte säkerheten enbart utifrån antalet lager. Bedöm de faktiska behörigheter som är tillgängliga efter att alla nödvändiga enheter, monteringar, funktioner, socketar och nätverk har lagts till. En enkel container med snäv åtkomst kan vara säkrare än en komplex kapslad konstruktion med flera undantag.
Vilken gräns passar den privilegierade hemmetjänsten?
Välj en Docker-appcontainer när
Välj Docker när tjänsten distribueras som en avbildning, behöver en eller två uttryckligen angivna enheter eller monteringar och kan köras utan --privileged, obegränsad åtkomst till Docker-socketen eller omfattande nätverk på värden. Lås versionerna, ta bort funktioner, använd skrivskyddade filsystem där det är möjligt och håll beständiga data explicit definierade.
Välj en dedikerad obehörig LXC när
Välj LXC när tjänsten behöver en mer komplett Linux-miljö, flera relaterade daemoner, direkt systemd-integration eller komplexa behörigheter för enhetsgrupper. Bevara mappningen för användarnamnrymden, behåll AppArmor- och seccomp-begränsningar och dokumentera varje montering på värden samt varje enhetsmappning.
Välj en VM i stället när
Välj en VM när arbetsbelastningen behöver kontroll motsvarande root på värden, laddar ovanliga drivrutiner, administrerar andra arbetsbelastningar, tar emot opålitlig offentlig indata eller inte kan köras utan omfattande filsystems- och nätverksbehörigheter. En separat kärna skapar en starkare gräns än att lägga till fler undantag i en container med delad kärna.
Vanliga frågor
Är en privilegierad LXC säkrare än en privilegierad Docker-container?
Inte som en generell regel. Båda har försvagat viktiga isoleringskontroller, men de exponerar privilegier på olika sätt. Utvärdera UID-mappning, enheter, monteringar, funktioner, nätverksåtkomst, AppArmor, seccomp och daemon-API:er i stället för att förlita dig på containeretiketten.
Lägger Docker i en obehörig LXC till ytterligare ett säkerhetslager?
Det kan lägga till UID-mappning mellan LXC-containern och Proxmox-värden, men kapslad Docker kan kräva nesting-funktioner, extra funktioner, undantag i filsystemet eller enhetsmappningar. Dessa ändringar kan motverka fördelen. En VM är tydligare när stark separering från värden krävs.
Behöver hemmetjänster som endast är tillgängliga via LAN obehöriga containrar?
Ja, när ett intrång kan komma via en annan LAN-enhet, ett sårbart webbgränssnitt, skadlig media eller dokumentindata, avbildningar från leveranskedjan eller exponerade inloggningsuppgifter. En placering som endast är tillgänglig via LAN minskar viss exponering, men gör inte åtkomst till värdens root ofarlig.
Slutligt omdöme
Använd Docker när en paketerad applikation kan köras med snävt deklarerade behörigheter och utan administrativa värdgränssnitt. Använd en obehörig LXC när en tjänst behöver ett mer komplett Linux-system samtidigt som rotmappning och kontrollerad enhetsåtkomst bevaras. Om någon av konstruktionerna kräver omfattande root-behörigheter på värden, obegränsade socketar eller skrivåtkomst till kritiska data ska du sluta jämföra containrar och placera tjänsten bakom en starkare VM-gräns eller på en separat maskin.
Rekommenderade produkter
Produktjämförelser
Mer att läsa
VPS-tunnel kontra portvidarebefordran hemma för offentliga egenhostade tjänster: Vilken inkommande väg är enklare att kontrollera?
Använd portvidarebefordran för den enklaste direkta vägen; använd en VPS-tunnel när CGNAT, adressintegritet, centraliserad inkommande trafik eller flyttbar routing är viktigt.
Konsumentrouter eller dedikerad brandvägg för ett segmenterat hemlabb: När bör du separera gatewayen?
Behåll konsumentroutern så länge segmenteringen är enkel; gå över till en dedikerad brandvägg när policyhantering, insyn, gränssnitt eller återställning överstiger dess kapacitet.
Layer 2-labb kontra routade VLAN: När bör gatewayen flyttas närmare kanten?
Behåll lager 2 så länge en gateway och några få trunkar förblir överskådliga; routa närmare kanten när VLAN-spännvidd, felomfattning och policy blir svårare att...
