Hvilke Linux-kapabiliteter trenger VPN-prosessen din?
Oppsett av grensesnittet, ruter, enhetstilgang og vanlige sockets er separate privilegier. Navngi operasjonen som feilet før du gir CAP_NET_ADMIN.
En VPN-daemon trenger privilegerte nettverksoperasjoner selv om vanlige programmer åpner utgående sockets helt uten privilegier. Det er i dette gapet de fleste kapabilitetsfeil starter: noen ser en tilgangsfeil, gir hele settet, og tjenesten virker av grunner ingen senere kan forklare. Gjennomgangen nedenfor starter ved operasjonen som feilet, kobler den til én myndighet og sjekker deretter konteksten prosessen faktisk kjører i. Å kjøre som ubegrenset root er et gyldig svar for noen utrullinger, men det bør være en beslutning og ikke en standard.
Start ved operasjonen som feilet
Les feilen før du leser en veiledning. «Operasjonen er ikke tillatt» ved en grensesnittendring, en avvisning av å åpne en enhetsnode og en bind-feil på en lav port er tre forskjellige problemer med tre forskjellige tildelinger. Hvis prosessen starter og bare feiler ved den første ruteendringen, forteller det også at grensesnittet allerede er opprettet, noe som snevrer inn svaret betraktelig.
Gjenskap feilen med tjenesten stoppet, og start den deretter i forgrunnen under samme bruker hvis implementasjonen tillater det. En feil du kan se, er bedre enn en logglinje du må gjette deg til, og den gjør forskjellen mellom et kapabilitetsproblem og en avvisning fra SELinux eller AppArmor tydelig.
Koble hver operasjon til én myndighet
Tabellen er et startkart, ikke en erstatning for implementasjonens dokumentasjon:
| Operation | Usual authority | Watch for |
|---|---|---|
| Create or configure tun/tap | CAP_NET_ADMIN in the relevant namespace | Creating the device and opening it are separate steps |
| Add routes, rules, firewall entries | CAP_NET_ADMIN | Same capability, different namespace than you think |
| Open /dev/net/tun | Device permissions, not a capability | Group membership or a udev rule may be enough |
| Raw sockets | CAP_NET_RAW | Needed by some user-space tunnel implementations |
| Bind a port below 1024 | CAP_NET_BIND_SERVICE | Irrelevant for most modern tunnel ports |
De to radene i tabellen er dem folk blander sammen. Å åpne /dev/net/tun er et spørsmål om filrettigheter; å be kjernen konfigurere det du åpnet, er et spørsmål om kapabiliteter. Tildeling av CAP_NET_ADMIN retter ikke en enhetsnode tjenestebrukeren din ikke kan lese, og å rette noden gir deg ikke ruterettighet. Sjekk begge før du endrer noen av dem.
WireGuard i kjernen og tunnelprogrammer i brukerrommet har heller ikke identiske krav. Kjernemodulveien konfigurerer et eksisterende grensesnitt via netlink, mens en implementasjon i brukerrommet også kan trenge enheten og, for noen transportlag, rå sockets.
Les konteksten: tjeneste, container eller skall
En kapabilitet i vertsmaskinens nettverksnavnerom kan påvirke langt mer enn den samme operasjonen i en bevisst isolert stabel. Et container-runtime starter vanligvis med et redusert grensesett; å legge NET_ADMIN til en container som deler vertens nettverk er en langt større tildeling enn å legge det til en med eget nettverksnavnerom og uten vertsmontasjer.
For systemd-enheter bør du lese hva som faktisk anvendes, ikke hva enhetsfilen ser ut til å si: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities rapporterer de effektive verdiene, som kan være satt av en drop-in du har glemt. Spør etter den effektive verdien, aldri den tiltenkte. Ambient-kapabiliteter betyr noe fordi en tjeneste uten root mister kapabiliteter gjennom exec uten dem.
Bruk pakken eller imagets støttede oppsett som utgangspunkt. Ikke legg til rå-socket-tillatelser eller privilegert modus fordi en annen veiledning listet dem for et annet verktøy; den begrunnelsen overfører ingenting og koster deg isolasjonen du betalte for. Er du i tvil, gi ingenting og les implementasjonsnotatene for den nøyaktige operasjonen du trenger.
Se hva som skjer etter at privilegiene faller
Mange daemoner starter privilegert, konfigurerer grensesnittet, bytter deretter til en uprivilegert bruker og beholder tunnelen. Fra det punktet kan prosessen ikke lenger legge til en rute, skrive om en brannmurregel eller åpne en ny privilegert enhet, noe som er greit helt til en gjenoppkobling trenger nettopp det. Senere fillesing og kjøring av hooks kan feile av samme grunn.
Test hele livssyklusen i stedet for det første sekundet: oppstart, en fornyelse eller gjenoppkobling og opprydding ved stopp. En første vellykket oppretting av grensesnittet beviser ikke at hver senere privilegert operasjon fortsatt virker, og feilen dukker vanligvis opp timer senere i produksjon.
Implementasjoner som holder tunnelen åpen gjennom et brukerbytte, parer det vanligvis med alternativer for å bevare tunnelen og nøklene. På systemd-siden er det tilsvarende spørsmålet om enhetens kapabilitetssett overlever brukerbyttet du konfigurerte.
Skriv ned tildelingen og begrunnelsen for den
Skriv ned den nøyaktige tildelingen, operasjonen den muliggjør og feilen den rettet. Én linje i utrullingsnotatene — «CAP_NET_ADMIN i enhetens nettverksnavnerom, nødvendig for ruteendringer etter gjenoppkobling» — er nok til å hindre den neste personen i å utvide tildelingen igjen.
Les deretter det effektive settet på nytt etter hver oppgradering. Leverandører legger til funksjoner, images endrer standardverdier, og en kapabilitet som var unødvendig i fjor, kan bli bærende uten at noen merker det.