Hvilke Linux-kapabiliteter har din VPN-proces brug for?
Interfaceopsætning, ruter, enhedsadgang og almindelige sockets er separate privilegier. Navngiv den handling, der fejlede, før du giver CAP_NET_ADMIN.
En VPN-dæmon har brug for privilegerede netværkshandlinger, selv om almindelige programmer åbner udgående sockets helt uden privilegier. Det gab er, hvor de fleste kapabilitetsfejl starter: nogen ser en tilladelsesfejl, giver hele sættet, og tjenesten virker af grunde, som ingen senere kan forklare. Gennemgangen nedenfor starter ved den handling, der fejlede, knytter den til én beføjelse og tjekker derefter den kontekst, processen faktisk kører i. At køre som ubegrænset root er et gyldigt svar for nogle udrulninger, men det bør være en beslutning og ikke en standard.
Start ved den handling, der fejlede
Læs fejlen, før du læser en vejledning. „Operationen er ikke tilladt“ ved en interfaceændring, en afvisning af at åbne en enhedsnodet og en bind-fejl på en lav port er tre forskellige problemer med tre forskellige tildelinger. Hvis processen starter og kun fejler ved den første ruteændring, fortæller det også, at interfaceoprettelsen allerede lykkedes, hvilket indsnævrer svaret betydeligt.
Genskab fejlen med tjenesten stoppet, og start den derefter i forgrunden under samme bruger, hvis implementeringen tillader det. En fejl, du kan se, er bedre end en loglinje, du skal gætte dig til, og den gør forskellen mellem et kapabilitetsproblem og en SELinux- eller AppArmor-afvisning tydelig.
Knyt hver handling til én beføjelse
Tabellen er et startkort, ikke en erstatning for implementeringens dokumentation:
| 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 rækker i tabellen er dem, folk blander sammen. At åbne /dev/net/tun er et spørgsmål om filtilladelser; at bede kernen konfigurere det, du åbnede, er et spørgsmål om kapabiliteter. Tildeling af CAP_NET_ADMIN retter ikke en enhedsnodet, som din tjenestebruger ikke kan læse, og at rette nodet giver dig ikke rutebeføjelse. Tjek begge, før du ændrer nogen af dem.
WireGuard i kernen og tunnelprogrammer i brugerniveau har heller ikke identiske krav. Kernemodulvejen konfigurerer et eksisterende interface via netlink, mens en implementering i brugerniveau også kan have brug for enheden og, for nogle transportlag, rå sockets.
Læs konteksten: tjeneste, container eller shell
En kapabilitet i værtsmaskinens netværksnavnerum kan påvirke langt mere end den samme handling inde i en bevidst isoleret stak. En container-runtime starter typisk med et reduceret grænsesæt; at tilføje NET_ADMIN til en container, der deler værtens netværk, er en langt større tildeling end at tilføje det til en med sit eget netværksnavnerum og ingen værtsmonteringer.
For systemd-units skal du læse, hvad der faktisk anvendes, i stedet for hvad unit-filen ser ud til at sige: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities rapporterer de effektive værdier, som kan være sat af et drop-in, du har glemt. Spørg efter den effektive værdi, aldrig den tilsigtede. Ambient-kapabiliteter betyder noget, fordi en tjeneste uden root mister kapabiliteter hen over exec uden dem.
Brug pakkens eller images understøttede opsætning som udgangspunkt. Tilføj ikke rå-socket-tilladelser eller privilegeret tilstand, fordi en anden vejledning listede dem til et andet værktøj; den begrundelse overfører intet og koster dig den isolering, du betalte for. Er du i tvivl, så giv intet og læs implementeringens noter for den præcise handling, du har brug for.
Se, hvad der sker, når privilegierne falder
Mange dæmoner starter privilegeret, konfigurerer interfacet og skifter derefter til en uprivilegeret bruger og beholder tunnelen. Fra det punkt kan processen ikke længere tilføje en rute, omskrive en firewallregel eller åbne en ny privilegeret enhed, hvilket er fint, indtil en genopkobling har brug for netop det. Senere fillæsninger og hook-kørsel kan fejle af samme grund.
Test hele livscyklussen i stedet for det første sekund: opstart, en fornyelse eller genopkobling og oprydning ved stop. En første vellykket interfaceoprettelse beviser ikke, at hver senere privilegeret handling stadig virker, og fejlen dukker normalt op timer senere i produktion.
Implementeringer, der holder tunnelen åben hen over et brugerskift, parrer det normalt med muligheder for at bevare tunnelen og nøglerne. På systemd-siden er det tilsvarende spørgsmål, om unit'ens kapabilitetssæt overlever det brugerskift, du konfigurerede.
Skriv tildelingen og dens begrundelse ned
Skriv den præcise tildeling ned, den handling den muliggør, og den fejl den rettede. Én linje i udrulningsnoterne — „CAP_NET_ADMIN i unit'ens netværksnavnerum, nødvendig for ruteændringer efter genopkobling“ — er nok til at forhindre den næste person i at udvide tildelingen igen.
Læs derefter det effektive sæt igen efter hver opgradering. Leverandører tilføjer funktioner, images ændrer standarder, og en kapabilitet, der var unødvendig sidste år, kan blive bærende, uden at nogen bemærker det.