Bigyan ang OpenVPN ng CAP_NET_ADMIN nang hindi binibigyan ng root

Nagsisimula ang serbisyo, nagrereklamo ang log na hindi nito mabuksan ang tun device, at hindi kailanman lumilitaw ang mga ruta. Patakbuhin ang capsh --print sa iyong shell at ang cap_net_admin ay naroon mismo, na gumagawang imposible ang pagpalya. Ang pagkakaiba ng iyong shell at ng unit ay ang paglilipat ng pribilehiyo, hindi ang pagpayag ng kernel na ibigay ang kakayahan. Dumaan sa apat na pagsusuri sa ibaba nang sunud-sunod at huminto sa una na nagpapaliwanag ng agwat.

Ihiwalay ang nawawalang kakayahan sa nakatagong device

Dalawang pagpalya ang magkamukha mula sa linya ng log. Ang prosesong walang CAP_NET_ADMIN ay hindi makakalikha o makakapag-configure ng interface ng tunnel, at ang prosesong itinatago ng sandbox ang /dev/net/tun ay hindi ito mabubuksan sa simula pa lang. Ang pagdaragdag ng kakayahan ay hindi mag-aayos ng ikalawang kaso.

Suriin kung umiiral ang device sa loob ng namespace ng serbisyo bago ka mag-edit ng kahit ano. Ang PrivateDevices=yes ay karaniwang linya ng pagpapatibay na nag-aalis nang buo sa tun node, at ang mahigpit na ProtectSystem ay maaaring gawing read-only ang path ng configuration sa paraang mababasa na parang error sa pahintulot. Pareho silang gumagawa ng mga linya ng log na tumutukoy sa tunnel, kaya ang kakayahan ang sinisisi. Tiyakin muna na ang node ay naroon at nabubuksan, pagkatapos ay magpatuloy.

Alamin kung aling set ng kakayahan ang tinitignan mo

Hinihiling ng Linux ang mga set na pinapayagan, epektibo, namamana, naglilimita at pangkapaligiran, at ang pangkapaligirang set ang tumatagal pagkatapos ng exec ng isang user na hindi root. Ang mga kakayahan ng file sa binary ay maaaring maglipat ng pinapayagan at epektibong karapatan sa exec, ngunit hangga't walang humaharang sa paglilipat na iyon sa kadena.

Dito nalilinlang ng sudo ang mga tao. Ang command na pinapatakbo sa pamamagitan ng sudo -u ay nagsisimula ng bagong paglilipat ng pribilehiyo at nawawala ang pangkapaligirang set, kaya ang parehong pagsusuri na nagtatagumpay bilang root ay nabibigo doon. Ang tagapamahala ng serbisyo ay isa pang paglilipat, at wala itong ibinibigay na pangkapaligiran maliban kung sasabihin ng unit.

Ibigay ang kakayahan sa unit, hindi sa wrapper

Ang pinakamaliit na seksyon ng serbisyo para sa tunnel na kailangang lumikha ng device at mag-install ng mga ruta ay ganito ang hitsura.

[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

Inilalagay ng AmbientCapabilities ang karapatan sa pangkapaligirang set bago magsimula ang proseso, at pinipigilan ng CapabilityBoundingSet ang proseso na humawak ng anumang labas ng listahang iyon. Hinaharang ng NoNewPrivileges=yes ang pagkuha ng pribilehiyo sa pamamagitan ng setuid o mga kakayahan ng file, habang ang kakayahang tahasang ibinigay ng unit ay umiiral pa rin. Idagdag ang CAP_NET_BIND_SERVICE lamang kapag kailangang magbigkis ng mababang port ang serbisyo, at huwag kailanman idagdag ang CAP_SYS_ADMIN dahil lang ginawa ito ng isang thread sa forum.

Kung binabalot ng unit ang binary sa sudo, alisin ang wrapper. Inilalapat na ng systemd ang User=, at ang dagdag na patong na iyon ang pinakamalamang na dahilan kung bakit walang laman ang pangkapaligirang set.

I-verify laban sa buhay na proseso, hindi sa file ng unit

Basahin kung ano ang aktwal na inilapat ng tagapamahala, pagkatapos ay basahin ang prosesong nilikha nito.

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

Kung inililista ng unit ang kakayahan at wala pa rin ito sa CapEff, may drop-in na nagsasapaw sa setting o may hakbang na ExecStartPre na nagbabago ng kapaligiran. Hanapin ang pangalan ng unit sa mga direktoryo ng drop-in bago ipagpalagay na ang pangunahing file ang may awtoridad, dahil tahimik na nananalo ang huling file. Kung parehong ipinapakita ng unit at ng proseso ang kakayahan at nabibigo pa rin ang tunnel, bumalik sa mga pagsusuri ng device at path sa halip na palawakin ang naglilimitang set. Tinatakpan ng pagpapalawak nito ang tunay na dahilan at iniiwan ang serbisyo na mas may pribilehiyo kaysa dati.

Mas mainam na bitawan ang mga pribilehiyo pagkatapos ng pagsisimula

OpenVPN ay maaaring magsimula nang may pribilehiyo at pagkatapos ay bumaba sa isang account na walang pribilehiyo sa pamamagitan ng sarili nitong mga opsyon na user at group, habang pinapanatili ng persist-key at persist-tun na magamit pa rin ang tunnel pagkatapos. Ang ganitong kaayusan ay nagpapaliit sa bintana kung saan may mga karapatan ang proseso, at kadalasan ito ay mas angkop kaysa sa pagsisimula ng buong daemon na walang pribilehiyo na may permanenteng kakayahan.

Anuman ang modelong piliin mo, i-restart ang unit at ulitin ang mga pagsusuri pagkatapos ng reboot, dahil ang serbisyong gumagana mula sa interactive na root shell ngunit nabibigo sa boot ay kadalasang pagkakaiba sa kakayahan, device o pahintulot ng file. Itala ang mga setting ng unit sa tabi ng output ng kakayahan ng proseso upang makita ng susunod na tagasuri kung inilipat ng update ng package o ng drop-in ang hangganan.