NET_ADMIN in 'n VPN-houer: wat dit kan verander en waar

Die vermoë laat veranderinge aan koppelvlakke, roetes en die vuurmuur toe binne een netwerknaamruimte. Met gasheernetwerk is daardie naamruimte die gasheer se eie stok.

NET_ADMIN is die Linux-vermoë wat 'n proses toelaat om netwerkadministrasie te doen, en in 'n houer doen dit presies dit binne watter netwerknaamruimte die proses ook al loop. Dit is nie 'n lisensie om 'n socket oop te maak nie, en dit is nie 'n plaasvervanger vir 'n toestel of 'n roete nie. Die interessante vraag is nooit of die vermoë toegestaan is nie, maar watter naamruimte die verandering ontvang.

Wat die vermoë dek

Binne sy naamruimte kan 'n proses met NET_ADMIN koppelvlakke op en af bring, adresse toeken, roetes byvoeg en verwyder, en vuurmuurreëls skryf, wat die groep bewerkings is wat capabilities(7) onder hierdie vermoë versamel. Dit kan ook instellings op koppelvlakvlak aanpas wat bepaal hoe die kern verkeer in die ry plaas en filtreer. 'n VPN-kliënt het gewoonlik 'n paar daarvan nodig by die opstart en niks anders daarna nie. Die meeste beelde vra dus meer bereik as wat hulle gebruik.

Bewerkings buite daardie naamruimte word nie gedek nie, en aangrensende voorregte is apart. Lees en skryf van rou pakkette hoort by NET_RAW, en die skep van 'n tun-toestel benodig beide die vermoë en toegang tot die toestelknoop. 'n Proses sonder die toestel kry 'n toestemmingsfout wat soos 'n netwerkprobleem lyk en nie een is nie.

Die naamruimte bepaal die skadeomvang

'n Houer op sy eie brugnetwerk bereik sy eie loopback, sy eie koppelvlakke en sy eie roetertabel. Om NET_ADMIN daar toe te ken, laat die VPN-kliënt 'n tonnel bou sonder om die gasheer se roetebesluite aan te raak, wat die reëling is wat die meeste houerbeelde aanneem.

Skakel daardie houer na gasheernetwerk en dieselfde toekenning wysig nou die gasheer se roetes en die gasheer se vuurmuur, want daar is geen aparte naamruimte oor nie. Die kliënt wat veronderstel was om een tonnel te bestuur, kan dan verkeer vir die hele masjien herlei, en 'n fout in sy afbreekteks laat die gasheer met reëls wat niemand geskryf het nie. Niks in die vermoë self het verander nie; die konteks het. Dit is waarom dieselfde compose-lêer anders op twee gashere optree.

Drie voorvereistes wat in een saamgevoeg word

Opstartfoute in VPN-houers behels gewoonlik een van drie aparte dinge: die vermoë, die tonnestoestel en kernondersteuning vir die protokol. Om al drie gelyk toe te ken werk, en dit maak die volgende fout ook onmoontlik om toe te skryf. 'n Minimale compose-fragment ken die vermoë toe en gee die toestelknoop eksplisiet deur:

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

Lees die beeld se eie dokumentasie vir watter sysctls dit nodig het, want 'n sysctl in 'n houer kan 'n bykomende voorreg of 'n instelling op gasheervlak vereis. Waar die beeld slegs-gebruikersruimte-modus ondersteun, is geen toestel hoegenaamd nodig nie en krimp die vermoëlys dienooreenkomstig.

Ken die eng bewerking toe, nie die modus nie

Bevoorregte modus gee elke vermoë oor en verbreed terselfdertyd toesteltoegang, so dit verberg watter van die drie voorvereistes ontbreek het. Dit maak ook die houer se foutmodusse nie van gasheerwysigings te onderskei nie. Verkies 'n eksplisiete lys selfs wanneer dit langer is om te skryf.

Rootless en gebruikersnaamruimte-ontplooiings verander wat 'n vermoë in die praktyk beteken, want die proses mag dit net binne 'n gekarteerde naamruimte hou. Om 'n vermoëlys van 'n rootful-voorbeeld na 'n rootless-tydloop te kopieer en dieselfde bereik te verwag, is 'n algemene manier om 'n middag te verloor.

Geheime hoort in 'n aparte besluit. Om NET_ADMIN te hou sê niks oor watter eweknie-identiteit die kliënt voorhou, watter geloofsbriewe dit laai, of hoe dit geroteer word nie. Netwerkadministrasie verskaf nie vertroue nie.

Verifieer die verandering en teken aan waarom die toekenning bestaan

Bevestig wat die houer werklik ontvang het voordat jy die tonnel ontfout. Die inspeksie hieronder rapporteer die bygevoegde vermoëns en die netwerkmodus, en wys dan hoe die koppelvlaklys van binne lyk:

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

As die vermoë teenwoordig is en die koppelvlaklys steeds leeg is, het die kliënt gefaal voordat dit iets kon skep, en die houerlogboeke is die volgende plek om te kyk. As die tonnel bestaan maar verkeer nie vloei nie, antwoord die roetertabel binne die houer die volgende vraag.

Toets ook die afbreekpad, want 'n kliënt wat vuurmuurreëls skryf, kan hulle agterlaat. Stop die houer en herkontroleer die gasheer se reëlstel as gasheernetwerk in gebruik is. 'n Toekenning wat net twee sekondes by die opstart nodig is, moet nie in die compose-lêer as 'n permanente vereiste beskryf word sonder 'n nota wat dit verduidelik nie.

Skryf die rede langs elke vermoë: watter bewerking dit nodig gehad het en wat sonder dit faal. Daardie nota oorleef beeldopdaterings, en dit is die verskil tussen 'n nagegane voorreglys en een wat deur kopieer-en-plak gegroei het.

Verwante artikels