Milyen Linux-képességekre van szüksége a VPN-folyamatnak?
Az interfész beállítása, az útvonalak, az eszközhozzáférés és a közönséges socketek külön jogosultságok. Nevezze meg a sikertelen műveletet, mielőtt CAP_NET_ADMIN-t ad.
A VPN-démonnak kiemelt hálózati műveletekre van szüksége, pedig a közönséges alkalmazások minden jogosultság nélkül nyitnak kimenő socketeket. Ebben a résben kezdődik a legtöbb képesség-hiba: valaki jogosultsági hibát lát, odaadja az egész készletet, és a szolgáltatás olyan okokból működik, amelyeket később senki sem tud megmagyarázni. Az alábbi végigvezetés a sikertelen művelettől indul, egyetlen hatáskörhöz rendeli, majd ellenőrzi azt a környezetet, amelyben a folyamat valóban fut. A korlátlan rootként való futás egyes telepítéseknél érvényes válasz, de döntésnek kell lennie, nem alapértelmezésnek.
A sikertelen művelettől induljon ki
Olvassa el a hibát, mielőtt útmutatót olvas. Az „a művelet nem engedélyezett” interfész-változtatásnál, egy eszközcsomópont megnyitásának megtagadása és egy alacsony porton történő bind-hiba három különböző probléma három különböző engedéllyel. Ha a folyamat elindul, és csak az első útvonal-változtatásnál hibázik, az azt is jelenti, hogy az interfész létrehozása már sikerült, ami jelentősen szűkíti a választ.
Reprodukálja a hibát a szolgáltatás leállított állapotában, majd indítsa el előtérben ugyanazzal a felhasználóval, ha az implementáció engedi. A látható hiba jobb, mint egy kitalálandó naplósor, és nyilvánvalóvá teszi a különbséget a képesség-probléma és a SELinux vagy AppArmor elutasítása között.
Rendeljen minden műveletet egyetlen hatáskörhöz
A táblázat kiinduló térkép, nem az implementáció dokumentációjának helyettesítője:
| 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 |
A táblázat két sora az, amelyet az emberek összekevernek. A /dev/net/tun megnyitása fájljogosultsági kérdés; a kernel megkérése arra, hogy állítsa be a megnyitottat, képességkérdés. A CAP_NET_ADMIN megadása nem javítja meg azt az eszközcsomópontot, amelyet a szolgáltatásfelhasználó nem tud olvasni, és a csomópont javítása nem ad útvonal-hatáskört. Ellenőrizze mindkettőt, mielőtt bármelyiket módosítja.
A kernelbeli WireGuard és a felhasználói térben futó alagútprogramok követelményei sem azonosak. A kernelmodul útja netlinken keresztül állít be egy meglévő interfészt, míg a felhasználói téri implementációnak szüksége lehet az eszközre és egyes átviteleknél nyers socketekre is.
Olvassa el a környezetet: szolgáltatás, konténer vagy shell
A gazdagép hálózati névterében lévő képesség sokkal nagyobb hatással lehet, mint ugyanaz a művelet egy szándékosan elkülönített veremben. A konténer-futtatókörnyezet általában csökkentett korlátkészlettel indul; a NET_ADMIN hozzáadása egy gazdagép hálózatát megosztó konténerhez sokkal nagyobb engedély, mint egy saját hálózati névtérrel rendelkező és gazdagép-csatolások nélküli konténerhez.
A systemd-egységeknél azt olvassa, ami ténylegesen érvényesül, ne azt, amit az egységfájl mondani látszik: a systemctl show -p CapabilityBoundingSet -p AmbientCapabilities az effektív értékeket jelenti, amelyeket egy elfelejtett drop-in állíthatott be. Az effektív értéket kérdezze, soha a szándékoltat. Az ambient képességek azért fontosak, mert a nem root szolgáltatás ezek nélkül elveszíti a képességeit a exec során.
A csomag vagy a lemezkép támogatott beállítását vegye alapnak. Ne adjon hozzá nyers socket jogosultságokat vagy kiemelt módot azért, mert egy másik útmutató egy másik eszközhöz felsorolta őket; ez az érvelés semmit nem visz át, és azzal az elkülönítéssel fizet, amiért már fizetett. Ha bizonytalan, ne adjon semmit, és olvassa el az implementáció megjegyzéseit a pontosan szükséges művelethez.
Figyelje, mi történik a jogosultságok csökkenése után
Sok démon kiemelt jogosultsággal indul, beállítja az interfészt, majd átvált egy nem kiemelt felhasználóra, és megtartja az alagutat. Attól a ponttól a folyamat már nem tud útvonalat hozzáadni, tűzfal-szabályt átírni vagy új kiemelt eszközt megnyitni, ami addig rendben van, amíg egy újracsatlakozás pontosan ezt nem igényli. A későbbi fájlolvasások és hook-végrehajtás ugyanezen okból hiúsulhatnak meg.
A teljes életciklust tesztelje, ne az első másodpercet: indítás, megújítás vagy újracsatlakozás, és tisztítás leállításkor. Az első sikeres interfész-létrehozás nem bizonyítja, hogy minden későbbi kiemelt művelet továbbra is működik, és a hiba általában órákkal később, éles környezetben jelenik meg.
Azok az implementációk, amelyek felhasználóváltás alatt is nyitva tartják az alagutat, ezt általában az alagút és a kulcsok megőrzését szolgáló beállításokkal párosítják. A systemd oldalán az egyenértékű kérdés, hogy az egység képességkészlete túléli-e a beállított felhasználóváltást.
Jegyezze fel az engedélyt és annak okát
Írja le a pontos engedélyt, az általa lehetővé tett műveletet és a kijavított hibát. Egyetlen sor a telepítési megjegyzésekben — „CAP_NET_ADMIN az egység hálózati névterében, újracsatlakozás utáni útvonalváltozásokhoz szükséges” — elég ahhoz, hogy megakadályozza a következő embert az engedély ismételt kiszélesítésében.
Ezután minden frissítés után olvassa újra az effektív készletet. A beszállítók funkciókat adnak hozzá, a lemezképek alapértelmezéseket változtatnak, és egy tavaly fölösleges képesség észrevétlenül teherhordóvá válhat.