augustus 30, 2020
Articles
Geen reacties

Linux LXC versus FreeBSD jail

Zijn er opmerkelijke verschillen tussen LXC (Linux-containers) en FreeBSD “s jails in termen van veiligheid, stabiliteit & prestaties?

Ten eerste kijk, beide benaderingen lijken erg op elkaar.

Reacties

  • LXC is een vrij nieuwe technologie, dus ik zou betere veiligheid en stabiliteit verwachten met jails. zelfs een gok over de prestaties. Er zijn enkele bekende beveiligingsproblemen met LXC die kunnen worden verholpen met bijvoorbeeld selinux. Persoonlijk vind ik LXC echter leuk.
  • @ PavelŠimerda Ik heb vandaag net van LXC gehoord, maar dat was ik verbaasd te ontdekken dat zowel Heroku als waarschijnlijk Google App Engine LXC al gebruiken.
  • Als je ' zojuist LXC bent tegengekomen, moet je Docker eens bekijken, gebruikt LXC onder de motorkap: docker.io/the_whole_story
  • Docker doet n ot gebruikt lxc niet meer.
  • @nwildner het ' gebruikt liblxc niet meer, maar het gebruikt exact dezelfde concepten: kernelnaamruimten.

Answer

Ongeacht de mooie naam die hier wordt gebruikt, beide zijn oplossingen voor een specifiek probleem: een betere oplossing voor scheiding dan de klassieke Unix chroot . Virtualisatie op besturingssysteemniveau, containers, zones of zelfs “chroot met steroïden” zijn namen of commerciële titels die hetzelfde concept van gebruikersruimtescheiding definiëren, maar met verschillende kenmerken.

Chroot werd geïntroduceerd op 18 maart 1982 , maanden voor de release van 4.2 BSD , als een hulpmiddel om de installatie en het bouwen van het systeem te testen, maar vandaag de dag heeft het nog steeds zijn gebreken. Aangezien het eerste doel van chroot alleen was om een newroot -pad te bieden, werden andere aspecten van het systeem die geïsoleerd of bestuurd moesten worden, blootgelegd (netwerk, procesweergave, I / O-doorvoer). Dit is waar de eerste containers (virtualisatie op gebruikersniveau) verschenen.

Beide technologieën (FreeBSD Jails en LXC) maken gebruik van gebruikersruimte-isolatie om een andere beveiligingslaag te bieden. Deze compartimentering zorgt ervoor dat een bepaald proces alleen communiceert met andere processen in dezelfde container op dezelfde host, en als een netwerkbron wordt gebruikt om communicatie met de buitenwereld tot stand te brengen, wordt alles doorgestuurd naar de toegewezen interface / kanaal dat deze container heeft.

Functies

FreeBSD Jails:

  • Beschouwd als stabiele technologie, aangezien het een functie is binnen FreeBSD sinds 4.0;
  • Het vereist het beste van het ZFS-bestandssysteem op het punt waar je jails zou kunnen klonen en gevangenissjablonen om gemakkelijk meer gevangenissen te implementeren. Nog wat ZFS-waanzin ;
  • Goed gedocumenteerd , en evolueert ;
  • Hiërarchische gevangenissen staan je toe om gevangenissen te creëren in een gevangenis (we moeten dieper gaan!). Combineer met allow.mount.zfs om meer kracht te krijgen, en andere variabelen zoals children.max definiëren het maximum aantal kindergevangenissen.
  • rctl (8) zal omgaan met resourcelimieten van jails (geheugen, CPU, schijf, …);
  • FreeBSD jails behandelen Linux gebruikersruimte ;
  • Netwerkisolatie met vnet, waardoor elke jail zijn eigen netwerkstack, interfaces, adressering en routering van tabellen;
  • nullfs om mappen te helpen koppelen aan mappen die zich op de echte server bevinden naar in een gevangenis;
  • ezjail hulpprogramma om massa-implementaties en beheer van jails te helpen;
  • Veel kernel-tunables (sysctl ). security.jail.allow.* parameters zullen de acties van de rootgebruiker van die jail beperken.
  • Misschien breiden FreeBSD jails enkele van de VPS-projectfuncties uit, zoals live migratie in de nabije toekomst.
  • Er is enige inspanning van ZFS en Docker integratie rennen. Nog steeds experimenteel.
  • FreeBSD 12 ondersteunt bhyve in een jail en pf in een jail, waardoor deze tools nog meer geïsoleerd worden.
  • Er zijn de afgelopen jaren veel interessante tools ontwikkeld. Sommigen van hen zijn geïndexeerd op dit blogbericht .
  • Alternatieven: FreeBSD VPS-project

