Doni CAP_NET_ADMIN al OpenVPN sen doni root

La servo startas, la protokolo plendas, ke ĝi ne povas malfermi la tun-aparaton, kaj itineroj neniam aperas. Rulu capsh --print en via ŝelo kaj cap_net_admin estas ĝuste tie, kio igas la malsukceson ŝajni neebla. Kio diferencas inter via ŝelo kaj la unuo estas la privilegia transiro, ne la pretemo de la kerno doni la kapablon. Trairu la kvar kontrolojn sube laŭ ordo kaj haltu ĉe la unua, kiu klarigas la breĉon.

Apartigi mankan kapablon de kaŝita aparato

Du malsukcesoj aspektas samaj laŭ la protokola linio. Procezo sen CAP_NET_ADMIN ne povas krei aŭ agordi la tunelan interfacon, kaj procezo, kies sablujo kaŝas /dev/net/tun, tute ne povas malfermi ĝin. Aldoni kapablojn ne riparos la duan kazon.

Kontrolu, ĉu la aparato ekzistas ene de la nomspaco de la servo, antaŭ ol vi redaktu ion ajn. PrivateDevices=yes estas ofta malmoliga linio, kiu forigas la tun-nodon tute, kaj restrikta ProtectSystem povas igi la agordan vojon nurlegebla tiel, ke ĝi legiĝas kiel permesa eraro. Ambaŭ produktas protokolajn liniojn, kiuj mencias la tunelon, kaj tial la kapabloj estas kulpigitaj. Unue konfirmu, ke la nodo ĉeestas kaj malfermeblas, poste daŭrigu.

Sciu, kiun kapablaron vi rigardas

Linux tenas permesitajn, efikajn, heredajn, limigajn kaj ĉirkaŭajn arojn, kaj la ĉirkaŭa aro estas tiu, kiu postvivas exec de ne-root uzanto. Dosieraj kapabloj sur la dunoma dosiero povas transdoni permesitajn kaj efikajn rajtojn ĉe exec, sed nur dum nenio en la ĉeno blokas tiun transdonon.

Ĉi tie sudo misgvidas homojn. Komando rulita tra sudo -u komencas novan privilegian transiron kaj la ĉirkaŭa aro malaperas, do la sama kontrolo, kiu sukcesas kiel root, malsukcesas tie. La servoadministrilo estas ankoraŭ alia transiro, kaj ĝi donas nenion ĉirkaŭan, krom se la unuo diras tion.

Donu la kapablon en la unuo, ne en volvaĵo

Minimuma servo-sekcio por tunelo, kiu devas krei aparaton kaj instali itinerojn, aspektas jene.

[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 metas la rajton en la ĉirkaŭan aron antaŭ ol la procezo startas, kaj CapabilityBoundingSet malhelpas la procezon teni ion ekster tiu listo. NoNewPrivileges=yes blokas akiron de privilegio per setuid aŭ dosieraj kapabloj, dum la kapablo, kiun la unuo eksplicite donas, ankoraŭ validas. Aldonu CAP_NET_BIND_SERVICE nur kiam la servo devas ligi malaltan pordon, kaj neniam aldonu CAP_SYS_ADMIN nur ĉar forumfadeno tion faris.

Se la unuo volvas la dunoman dosieron en sudo, forigu la volvaĵon. systemd jam aplikas User=, kaj tiu kroma tavolo estas la plej verŝajna kaŭzo, ke la ĉirkaŭa aro estas malplena.

Kontrolu kontraŭ la viva procezo, ne kontraŭ la dosiero de la unuo

Legu, kion la administrilo efektive aplikis, poste legu la procezon, kiun ĝi generis.

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

Se la unuo listigas la kapablon kaj CapEff ankoraŭ mankas al ĝi, iu drop-in anstataŭigas la agordon aŭ paŝo ExecStartPre ŝanĝas la medion. Serĉu la nomon de la unuo en la drop-in dosierujoj antaŭ ol supozi, ke la ĉefa dosiero estas aŭtoritata, ĉar posta dosiero venkas silente. Se kaj la unuo kaj la procezo montras la kapablon kaj la tunelo ankoraŭ malsukcesas, reiru al la kontroloj de aparato kaj vojo anstataŭ vastigi la limigan aron. Vastigi ĝin kaŝas la veran kaŭzon kaj lasas la servon pli privilegia ol antaŭe.

Preferu forlasi privilegiojn post la starto

OpenVPN povas starti privilegie kaj poste transiri al neprivilegia konto per siaj propraj opcioj user kaj group, dum persist-key kaj persist-tun tenas la tunelon uzebla poste. Tiu aranĝo mallarĝigas la fenestron, en kiu la procezo tenas rajtojn, kaj ĝi ofte pli taŭgas ol startigi la tutan demonon neprivilegie kun permanentaj kapabloj.

Kiun ajn modelon vi elektas, restartigu la unuon kaj ripetu la kontrolojn post restarto, ĉar servo, kiu funkcias el interaga root-ŝelo kaj malsukcesas ĉe boot, kutime estas diferenco en kapablo, aparato aŭ dosieraj permesoj. Notu la agordojn de la unuo apud la kapabla eligo de la procezo, por ke la sekva revizianto vidu, ĉu paka ĝisdatigo aŭ drop-in movis la limon.