Linux LXC vs FreeBSD fengsel

Uansett det fancy navnet som brukes her, begge er løsninger på et spesifikt problem: En bedre segregeringsløsning enn klassisk Unix chroot . Operativsystemnivå virtualisering, containere, soner eller til og med «chroot with steroids» er navn eller kommersielle titler som definerer det samme konseptet med brukerseparasjon, men med forskjellige funksjoner.

Chroot ble introdusert 18. mars 1982 , måneder før utgivelsen av 4.2 BSD , som et verktøy for å teste installasjons- og byggesystemet, men i dag har det fortsatt sine feil. Siden det første målet med chroot bare var å gi en newroot -bane, ble andre aspekter av systemet som måtte isoleres eller kontrolleres avdekket (nettverk, prosessvisning, I / O-gjennomstrømning). Det var her de første beholderne (virtualiseringsnivå på brukernivå) dukket opp.

Begge teknologiene (FreeBSD Jails og LXC) benytter seg av isolering av brukerområdet for å gi et nytt sikkerhetslag. Denne avdelingen vil sikre at en bestemt prosess kun kommuniserer med andre prosesser i samme container på samme vert, og hvis du bruker en nettverksressurs for å oppnå «utenfor verden» -kommunikasjon, vil alle bli videresendt til det tildelte grensesnittet / kanalen som denne containeren har.

Funksjoner

FreeBSD-fengsler:

• Anses som stabil teknologi, siden det er en funksjon i FreeBSD siden 4.0;
• Det tar det beste av ZFS-filsystem på det punktet hvor du kan klone fengsler og opprette fengselsmaler for enkelt å distribuere flere fengsler. Noe mer ZFS galskap ;
• Godt dokumentert , og under utvikling ;
• Hierarkiske fengsler lar deg lage fengsler inne i et fengsel (vi må gå dypere!). Kombiner med allow.mount.zfs for å oppnå mer kraft, og andre variabler som children.max definerer maksimalt barnefengsler.
• rctl (8) håndterer ressursbegrensninger for fengsler (minne, CPU, disk, …);
• FreeBSD-fengsler håndterer Linux brukerområde ;
• Nettverksisolasjon med vnet, slik at hver fengsel kan ha sin egen nettverksstabel, grensesnitt, adressering og ruting av tabeller;
• nullfs for å hjelpe til med å koble mapper til de som ligger på den virkelige serveren til et fengsel;
• ezjail verktøy for å hjelpe massedistribusjoner og styring av fengsler;
• Mange kjernefunksjoner (sysctl ). security.jail.allow.* -parametere vil begrense handlingene til rotbrukeren av det fengselet.
• Kanskje FreeBSD-fengsler utvider noen av VPS-prosjektets funksjoner som live migrasjon i en nær fremtid.
• Det er en viss innsats for ZFS og Docker integrering løping. Fortsatt eksperimentell.
• FreeBSD 12 støtter bhyve inne i et fengsel og pf inne i et fengsel, noe som skaper ytterligere isolasjon til disse verktøyene
• Mange interessante verktøy ble utviklet de siste årene. Noen av dem er indeksert på dette blogginnlegget .
• Alternativer: FreeBSD VPS-prosjekt

Linux Containers (LXC):

• Ny «i kernel» -teknologi, men blir godkjent av store (spesielt Canonical);
• Ikke-privilegerte containere fra LXC 1.0, gjør et stort skritt inn i sikkerhet i containere;
• UID- og GID-kartlegging inne i containere;
• Kjerne-navneområder, for å skille IPC, mount, pid, nettverk og brukere. Disse navneområdene kan håndteres på en løsrevet måte, der en prosess som bruker et et annet nettverksnavnområde ikke nødvendigvis blir isolert på andre aspekter som lagring;
• Kontrollgrupper (cgroups) for å administrere ressurser og gruppere dem. CGManager er fyren for å oppnå det.
• Apparmor / SELinux-profiler og kjernefunksjoner for bedre håndheving av kjernefunksjoner som er tilgjengelige med containere. Seccomp er også tilgjengelig på lxc-containere for å filtrere systemanrop. Andre sikkerhetsaspekter her .
• Live migrasjonsfunksjonalitet blir utviklet. Det er veldig vanskelig å si når den vil være klar til produksjonsbruk, siden docker / lxc må håndtere prosesspause i brukerområdet, øyeblikksbilde, migrering og konsolidering – ref1 , ref2 . Live migrasjon fungerer med grunnleggende containere (ingen enhetsgjennomgang verken komplekse nettverkstjenester eller spesielle lagringskonfigurasjoner).
• API-bindinger for å muliggjøre utvikling i python3 og 2, lua, Go, Ruby og Haskell
• Sentralisert «Hva er nytt» -området. Ganske nyttig når du trenger å sjekke om noe feil ble løst eller om en ny funksjon ble begått. Her .
• Et interessant alternativ kan være lxd , at det under panseret fungerer med lxc, men det har noen fine funksjoner som en REST-API, OpenStack-integrasjon osv.
• En annen interessant tingen er at Ubuntu ser ut til å sende zfs som standard filsystem for containere på 16.04 . For å holde prosjektene justert lanserte lxd den «2.0-versjonen, og noen av funksjonene er zfs relatert .
• Alternativer : OpenVZ , Docker
• Docker . Merk deg her at Docker bruker navnerom, cgroups som skaper «per app» / «per programvare» isolasjon Hovedforskjeller her . Mens LXC oppretter containere med flere prosesser, reduserer Docker en container så mye som mulig til en enkelt prosess, og administrerer den deretter gjennom Docker.
• Arbeid med å integrere Docker med SELinux og redusere kapasiteten i en container for å gjøre den sikrere – Docker og SELinux, Dan Walsh
• Hva er forskjellen mellom Docker, LXD og LXC

Docker bruker ikke lenger lxc. De har nå en spesifikk lib kalt runc som håndterer integreringen med lavt nivå Kernel navneområde og cgroups-funksjoner direkte.

Ingen av teknologiene er et sikkerhetsmiddel, men begge er ganske gode måter å isolere en miljø som ikke krever full virtualisering på grunn av blandet operativsysteminfrastruktur. Sikkerhet vil komme etter mye dokumentasjonslesing og implementering av kjernefunksjoner, MAC og isolasjoner som disse OS-Level virt tilbyr deg.

Se også:

• Håndlagde containere
• BSD nå: Alt du trenger å vite om fengsler
• ezjail – Rammeverk for fengselsadministrasjon
• En kort historie om containere: Fra 1970-tallet til 2017
• Docker anses som skadelig – God artikkel om sikkerhetssirkuset rundt containerteknologier.

Kommentarer

• Verdt å nevne at det ikke er noen innsats fra lxc for å gi riktig gjesteisolasjon. lxd prøver imidlertid å gi isolasjon som BSD-fengsler eller Solaris-soner.
• lxd er en " bedre opplevelse " av LXC, og legger andre funksjoner på toppen av den. Det virker imidlertid hyggelig å sitere denne lille fyren her
• @allquixotic du mener hvis du bruker uendret konfigurasjon opprettet fra maler? Det var sant, men uprivilegerte (brukeraktiverte) containere var tilgjengelige med LXC 1.x og kunne til og med startes automatisk ved systemstart, forutsatt at de var eid av root (og dermed ligger på hele systemet for containere).