NET_ADMIN i ein VPN-container: kva han kan endre og kvar

Kapabiliteten lèt deg endre grensesnitt, ruter og brannmur innanfor eitt nettverksnamnerom. Med vertsnettverk er dette namnerommet verten sin eigen stakk.

NET_ADMIN er Linux-kapabiliteten som lèt ein prosess utføre nettverksadministrasjon, og i ein container gjer han nett dette inne i det nettverksnamnerommet prosessen køyrer i. Han er ikkje ein lisens til å opne ein socket, og han er ikkje ein erstatning for eit apparat eller ei rute. Det interessante spørsmålet er aldri om kapabiliteten er gjeven, men kva namnerom som får endringa.

Kva kapabiliteten dekkjer

Inne i namnerommet sitt kan ein prosess med NET_ADMIN ta grensesnitt opp og ned, tildele adresser, leggje til og fjerne ruter og skrive brannmurreglar, som er gruppa av operasjonar som capabilities(7) samlar under denne kapabiliteten. Han kan òg justere innstillingar på grensesnittnivå som styrer korleis kjernen køar og filtrerer trafikk. Ein VPN-klient treng vanlegvis nokre få av desse ved oppstart og ingenting anna etterpå. Difor ber dei fleste images om større rekkjevidde enn dei brukar.

Operasjonar utanfor dette namnerommet er ikkje dekte, og tilstøytande privilegium er skilde. Lesing og skriving av råpakkar høyrer til NET_RAW, og oppretting av eit tun-apparat krev både kapabiliteten og tilgang til apparatnoden. Ein prosess utan apparatet får ein løyvefeil som ser ut som eit nettverksproblem og ikkje er det.

Namnerommet avgjer skadeomfanget

Ein container på sitt eige bru-nettverk når sitt eige loopback, sine eigne grensesnitt og si eiga rutetabell. Å gje NET_ADMIN der lèt VPN-klienten byggje ein tunnel utan å røre rutingsavgjerdene til verten, som er ordninga dei fleste container-images føreset.

Bytt den containeren til vertsnettverk, og den same tildelinga endrar no rutene til verten og brannmuren til verten, fordi det ikkje er noko separat namnerom att. Klienten som skulle styre éin tunnel kan då omdirigere trafikk for heile maskinen, og ein feil i nedrivingsskriptet etterlèt verten med reglar ingen har skrive. Ingenting i sjølve kapabiliteten endra seg; konteksten gjorde det. Difor oppfører den same compose-fila seg ulikt på to vertar.

Tre føresetnader som smeltar saman til éin

Oppstartsfeil i VPN-containerar involverer vanlegvis éin av tre skilde ting: kapabiliteten, tunneleininga og kjernestøtte for protokollen. Å gje alle tre på éin gong verkar, og det gjer òg den neste feilen umogleg å tilskrive. Eit minimalt compose-utdrag gjev kapabiliteten og sender einingknuten eksplisitt:

services:
  vpn:
    image: example/vpn-client:latest
    cap_add:
      - NET_ADMIN
    devices:
      - /dev/net/tun
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1

Les dokumentasjonen til imaget sjølv for kva sysctls det treng, fordi ein sysctl i ein container kan krevje eit ekstra privilegium eller ei innstilling på vertsnivå. Der imaget berre støttar brukarmodus, er det ikkje behov for noko apparat i det heile, og kapabilitetslista krympar tilsvarande.

Gje den smale operasjonen, ikkje modusen

Privilegert modus overleverer kvar kapabilitet og utvidar einingstilgangen samstundes, så det skjuler kva av dei tre føresetnadene som mangla. Det gjer òg feilmodusane til containeren umoglege å skilje frå endringar på verten. Føretrekk ei eksplisitt liste sjølv når ho er lengre å skrive.

Rootless- og brukarnamneromsutrullingar endrar kva ein kapabilitet tyder i praksis, sidan prosessen berre kan halde han inne i eit mappa namnerom. Å kopiere ei kapabilitetsliste frå eit rootful døme til eit rootless køyremiljø og vente same rekkjevidde er ein vanleg måte å miste ein ettermiddag.

Hemmelegheiter høyrer til ei eiga avgjerd. Å halde NET_ADMIN seier ingenting om kva peer-identitet klienten presenterer, kva legitimasjonar han lastar eller korleis dei blir roterte. Nettverksadministrasjon gjev ikkje tillit.

Stadfest endringa og noter kvifor tildelinga finst

Stadfest kva containeren faktisk fekk før du feilsøkjer tunnelen. Inspeksjonen nedanfor rapporterer dei tilførte kapabilitetane og nettverksmodusen, og viser deretter korleis grensesnittlista ser ut innanfrå:

docker inspect --format '{{.HostConfig.CapAdd}} {{.HostConfig.NetworkMode}} {{.HostConfig.Privileged}}' vpn
docker exec vpn sh -c 'grep CapEff /proc/self/status'
docker exec vpn ip -br addr
docker exec vpn ip route

Viss kapabiliteten er til stades og grensesnittlista framleis er tom, feila klienten før han kunne opprette noko, og containerloggane er den neste staden å sjå. Viss tunnelen finst men trafikken ikkje flyt, svarar rutetabellen inne i containeren på det neste spørsmålet.

Test òg nedrivingsvegen, fordi ein klient som skriv brannmurreglar kan etterlate dei. Stopp containeren og kontroller regelsettet til verten på nytt viss vertsnettverk blir brukt. Ei tildeling som berre trengst i to sekund ved oppstart, bør ikkje skildrast i compose-fila som eit permanent krav utan ei merknad som forklarer det.

Skriv årsaka ved sida av kvar kapabilitet: kva operasjon som trengde han og kva som feilar utan han. Den merknaden overlever image-oppdateringar, og han er skilnaden mellom ei gjennomgått privilegieliste og ei som har vakse ved kopiering og liming.

Relaterte artiklar