Linux Containers (LXC):

  • Nieuwe “in kernel” -technologie maar ondersteund door grote (vooral Canonical);
  • Containers zonder privileges vanaf LXC 1.0, maakt een grote stap naar beveiliging in containers;
  • UID- en GID-mapping in containers;
  • Kernel-naamruimten, om IPC, mount, pid, netwerk en gebruikers te scheiden. Deze naamruimten kunnen op een aparte manier worden afgehandeld, waarbij een proces dat een andere netwerknaamruimte gebruikt, niet noodzakelijkerwijs geïsoleerd zal zijn voor andere aspecten, zoals opslag;
  • Stuurgroepen (cgroups) om bronnen te beheren en ze te groeperen. CGManager is de man om dat te bereiken.
  • Apparmor / SELinux-profielen en Kernel-mogelijkheden voor het beter afdwingen van Kernel-functies die toegankelijk zijn via containers. Seccomp is ook beschikbaar op lxc-containers om systeemoproepen te filteren. Andere beveiligingsaspecten hier .
  • Live migratiefunctie wordt ontwikkeld. Het is echt moeilijk te zeggen wanneer het klaar zal zijn voor productiegebruik, aangezien docker / lxc te maken zal hebben met het onderbreken, vastleggen, migreren en consolideren van gebruikersruimteprocessen – ref1 , ref2 . Live migratie werkt met standaardcontainers (geen apparaatdoorvoer noch complexe netwerkdiensten of speciale opslagconfiguraties).
  • API-bindingen om ontwikkeling mogelijk te maken in python3 en 2, lua, Go, Ruby en Haskell
  • Gecentraliseerd “Wat is er nieuw” gebied. Behoorlijk handig wanneer je moet controleren of een bug is verholpen of een nieuwe functie is vastgelegd. Hier .
  • Een interessant alternatief zou lxd , dat onder de motorkap werkt met lxc, maar het heeft een aantal leuke functies zoals een REST api, OpenStack-integratie, enz.
  • Nog een interessant ding is dat Ubuntu zfs lijkt te verzenden als het standaard bestandssysteem voor containers op 16.04 . Om projecten op één lijn te houden, lanceerde lxd zijn 2.0-versie, en enkele van de functies zijn zfs gerelateerd .
  • Alternatieven : OpenVZ , Docker
  • Docker . Houd er rekening mee dat Docker naamruimten gebruikt, cgroups die “per app” / “per software” -isolatie maken . Belangrijkste verschillen hier . Terwijl LXC containers met meerdere processen maakt, reduceert Docker een container zoveel mogelijk tot een enkel proces en beheert dat vervolgens via Docker.
  • Inspanning om Docker met SELinux te integreren en de mogelijkheden in een container te verminderen om het veiliger te maken – Docker en SELinux, Dan Walsh
  • Wat is het verschil tussen Docker, LXD en LXC

Docker gebruikt lxc niet meer. Ze hebben nu een specifieke bibliotheek genaamd runc die de integratie met low-level Kernel-naamruimte en cgroups-functies rechtstreeks afhandelt.

Geen van beide technologieën is een beveiligingswant, maar beide zijn redelijk goede manieren om een omgeving die geen volledige virtualisatie vereist vanwege de infrastructuur van gemengde besturingssystemen. Beveiliging zal komen na veel documentatie lezen en implementatie van kernel tunables, MAC en isolaties die die virt op OS-niveau je bieden.

Zie ook:

Reacties

  • Het is vermeldenswaard dat lxc out-of-the-box geen moeite doet om voor een goede gastisolatie te zorgen. lxd probeert echter isolatie te bieden, zoals BSD-jails of Solaris-zones.
  • lxd is een " betere ervaring " van LXC, door er andere functies bovenop te plaatsen. Het lijkt echter leuk om deze kleine man hier te citeren.
  • @allquixotic bedoel je als je een ongewijzigde configuratie gebruikt die is gemaakt op basis van sjablonen? Dat is waar, maar niet-geprivilegieerde (gebruikers-ingeschakelde) containers waren beschikbaar met LXC 1.x en konden zelfs automatisch worden gestart bij het opstarten van het systeem, op voorwaarde dat ze eigendom waren van root (en dus op de systeembrede locatie voor containers).

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *