Varnost zabojnikov: (Docker proti Podmanu brez korenin): Ali je izolacija absolutna?

5

0

Preberite 12 min.

Temeljne omejitve izolacije zabojnikov

Kontejnerizacija je postala prevladujoča metoda za pakiranje in dostavo aplikacij v oblaku in mikrostoritvenih arhitekturah. Kontejnerji omogočajo združevanje kode, knjižnic in odvisnosti, kar zagotavlja visoko prenosljivost in operativno učinkovitost.

Vendar je zaradi množične migracije kritičnih delovnih obremenitev v zabojnike odpornost mehanizmov izolacije temeljni problem. Raziskave in ankete med ekipami DevOps in varnostnimi ekipami vedno znova kažejo, da varnost zabojnikov ostaja ena glavnih skrbi: ranljivosti jedra in izvajalnega časa skupaj z napakami v konfiguraciji redno vodijo do dejanskih kršitev izolacije.

Ključno vprašanje je: ali je izolacija vsebnikov absolutna?

Odgovor je ne, razlog za to pa je v njihovi arhitekturi. V tem članku se bomo poglobili v to vprašanje in raziskali ukrepe, ki so na voljo za zmanjšanje tveganj ranljivosti.

Kontejnerji proti virtualnim strojem: skupno jedro

Virtualni stroj (VM):

• Vsak virtualni stroj uporablja svoje jedro operacijskega sistema, ki je popolnoma ločeno od gostitelja.

• Izolacijo zagotavlja hipervizor (KVM, Xen, ESXi itd.).

• Napad mora biti običajno usmerjen na hipervizor, kar bistveno zoži možnosti napada.

Kontejnerji:

• Kontejner je proces, izoliran z uporabo primitivov jedra Linuxa (imenski prostori, skupine cgroups itd.).

• Zabojnik ima samo uporabniški prostor (knjižnice, izvajalni čas, aplikacija), vendar si deli jedro z gostiteljem in drugimi zabojniki.

• Vsaka kritična ranljivost jedra samodejno postane potencialni vektor napada za vse vsebnike v vozlišču.

Zaradi arhitekturne izbire skupnega jedra je izolacija vsebnikov v osnovi neabsolutna: uspešno izkoriščanje ranljivosti jedra omogoča napadalcu, da obide meje katerega koli imenskega prostora.

Vloga imenskih prostorov in skupin C pri vzpostavljanju izolacije

Osnova za izolacijo vsebnikov v Linuxu so imenski prostori in skupine C.

• Prostori imen - Izolacija sistemskega pogleda: PID, Mount, Network, User, IPC, UTS in druge. Procesi "vidijo" samo svoj prostor: svoj datotečni sistem, svoj PID, svoje ime gostitelja in svoje omrežje.

• Skupine C - nadzor in omejevanje virov: CPU, pomnilnik, I/O, število procesov itd.

Prostori imen ustvarjajo iluzijo ločenega sistema, skupine S pa preprečujejo, da bi en vsebnik zasegel vire gostitelja. Vendar pa je ključno opozoriti, da so prostori imen mehanizem izolacije in ne polnopravni varnostni mehanizem proti namernemu izogibanju oviram. Ne preprečujejo izkoriščanja ranljivosti jedra, ne rešujejo težav s prevelikimi korenskimi privilegiji ali privilegiranimi vsebniki, ne filtrirajo sistemskih klicev in ne upravljajo politik dostopa.

Zato so imenski prostori in skupine zgolj osnovni sloj, ki ga je treba okrepiti:

1. filtriranje sistemskih klicev (Seccomp)

2. politikami MAC (AppArmor/SELinux)

3. omejitvami zmogljivosti

4. V idealnem primeru uporabniški prostori imen + način brez korena

Varnost kontejnerske platforme: kritične grožnje in vektorji napadov

Površina za napade na kontejnersko platformo je večplastna. Opredeljene so naslednje glavne površine:

• izvajalni čas in jedro (runc, containerd, CRI-O, jedro Linuxa).

• dobavna veriga slik.

• Konfiguracija zabojnikov in orkestratorjev.

• Oblak in infrastruktura (IAM, API, shranjevanje, omrežje).

Pregled vektorjev napada in kritičnih ranljivosti: Pobeg zabojnikov

