Säkerhetsgränser för privilegierade hemtjänster: Docker kontra LXC

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Docker är det säkrare standardvalet när en privilegierad hemmaservice kan förbli en deklarerad applikation med begränsade monteringar. LXC är renare när den faktiskt behöver ett litet Linux-system, men ingen av dem skapar en separat kärngräns.

Den avgörande frågan är inte vilken etikett som låter mest isolerad. Båda förlitar sig på begränsning via värdkärnan. Jämför de privilegier som faktiskt beviljas, de enheter och filer som exponeras, den enhet du patchar och återställer samt konsekvensen av ett intrång. Om exponering mot en delad kärna i sig är oacceptabel, sluta jämföra Docker och LXC och använd en virtuell maskin eller en separat värd.

Acceptera gränsen med den delade kärnan innan du jämför funktioner

Docker paketerar normalt en applikation och dess beroenden, medan LXC tillhandahåller en mer komplett Linux-användarmiljö med init, konton, paket och systemtjänster. Den operativa skillnaden ger inte LXC en oberoende gästkärna.

Forskning om begränsning av Linux-containrar beskriver namnrymder och policy-mekanismer som ett lapptäcke vars semantik kan vara svår att granska. Denna begränsning hos delad kärna gäller båda alternativen och innebär att inget av dem är lösningen när kärnseparation är obligatorisk.

Behåll båda som alternativ endast för betrodda eller begränsade arbetslaster. Flytta internetexponerad kod, okända avbildningar eller automatisering med stora konsekvenser till en virtuell maskin när ett intrång inte får nå värdkärnan direkt.

Låt det nödvändiga privilegiet ändra standardvalet

Docker är fortfarande attraktivt när tjänsten behöver några få uttryckliga funktioner, skrivskyddad konfiguration och en eller två beständiga sökvägar. Dess Compose-definition kan göra dessa undantag synliga vid granskning.

LXC passar tjänster som förväntar sig ett konventionellt Linux-system, flera daemoner, en pakethanterare eller stabil nätverkshantering på systemnivå. Oprivilegierad LXC bevarar användbar UID-mappning, men privilegierat läge, nästling och breda bind-monteringar urholkar den fördelen.

Räkna undantag i stället för att markera en kryssruta för privilegier. Om någon av lösningarna behöver värdnätverk, containermanagement-socketen, skrivbara systemmonteringar, alla enheter eller en obegränsad profil, gör om åtkomstvägen eller lämna nivån med delad kärna.

Åtkomst till enheter och lagring avgör skadeomfattningen

En USB-koordinator, GPU-renderingsnod, UPS-gränssnitt eller mediekatalog bör exponeras så snävt som tjänsten tillåter. Stabila enhetssökvägar, skrivskyddade monteringar och uttryckligt UID/GID-ägarskap är både begränsningskontroller och praktiska inställningar.

En aktuell redogörelse för en Proxmox-distribution visar att oprivilegierad LXC kan isolera Docker-baserade tjänster i separata återställningsenheter och samtidigt dela värdkärnan och lagringsstacken. Detta LXC-mönster med liten skadeomfattning är endast användbart när undantag för nästling och lagringsdrivrutiner förblir dokumenterade.

Föredra Docker när en app behöver en liten dataavgränsning. Föredra LXC när flera systemtjänster hör ihop. Avvisa båda uppläggen om ett enda intrång ger skrivåtkomst till säkerhetskopior, hypervisorkontroll eller orelaterad familjedata.

-15% OFF
Single board computer zimaboard2

Jämför den enhet du patchar och återställer

Återställning i Docker innebär normalt att återställa den föregående Compose-versionen och avbildningen samt applikationskonsistenta data. Återställning i LXC kan återställa en hel användarmiljö, vilket är bekvämt men också kan återinföra föråldrade paket, autentiseringsuppgifter och dolda manuella ändringar.

Bygg om varje alternativ på en tillfällig värd. För Docker återställer du definitioner, hemligheter och volymer; för LXC återskapar eller återställer du containern och verifierar paket-, nätverks-, enhets- och monteringsstatus. Det enklare lyckade testet är starkare bevis än lägre minnesanvändning i viloläge.

Det bredare ZimaSpace-beslutet om gränser för VM-, LXC- och Docker-tjänster är nästa steg när en oberoende kärna fortfarande övervägs.

Villkorad slutsats: välj den snävaste gräns som fortfarande begränsar felet

Välj Docker för en väl paketerad, betrodd applikation där enheter, funktioner, hemligheter och beständiga sökvägar kan förbli uttryckliga och minimala.

Välj LXC för en betrodd Linux-tjänstemiljö som faktiskt drar nytta av init, paket, flera daemoner eller nätverkshantering på systemnivå, och håll den oprivilegierad där det är möjligt.

Välj inget av alternativen när arbetslasten behöver bred kontroll över värden, hanterar fientliga indata med stora konsekvenser eller måste överleva en komprometterad värdkärna. Då är en virtuell maskin eller en separat dator inte överdriven ingenjörskonst; det är den säkerhetsgräns som saknas.

Produktjämförelser

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.