Ein VPN-daemon treng privilegerte nettverksoperasjonar sjølv om vanlege program opnar utgåande socketar heilt utan privilegium. Det er i dette gapet dei fleste kapabilitetsfeil startar: nokon ser ein tilgangsfeil, gir heile settet, og tenesta verkar av grunnar ingen seinare kan forklare. Gjennomgangen nedanfor startar ved operasjonen som feila, knyter han til éi myndigheit og sjekkar deretter konteksten prosessen faktisk køyrer i. Å køyre som ubegrensa root er eit gyldig svar for nokre utrullingar, men det bør vere eit vedtak og ikkje ein standard.

Start ved operasjonen som feila

Les feilen før du les ei rettleiing. «Operasjonen er ikkje tillaten» ved ei grensesnittendring, ei avvising av å opne ein einheitsnode og ein bind-feil på ein låg port er tre ulike problem med tre ulike tildelingar. Viss prosessen startar og berre feilar ved den første ruteendringa, fortel det òg at grensesnittet alt er oppretta, noko som snevrar svaret mykje inn.

Gjenskap feilen med tenesta stoppa, og start henne deretter i forgrunnen under same brukar viss implementasjonen tillèt det. Ein feil du kan sjå, er betre enn ei loggline du må gjette deg til, og han gjer skilnaden mellom eit kapabilitetsproblem og ei avvising frå SELinux eller AppArmor tydeleg.

Knyt kvar operasjon til éi myndigheit

Tabellen er eit startkart, ikkje ei erstatning for dokumentasjonen til implementasjonen:

OperationUsual authorityWatch for
Create or configure tun/tapCAP_NET_ADMIN in the relevant namespaceCreating the device and opening it are separate steps
Add routes, rules, firewall entriesCAP_NET_ADMINSame capability, different namespace than you think
Open /dev/net/tunDevice permissions, not a capabilityGroup membership or a udev rule may be enough
Raw socketsCAP_NET_RAWNeeded by some user-space tunnel implementations
Bind a port below 1024CAP_NET_BIND_SERVICEIrrelevant for most modern tunnel ports

Dei to radene i tabellen er dei folk blandar saman. Å opne /dev/net/tun er eit spørsmål om filrettar; å be kjernen konfigurere det du opna, er eit spørsmål om kapabilitetar. Tildeling av CAP_NET_ADMIN rettar ikkje ein einheitsnode tenestebrukaren din ikkje kan lese, og å rette noden gir deg ikkje ruterett. Sjekk begge før du endrar nokon av dei.

WireGuard i kjernen og tunnelprogram i brukarrommet har heller ikkje identiske krav. Kjernemodulvegen konfigurerer eit eksisterande grensesnitt via netlink, medan ein implementasjon i brukarrommet òg kan trenge eininga og, for nokre transportlag, rå socketar.

Les konteksten: teneste, container eller skal

Ein kapabilitet i nettverksnamnerommet til vertsmaskina kan påverke langt meir enn den same operasjonen i ein medvite isolert stabel. Eit container-runtime startar vanlegvis med eit redusert grensesett; å leggje NET_ADMIN til ein container som deler nettverket til verten er ei langt større tildeling enn å leggje det til ein med eige nettverksnamnerom og utan vertsmontasjar.

For systemd-einingar bør du lese kva som faktisk vert nytta, ikkje kva einingafila ser ut til å seie: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities rapporterer dei effektive verdiane, som kan vere sette av ein drop-in du har gløymt. Spør etter den effektive verdien, aldri den tiltenkte. Ambient-kapabilitetar har mykje å seie fordi ei teneste utan root misser kapabilitetar gjennom exec utan dei.

Bruk den støtta oppsetnaden til pakken eller imaged som utgangspunkt. Ikkje legg til rå-socket-løyve eller privilegert modus fordi ei anna rettleiing lista dei for eit anna verktøy; den grunngivinga overfører ingenting og kostar deg isolasjonen du betalte for. Er du i tvil, gi ingenting og les implementasjonsnotata for den nøyaktige operasjonen du treng.

Sjå kva som skjer etter at privilegia fell

Mange daemonar startar privilegert, konfigurerer grensesnittet, byter deretter til ein uprivilegert brukar og held på tunnelen. Frå det punktet kan prosessen ikkje lenger leggje til ei rute, skrive om ei brannmurregel eller opne eininga på nytt, noko som er greitt heilt til ein gjenoppkopling treng nettopp det. Seinare fillesing og køyring av hooks kan feile av same grunn.

Test heile livssyklusen i staden for det første sekundet: oppstart, ei fornying eller gjenoppkopling og opprydding ved stopp. Ein første vellykka oppretting av grensesnittet provar ikkje at kvar seinare privilegert operasjon framleis verkar, og feilen dukkar vanlegvis opp timar seinare i produksjon.

Implementasjonar som held tunnelen open gjennom eit brukarbyte, parear det vanlegvis med alternativ for å ta vare på tunnelen og nøklane. På systemd-sida er det tilsvarande spørsmålet om kapabilitetssettet til eininga overlever brukarbytet du konfigurerte.

Skriv ned tildelinga og grunngivinga for henne

Skriv ned den nøyaktige tildelinga, operasjonen ho gjer mogleg og feilen ho retta. Éi line i utrullingsnotata — «CAP_NET_ADMIN i nettverksnamnerommet til eininga, nødvendig for ruteendringar etter gjenoppkopling» — er nok til å hindre den neste personen i å utvide tildelinga igjen.

Les deretter det effektive settet på nytt etter kvar oppgradering. Leverandørar legg til funksjonar, images endrar standardverdiar, og ein kapabilitet som var unødvendig i fjor, kan bli berande utan at nokon merkar det.

Relaterte artiklar