Tipični vektorji v okolju vsebnikov vključujejo: izkoriščanje CVE v jedru Linuxa ali izvajalnem času vsebnika; uporabo nezanesljivih slik (zastareli paketi, kompleti za izkoriščanje); napake v konfiguraciji v Kubernetes/Docker (preveliki privilegiji, namestitev gostiteljskega datotečnega sistema, gostiteljski omrežni niz); ter kompromitiranje registrov in CI/CD.

Pomembno je razumeti, da je pobeg zabojnika pogosto kombinacija več dejavnikov:

ranljivost jedra/programa + slaba konfiguracija (zagon kot root, --privileged, namestitev datotečnega sistema gostitelja, manjkajoči MAC/Seccomp).

Ranljivosti dobavne verige

Dobavna veriga slik vsebnikov je eno glavnih tveganj, saj osnovne slike iz javnih registrov pogosto vsebujejo znane CVE. Odvisnosti (moduli pip/npm/gem/go) se vlečejo prehodno in niso vedno nadzorovane. Najnevarneje je, da lahko zlonamerna programska oprema "miruje" in se pokaže šele med izvajanjem.

Zato so v produkciji obvezne naslednje najboljše prakse:

• pregledovanje slik za CVE z orodji, kot so Trivy, Clair, Grype itd.

• uporaba registrov z izvajanjem, ki se zavedajo politik, kot so Harbor, Quay ali GHCR.

• Podpisovanje in preverjanje slik pred uporabo.

Napake v konfiguraciji in privilegirani vsebniki

Najpogostejša napaka, ki na široko odpira vrata ranljivostim, je izvajanje procesov znotraj vsebnika kot root! Če se aplikacija v vsebniku zažene s pravicami superuporabnika, napadalec ob kompromitaciji vsebnika pridobi root znotraj vsebnika. Uspešen pobeg zunaj vsebnika nato znatno poenostavi eskalacijo do korenskega korena gostitelja.

Prepoved zagona aplikacij kot root in uporaba neprivilegiranih UID/GID je osnovno pravilo pravilnega utrjevanja.

Privilegirani vsebniki z uporabo zastave --privileged praktično onemogočijo ključne mehanizme izolacije, zlasti nekatere skupine C, omejitve AppArmor/SELinux in Seccomp. To zabojniku omogoča neposreden dostop do gostiteljskih naprav in psevdofilamentov (/proc, /sys, /dev itd.). Iz privilegiranega vsebnika je mogoče enostavno priklopiti diske gostitelja ter spreminjati datotečni sistem in konfiguracije.

V bistvu je privilegirana posoda enakovredna namernemu povečanju privilegijev. Ne pozabite, da je to sprejemljivo le v redkih, dobro izoliranih scenarijih, nikakor pa ne v okolju z več najemniki.

Obstajajo tudi "tihe" napake v konfiguraciji, zaradi katerih je lahko okolje vsebnika zelo ranljivo, tudi brez uporabe oznake --privileged. Najnevarnejše so:

• Montaža hostPath v občutljive gostiteljske imenike, kot sta /etc ali /var/run/docker.sock.

• dodeljevanje nepotrebnih zmožnosti, na primer CAP_SYS_ADMIN, ki gostitelju praktično podeljuje pravice korena.

• Neupravičena uporaba načinov hostNetwork ali hostPID.

Te na videz nepomembne nastavitve lahko napadalcu omogočijo, da pobegne iz vsebnika in pridobi nadzor nad jedrom ali celotnim gostiteljskim sistemom.

Primerjava arhitekture: Docker proti Podmanu

Arhitekturne razlike med Dockerjem in Podmanom neposredno vplivajo na model groženj. Docker s svojim demonom z visokimi privilegiji predstavlja glavno tveganje: ena sama točka odpovedi.

Docker in način rootful

V klasični ali standardni arhitekturi Docker CLI programa Docker komunicira z demonom dockerd prek vtičnice /var/run/docker.sock ali TCP. Demon dockerd teče kot uporabnik root in izvaja osnovne operacije:

• Ustvarjanje/izbrisovanje vsebnikov

• ustvarjanje slik

• upravljanje omrežij/volumnov

• interakcija z registri

Iz tega sledi, da je neposreden dostop do vmesnika Docker API enakovreden skoraj popolnemu korenskemu dostopu do gostitelja, kar napadalcu omogoča priklop datotečnega sistema, zagon privilegiranih vsebnikov itd. V tem scenariju demon postane enotna točka odpovedi - če je ogrožen, napadalec pridobi dostop do gostitelja.

