CAP_NET_ADMIN adása az OpenVPN-nek root nélkül

A szolgáltatás elindul, a napló panaszkodik, hogy nem tudja megnyitni a tun eszközt, és az útvonalak soha nem jelennek meg. Futtassa a capsh --print parancsot a saját shelljében, és a cap_net_admin ott van, ami lehetetlennek láttatja a hibát. Ami a shellje és a unit között eltér, az a jogosultságátmenet, nem a kernel hajlandósága a képesség megadására. Menjen végig az alábbi négy ellenőrzésen sorrendben, és álljon meg az elsőnél, amely megmagyarázza a rést.

Válassza el a hiányzó képességet a rejtett eszköztől

Két hiba egyformának látszik a naplósorból. A CAP_NET_ADMIN nélküli folyamat nem tudja létrehozni vagy beállítani az alagút interfészét, és az a folyamat, amelynek sandboxa elrejti a /dev/net/tun elemet, egyáltalán nem tudja megnyitni. A képességek hozzáadása nem javítja a második esetet.

Ellenőrizze, hogy az eszköz létezik-e a szolgáltatás névterében, mielőtt bármit szerkesztene. A PrivateDevices=yes gyakori keményítő sor, amely teljesen eltávolítja a tun csomópontot, és egy korlátozó ProtectSystem csak olvashatóvá teheti a konfigurációs útvonalat olyan módon, amely engedélyhibaként olvasható. Mindkettő olyan naplósorokat produkál, amelyek említik az alagutat, ezért a képességeket okolják. Először erősítse meg, hogy a csomópont jelen van és megnyitható, aztán lépjen tovább.

Tudja, melyik képességkészletet nézi

A Linux engedélyezett, effektív, örökölhető, korlátozó és ambient készleteket tart, és az ambient készlet az, amely túléli egy nem root felhasználó exec műveletét. A binárison lévő fájlképességek exec során átadhatnak engedélyezett és effektív jogokat, de csak addig, amíg a láncban semmi nem blokkolja ezt az átadást.

Itt vezeti félre sudo az embereket. A sudo -u útján futtatott parancs új jogosultságátmenetet indít, és az ambient készlet eltűnik, így ugyanaz az ellenőrzés, amely rootként sikerül, ott elbukik. A szolgáltatáskezelő megint más átmenet, és nem ad semmi ambientet, hacsak a unit nem mondja.

A képességet a unitban adja meg, ne egy wrapperben

Egy minimális szolgáltatásszakasz egy olyan alagúthoz, amelynek eszközt kell létrehoznia és útvonalakat telepítenie, így néz ki.

[Unit]
Description=OpenVPN client, office profile
After=network-online.target

[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.conf

A AmbientCapabilities a folyamat indulása előtt beteszi a jogot az ambient készletbe, a CapabilityBoundingSet pedig megakadályozza, hogy a folyamat a listán kívül bármit tartson. A NoNewPrivileges=yes blokkolja a jogosultságszerzést setuid vagy fájlképességek útján, miközben a unit által kifejezetten adott képesség továbbra is érvényes. A CAP_NET_BIND_SERVICE csak akkor adja hozzá, ha a szolgáltatásnak alacsony portot kell kötnie, és soha ne adja hozzá a CAP_SYS_ADMIN elemet csak azért, mert egy fórumtéma így tett.

Ha a unit a binárist sudo belsejébe csomagolja, távolítsa el a wrappert. A systemd már alkalmazza a User= elemet, és ez a plusz réteg a legvalószínűbb oka annak, hogy az ambient készlet üres.

Az élő folyamat ellen ellenőrizzen, ne a unit fájl ellen

Olvassa el, mit alkalmazott valójában a kezelő, majd olvassa el az általa létrehozott folyamatot.

unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/status

Ha a unit felsorolja a képességet, és a CapEff még mindig nem rendelkezik vele, egy drop-in felülírja a beállítást, vagy egy ExecStartPre lépés megváltoztatja a környezetet. Keresse meg a unit nevét a drop-in könyvtárakban, mielőtt a fő fájlt tartaná mérvadónak, mert egy későbbi fájl csendben nyer. Ha a unit és a folyamat is mutatja a képességet, és az alagút mégis elbukik, térjen vissza az eszköz- és útvonalellenőrzésekhez, ahelyett hogy szélesítené a korlátozó készletet. A szélesítés elrejti a valódi okot, és a szolgáltatást az eddiginél nagyobb jogosultsággal hagyja.

Inkább indulás után adja fel a jogosultságokat

OpenVPN képes privilegizáltan indulni, majd a saját user és group beállításaival áttérni egy nem privilegizált fiókra, miközben a persist-key és a persist-tun utána is használhatóvá teszi az alagutat. Ez az elrendezés szűkíti azt az ablakot, amelyben a folyamat jogokkal rendelkezik, és gyakran jobban illik, mint az egész démont nem privilegizáltan, állandó képességekkel indítani.

Bármelyik modellt választja, indítsa újra a unitot, és ismételje meg az ellenőrzéseket újraindítás után, mert az a szolgáltatás, amely interaktív root shellből működik, de indításkor elbukik, általában képesség, eszköz vagy fájljogosultság különbsége. Jegyezze fel a unit beállításait a folyamat képességkimenete mellé, hogy a következő ellenőrző lássa, egy csomagfrissítés vagy egy drop-in elmozdította-e a határt.