Anda OpenVPN-ile CAP_NET_ADMIN ilma rooti andmata

Teenus käivitub, logi kurdab, et ei saa tun-seadet avada, ja marsruudid ei ilmu kunagi. Käivitage oma shellis capsh --print ja cap_net_admin on kohe seal, mis teeb vea näiliselt võimatuks. See, mis erineb teie shelli ja üksuse vahel, on privileegide üleminek, mitte tuuma valmisolek võimekust anda. Käige allolevad neli kontrolli järjekorras läbi ja peatuge esimesel, mis lõhe ära seletab.

Eraldage puuduv võimekus peidetud seadmest

Kaks viga näevad logirealt ühesugused välja. Protsess ilma CAP_NET_ADMIN ei saa tunneliliidest luua ega seadistada, ja protsess, mille sandbox peidab /dev/net/tun, ei saa seda üldse avada. Võimekuste lisamine ei paranda teist juhtumit.

Kontrollige, kas seade eksisteerib teenuse nimeruumis, enne kui midagi muudate. PrivateDevices=yes on tavaline kõvendusrida, mis eemaldab tun-sõlme täielikult, ja piirav ProtectSystem võib muuta konfiguratsioonitee kirjutuskaitstuks viisil, mis loeb nagu õiguste viga. Mõlemad tekitavad logiridu, mis tunnelit mainivad, ja seetõttu süüdistatakse võimekusi. Kinnitage esmalt, et sõlm on olemas ja avatav, ning liikuge siis edasi.

Teage, millist võimekuste komplekti vaatate

Linux hoiab lubatud, tõhusat, päritavat, piiravat ja ambient-komplekti, ja ambient-komplekt on see, mis jääb alles mitte-root kasutaja exec'i järel. Binaaril olevad failivõimekused võivad exec'i ajal üle anda lubatud ja tõhusad õigused, kuid ainult seni, kuni miski ahelas seda üleandmist ei blokeeri.

Siin eksitab sudo inimesi. Läbi sudo -u käivitatud käsk alustab uue privileegide ülemineku ja ambient-komplekt kaob, nii et sama kontroll, mis rootina õnnestub, ebaõnnestub seal. Teenusehaldur on jälle teine üleminek ja ei anna midagi ambienti, kui üksus seda ei ütle.

Andke võimekus üksuses, mitte mähises

Minimaalne teenuseosa tunnelile, mis peab looma seadme ja paigaldama marsruudid, näeb välja nii.

[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

AmbientCapabilities paneb õiguse ambient-komplekti enne protsessi käivitumist ja CapabilityBoundingSet hoiab protsessi sellest loendist väljaspool olevast eemale. NoNewPrivileges=yes blokeerib privileegide saamise setuidi või failivõimekuste kaudu, samal ajal kui üksuse selgesõnaliselt antud võimekus kehtib edasi. Lisage CAP_NET_BIND_SERVICE ainult siis, kui teenus peab siduma madala pordi, ja ärge kunagi lisage CAP_SYS_ADMIN ainult sellepärast, et üks foorumilõim seda tegi.

Kui üksus mähib binaari sudo sisse, eemaldage mähis. systemd rakendab juba User= ja see lisakiht on kõige tõenäolisem põhjus, miks ambient-komplekt on tühi.

Kontrollige elava protsessi vastu, mitte üksusefaili vastu

Lugege, mida haldur tegelikult rakendas, ja seejärel lugege protsessi, mille see tekitas.

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

Kui üksus loetleb võimekuse ja CapEff ikka seda ei oma, siis mõni drop-in alistab seade või ExecStartPre samm muudab keskkonda. Enne kui eeldate, et põhifail on autoriteetne, otsige drop-in kataloogidest üksuse nime, sest hilisem fail võidab vaikselt. Kui nii üksus kui protsess näitavad võimekust ja tunnel ikka ei tööta, minge tagasi seadme- ja teekontrollide juurde, selle asemel et piiravat komplekti laiendada. Selle laiendamine peidab tegeliku põhjuse ja jätab teenuse privilegeeritumaks kui enne.

Eelistage privileegidest loobumist pärast käivitumist

OpenVPN võib alustada privilegeeritult ja seejärel oma user ja group valikute kaudu mitteprivilegeeritud kontole laskuda, kusjuures persist-key ja persist-tun hoiavad tunnelit hiljem kasutatavana. See korraldus kitsendab akent, milles protsess õigusi hoiab, ja sobib sageli paremini kui kogu deemonit mitteprivilegeeritult püsivate võimekustega käivitada.

Ükskõik millise mudeli valite, taaskäivitage üksus ja korrake kontrolle pärast uuesti käivitamist, sest teenus, mis töötab interaktiivsest root-shellist ja ebaõnnestub alglaadimisel, on tavaliselt erinevus võimekuses, seadmes või failiõigustes. Kirjutage üksuse seaded protsessi võimekuse väljundi kõrvale, et järgmine ülevaataja näeks, kas paketi uuendus või drop-in nihutas piiri.