Zato Docker zahteva strog nadzor dostopa do vtičnice, obvezno omogočanje MAC in Seccomp ter omejevanje zmožnosti. Ključnega pomena je zmanjšanje števila uporabnikov in storitev z dostopom do vmesnika API Docker na najmanjšo možno mero.

Podman brez demonov: izvirni linuxni pristop

Podman so razvili družba Red Hat in skupnost kot varnejšo, "domačo" alternativo Linuxu. Prvotno je bil zasnovan z arhitekturo brez demonov, kar pomeni, da nima stalnega, centraliziranega demona. Namesto tega so vsebniki podrejeni procesi uporabnika, ki je zagnal ukaz. Temelj je globoka integracija s sistemom systemd, kjer se enote in storitve ustvarjajo neposredno.

S tem se odpravi enotna točka odpovedi, ki jo predstavlja korenski demon, in se bolje uskladi s tradicionalnim modelom Unix: "kdor je zagnal proces, je njegov lastnik".

Način brez korena: Prostori uporabniških imen kot glavna varnostna ovira

Način brez korena je v bistvu logičen odgovor na temeljno nevarnost: "Kaj pa, če se zabojnik razbije?"

Vloga prostorov uporabniških imen in zmanjševanje škode

Prostori uporabniških imen izolirajo UID/GID in omogočajo prestavljanje UID. Če ima na primer proces v vsebniku UID 0 (root), je ta isti proces preslikan na neprivilegiran UID iz območja subuid/subgid v gostitelju.

Zato tudi če ima napadalec v vsebniku pravice korporacije in mu uspe izkoristiti ranljivost v času izvajanja/jedru za prebeg na raven gostitelja, še naprej deluje kot neprivilegiran uporabnik na gostitelju.

Številne verige izkoriščanja, vključno z runc-escape, so tako prekinjene ali imajo bistveno manjši vpliv. Napadalec namreč ne more prepisati binarnih datotek/konfiguracij, ki so v lasti korenskega uporabnika, ne more montirati datotečnih sistemov ali upravljati naprav brez zmogljivosti, politike MAC pa še naprej delujejo tudi v gostitelju.

Podman brez korenin: Omejitve in omrežni sklad

Podman je bil od začetka zasnovan s poudarkom na operacijah brez korena. Kontejnerje ustvarja in upravlja neprivilegirani uporabnik, uporabniški imenski prostori so privzeto omogočeni, sistemi SELinux/AppArmor in Cgroups pa se v največji možni meri uporabljajo brez korenskega dostopa.

Vendar je v tej shemi nekaj kompromisov. Kadar vsebnik brez korena deluje v območju subuid/subgid, so možne napake pri preslikavi, če slika vsebuje datoteke z vrednostmi UID/GID, ki ne spadajo v to območje.

Druga posredna pomanjkljivost je, da neprivilegirani uporabnik ne more prosto konfigurirati omrežnih imenskih prostorov. Od začetka leta 2025 Podman uporablja testenine uporabniškega prostora kot zamenjavo za slirp4netns. Ta vtičnik v celoti deluje v uporabniškem prostoru, vendar zaradi vmesnika tap in spajanja brez kopij zagotavlja skorajda nativno omrežno zmogljivost. Kljub temu so upočasnitve zmogljivosti še vedno možne in so vsekakor zagotovljene, če uporabniki še naprej uporabljajo slirp4netns.

Docker brez korenin: izvajanje in zahteve

Docker podpira tudi polnopravni način brez korena, v katerem se demon dockerd in vsebniki zaženejo znotraj uporabniškega imenskega prostora brez privilegijev korenskega uporabnika gostitelja. Pomembno je, da se to razlikuje od starejše funkcije userns-remap, kjer je demon sam ostal privilegiran.

Z varnostnega vidika to zagotavlja, da kršitev kontejnerja ne bo povzročila samodejnega povišanja na raven korenskega uporabnika gostitelja. V primeru uspešnega napada na dockerd v načinu brez korenskega uporabnika bodo dostopna le sredstva neprivilegiranega uporabnika, ne pa celotnega sistema.

Izbira med načinoma rootful in rootless je predvsem ravnovesje med čim večjo zmogljivostjo in čim večjo omejitvijo morebitne škode v primeru vdora.

Zaključki in priporočila za okrepitev

Analiza potrjuje, da izolacija vsebnikov zaradi njihove arhitekture ni absolutna. Ker si vsebniki delijo jedro gostiteljskega sistema, lahko ranljivosti na ravni jedra ali izvajalnega časa po definiciji "vidijo" prek imenskih prostorov in tako kršijo pričakovane varnostne meje.

