Docker versus LXC-beveiligingsgrenzen voor geprivilegieerde thuisservices

Docker is de veiligere standaard wanneer een geprivilegieerde thuisservice één gedeclareerde applicatie kan blijven met beperkte mounts. LXC is overzichtelijker wanneer de service echt een klein Linux-systeem nodig heeft, maar geen van beide creëert een afzonderlijke kernelgrens.

De doorslaggevende kwestie is niet welk label geïsoleerder klinkt. Beide zijn afhankelijk van insluiting via de hostkernel. Vergelijk de daadwerkelijk verleende rechten, de blootgestelde apparaten en bestanden, de eenheid die je patcht en herstelt, en de gevolgen van een ontsnapping. Als blootstelling aan een gedeelde kernel zelf onaanvaardbaar is, stop dan met het vergelijken van Docker en LXC en gebruik een VM of afzonderlijke host.

Accepteer de grens van de gedeelde kernel voordat je functies vergelijkt

Docker verpakt normaal gesproken een applicatie en de bijbehorende afhankelijkheden; LXC biedt een completere Linux-userspace met init, accounts, pakketten en systeemservices. Dat operationele verschil geeft LXC geen onafhankelijke gastkernel.

Onderzoek naar containerinsluiting in Linux beschrijft namespace- en beleidsmechanismen als een lappendeken waarvan de semantiek moeilijk te controleren kan zijn. Die beperking van insluiting via een gedeelde kernel geldt voor beide kandidaten en voorkomt dat een van beide het antwoord is wanneer kernelscheiding verplicht is.

Houd beide alleen in de race voor vertrouwde of afgebakende workloads. Verplaats code die vanaf internet bereikbaar is, onbekende images of automatisering met grote gevolgen naar een VM wanneer een inbreuk niet rechtstreeks de hostkernel mag bereiken.

Laat de vereiste rechten de standaard bepalen

Docker blijft aantrekkelijk wanneer de service enkele expliciete capabilities, alleen-lezenconfiguratie en een of twee persistente paden nodig heeft. De Compose-definitie kan deze uitzonderingen zichtbaar maken tijdens een beoordeling.

LXC past bij services die een conventioneel Linux-systeem, meerdere daemons, een pakketbeheerder of stabiele netwerkconfiguratie op systeemniveau verwachten. Unprivileged LXC behoudt nuttige UID-mapping, maar de privileged-modus, nesting en brede bind mounts doen dat voordeel teniet.

Tel uitzonderingen in plaats van simpelweg een vinkje voor geprivilegieerde toegang te zetten. Als een van beide ontwerpen hostnetwerken, de containerbeheersocket, beschrijfbare systeemmounts, elk apparaat of een onbeperkt profiel nodig heeft, ontwerp dan de toegang opnieuw of verlaat de gedeelde-kernel-laag.

Toegang tot apparaten en opslag bepaalt de omvang van de schade

Een USB-coördinator, GPU-rendernode, UPS-interface of mediadirectory moet zo beperkt mogelijk worden blootgesteld, binnen wat de service toestaat. Stabiele apparaatpaden, alleen-lezenmounts en expliciet UID/GID-eigenaarschap zijn zowel insluitingsmaatregelen als handige instellingen.

Een recent implementatieverslag van Proxmox laat zien dat unprivileged LXC Docker-services kan isoleren in afzonderlijke herstelbare eenheden, terwijl de hostkernel en opslagstack worden gedeeld. Dit LXC-patroon met een beperkte schadeomvang is alleen nuttig wanneer uitzonderingen voor nesting en opslagdrivers gedocumenteerd blijven.

Geef de voorkeur aan Docker wanneer één app één kleine gegevensgrens nodig heeft. Geef de voorkeur aan LXC wanneer meerdere systeemservices bij elkaar horen. Wijs beide indelingen af als één inbreuk beschrijfbare toegang geeft tot back-ups, hypervisorbeheer of niet-gerelateerde gezinsgegevens.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Vergelijk de eenheid die je patcht en herstelt

Terugdraaien met Docker betekent normaal gesproken het herstellen van de vorige Compose-revisie en image, samen met applicatieconsistente gegevens. Met LXC kun je een volledige userspace herstellen, wat handig is, maar mogelijk ook verouderde pakketten, inloggegevens en verborgen handmatige wijzigingen terugbrengt.

Maak elke kandidaat opnieuw op een wegwerpbare host. Herstel voor Docker de definities, secrets en volumes; maak voor LXC de container opnieuw aan of herstel deze en controleer de status van pakketten, netwerk, apparaten en mounts. Een eenvoudigere geslaagde test levert sterker bewijs dan een lager geheugengebruik in rust.

De bredere ZimaSpace-beslissing over grenzen voor VM-, LXC- en Docker-services is de volgende stap wanneer een onafhankelijke kernel nog steeds wordt overwogen.

Voorwaardelijk oordeel: kies de smalste grens die een fout nog steeds binnen de perken houdt

Kies Docker voor één goed verpakte, vertrouwde applicatie waarvan de apparaten, capabilities, secrets en persistente paden expliciet en minimaal kunnen blijven.

Kies LXC voor een vertrouwde Linux-serviceomgeving die daadwerkelijk baat heeft bij init, pakketten, meerdere daemons of netwerken op systeemniveau, en gebruik de unprivileged-modus waar mogelijk.

Kies geen van beide wanneer de workload brede controle over de host nodig heeft, invoer van mogelijk kwaadwillenden verwerkt met grote gevolgen, of een compromittering van de hostkernel moet kunnen overleven. Een VM of afzonderlijke machine is dan geen overengineering; het is de ontbrekende beveiligingsgrens.