Cilat aftësi Linux i nevojiten procesit tuaj VPN?
Konfigurimi i ndërfaqes, rrugët, aksesi në pajisje dhe soketat e zakonshëm janë privilegje të veçanta. Emërtoni operacionin që dështoi përpara se të jepni CAP_NET_ADMIN.
Një daemon VPN ka nevojë për operacione rrjeti të privilegjuara, ndonëse aplikacionet e zakonshme hapin soketa dalëse pa asnjë privilegj. Pikërisht në këtë boshllëk fillojnë shumica e gabimeve të aftësive: dikush sheh një gabim leje, jep të gjithë grupin, dhe shërbimi punon për arsye që askush nuk arrin t'i shpjegojë më vonë. Ecja më poshtë nis nga operacioni që dështoi, e lidh atë me një autoritet të vetëm dhe më pas kontrollon kontekstin në të cilin procesi ekzekutohet vërtet. Të ekzekutosh si root pa kufizime është përgjigje e vlefshme për disa implementime, por duhet të jetë vendim dhe jo vlerë e paracaktuar.
Nis nga operacioni që dështoi
Lexo gabimin përpara se të lexosh një udhëzues. «Operacioni nuk lejohet» në një ndryshim ndërfaqeje, refuzimi për të hapur një nyje pajisjeje dhe dështimi i bind në një port të ulët janë tre probleme të ndryshme me tre leje të ndryshme. Nëse procesi niset dhe dështon vetëm në ndryshimin e parë të rrugës, kjo tregon gjithashtu se krijimi i ndërfaqes ka pasur sukses, gjë që e ngushton shumë përgjigjen.
Riprodho dështimin me shërbimin të ndalur, pastaj nise atë në plan të parë nën të njëjtin përdorues nëse implementimi e lejon. Një gabim që e shihni është më mirë se një rresht log që duhet ta hamendësoni, dhe e bën të qartë dallimin midis një problemi të aftësive dhe një refuzimi nga SELinux ose AppArmor.
Lidh çdo operacion me një autoritet
Tabela është një hartë fillestare, jo zëvendësues i dokumentacionit të implementimit:
| 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 |
Dy rreshtat në atë tabelë janë ata që njerëzit i ngatërrojnë. Hapja e /dev/net/tun është çështje lejeje skedari; kërkesa ndaj kernelit për të konfiguruar atë që keni hapur është çështje aftësie. Dhënia e CAP_NET_ADMIN nuk rregullon një nyje pajisjeje që përdoruesi i shërbimit tuaj nuk mund ta lexojë, dhe rregullimi i nyjes nuk ju jep autoritet mbi rrugët. Kontrollo të dyja përpara se të ndryshosh cilëndo.
WireGuard në kernel dhe programet e tunelit në hapësirën e përdoruesit gjithashtu nuk kanë të njëjtat kërkesa. Rruga e modulit të kernelit konfiguron një ndërfaqe ekzistuese përmes netlink, ndërsa një implementim në hapësirën e përdoruesit mund të ketë nevojë edhe për pajisjen dhe, për disa transporte, për soketa të papërpunuara.
Lexo kontekstin: shërbim, kontejner apo shell
Një aftësi në hapësirën e emrave të rrjetit të hostit mund të ndikojë shumë më tepër sesa i njëjti operacion brenda një stivi të izoluar me qëllim. Një mjedis ekzekutimi kontejnerësh zakonisht nis me një grup kufijsh të reduktuar; shtimi i NET_ADMIN në një kontejner që ndan rrjetin e hostit është një leje shumë më e madhe sesa shtimi i tij në një me hapësirë të vet emrash rrjeti dhe pa montime të hostit.
Për njësitë systemd lexo atë që zbatohet vërtet dhe jo atë që skedari i njësisë duket se thotë: systemctl show -p CapabilityBoundingSet -p AmbientCapabilities raporton vlerat efektive, të cilat mund të jenë vendosur nga një drop-in që e keni harruar. Kërko vlerën efektive, kurrë atë të synuar. Aftësitë ambient kanë rëndësi sepse një shërbim që nuk është root humbet aftësi përgjatë exec pa ato.
Merr si bazë konfigurimin e mbështetur të paketës ose të imazhit. Mos shto leje për soketa të papërpunuara ose modalitet të privilegjuar vetëm sepse një udhëzues tjetër i renditi për një mjet tjetër; ai arsyetim nuk transferon asgjë dhe të kushton izolimin që ke paguar. Kur je në dyshim, mos jep asgjë dhe lexo shënimet e implementimit për operacionin e saktë që të nevojitet.
Vëzhgo çfarë ndodh pasi bien privilegjet
Shumë daemonë nisin me privilegje, konfigurojnë ndërfaqen, pastaj kalojnë te një përdorues pa privilegje dhe e mbajnë tunelin. Nga ai moment procesi nuk mund të shtojë më një rrugë, të rishkruajë një rregull firewall-i ose të hapë një pajisje të re të privilegjuar, gjë që është në rregull derisa një rilidhje ka nevojë pikërisht për atë. Leximet e skedarëve dhe ekzekutimi i hook-ave më vonë mund të dështojnë për të njëjtën arsye.
Testo të gjithë ciklin e jetës dhe jo sekondën e parë: nisja, një rinovim ose rilidhje dhe pastrimi në ndalim. Një krijim i parë i suksesshëm i ndërfaqes nuk vërteton se çdo operacion i privilegjuar i mëvonshëm do të vazhdojë të punojë, dhe dështimi zakonisht shfaqet orë më vonë në prodhim.
Implementimet që e mbajnë tunelin hapur gjatë një ndryshimi përdoruesi zakonisht e shoqërojnë atë me opsione për të ruajtur tunelin dhe çelësat. Nga ana e systemd, pyetja ekuivalente është nëse grupi i aftësive të njësisë i mbijeton ndryshimit të përdoruesit që keni konfiguruar.
Regjistro lejen dhe arsyen e saj
Shkruaj lejen e saktë, operacionin që ajo mundëson dhe gabimin që rregulloi. Një rresht në shënimet e implementimit — «CAP_NET_ADMIN në hapësirën e emrave të rrjetit të njësisë, i nevojshëm për ndryshimet e rrugëve pas rilidhjes» — mjafton për të ndaluar personin tjetër të zgjerojë përsëri lejen.
Pastaj rilexo grupin efektiv pas çdo përditësimi. Furnizuesit shtojnë funksione, imazhet ndryshojnë vlerat e paracaktuara, dhe një aftësi që ishte e panevojshme vitin e kaluar mund të bëhet mbajtëse pa e vënë re askush.