V praksi je večina uspešnih napadov povezana s kombinacijo znane ranljivosti (kernel/runc) in šibke konfiguracije (root, --privileged, hostPath).

Zanesljiv varnostni model zabojnikov mora biti zgrajen kot večplastni sistem:

plast 1 - Segmentacija: (imenski prostori, cgroups)

plast 2 - politike in filtriranje: (Seccomp, MAC, zmogljivosti)

plast 3 - arhitekturno omejevanje privilegijev: (prek načina brez korena in prostorov uporabniških imen)

Kontrolni seznam: okrepitev gostitelja za vsebnike Docker in Podman

Privzeto brez korena

Podman ali Docker v načinu brez korena upoštevajte kot privzeti model za notranje in večnajemniške delovne obremenitve.

Okrepitev in popravljanje jedra

Takoj posodobite jedro (težave Dirty COW, Dirty Pipe in podobne CVE so skoraj vedno že odpravljene s popravki). Uporabljajte distribucije z dobro zgodovino varnostnih popravkov (RHEL, OpenSUSE, Ubuntu LTS itd.).

Sprejemanje specializiranih nespremenljivih distribucij operacijskih sistemov

Če želite povečati varnost okolja zabojnikov, uporabljajte distribucije nespremenljivih operacijskih sistemov, kot sta openSUSE MicroOS ali Flatcar Linux. Njihov korenski datotečni sistem je privzeto namenjen samo branju, kar znatno zmanjša površino za napade. Ključni mehanizem so atomske posodobitve: ustvari se nova slika operacijskega sistema, posodobitev pa se uporabi v celoti ali pa se v celoti umakne, kar preprečuje poškodbe sistema in pospešuje obnovitev.

Načelo najmanjšega privilegija

Nikoli ne uporabljajte zastave --privileged v produkciji, razen v zelo specializiranih in izoliranih okoljih. Izogibajte se zagonu aplikacij v vsebnikih kot uporabnik root in uporabljajte datotečni sistem samo za branje, minimalni nabor zmožnosti in stroge profile Seccomp.

Politike MAC in Seccomp

Omogočite in konfigurirajte SELinux\AppArmor za vsebnike. Uporabite profile Seccomp, najbolje po meri, ki temeljijo na dejanskih sistemskih klicih aplikacije in ne le na privzetih nastavitvah programa Docker.

Varnost dobavne verige

Izvedite skeniranje slik zabojnikov. Omejite vire osnovnih slik na uradne ali notranje registre ter omogočite podpisovanje in preverjanje slik pred namestitvijo.

Spremljanje izvajanja

Uporabite orodja za odkrivanje anomalij in IDS/EDR za vsebnike (Falco, Sysdig Secure ali Aqua Security), ki lahko zaznajo poskuse pobega vsebnika in spremljajo izvajanje zlonamernih ukazov. Spremljajte netipičen omrežni promet, nepričakovane sistemske klice in dostop do občutljivih datotek.

Prihodnost izolacije: Izolacija: vsebniki Kata, gVisor in mikro-VM

Način brez korenin bistveno zmanjša tveganje popolne kompromitacije gostitelja, vendar ne reši vsega, saj odvisnosti od jedra gostitelja ostanejo, nekateri razredi napadov pa niso odpravljeni.

Zato so pri kritičnih delovnih obremenitvah vse bolj priljubljeni hibridni pristopi:

• Kata Containers: Vsak pod ali vsebnik se zažene znotraj lahkega mikro-VM z ločenim jedrom, kar združuje prednosti virtualnih računalnikov in vsebnikov.

• gVisor: VVisor: jedro peskovnika, napisano v Go, ki deluje kot vmesni sloj med aplikacijo in pravim jedrom Linuxa.

Te rešitve zmanjšujejo odvisnost od skupnega jedra in nas približujejo modelu izolacije VM, hkrati pa ohranjajo deklarativno naravo in priročnost orkestratorjev vsebnikov.

Smernice iz tega prispevka spremenite v resnično varnost pri naslednji namestitvi.

Zagotovite si VPS ali namenski strežnik in še danes vzpostavite varno platformo za zabojnike.

Nadaljujte z izbiro konfiguracije.

Nove objave:

Docker proti Podmanu: Podman: Popolni vodnik po kontejnerizaciji brez demonov: Podman: Podman: Popolni vodnik po kontejnerizaciji brez demonov