Дајте OpenVPN-у CAP_NET_ADMIN без давања root-а

Сервис се покреће, лог се жали да не може да отвори tun уређај, а руте се никада не појављују. Покрените capsh --print у својој љусци и cap_net_admin је одмах ту, што чини квар немогућим. Оно што се разликује између ваше љуске и јединице јесте прелаз привилегија, а не спремност језгра да додели способност. Прођите кроз четири провере испод редом и зауставите се на првој која објашњава разлику.

Одвојите недостајућу способност од скривеног уређаја

Два квара изгледају исто из лог линије. Процес без CAP_NET_ADMIN не може да створи или конфигурише интерфејс тунела, а процес чији sandbox скрива /dev/net/tun не може да га отвори уопште. Додавање способности неће поправити други случај.

Проверите да ли уређај постоји унутар именског простора сервиса пре него што било шта измените. PrivateDevices=yes је уобичајена линија очвршћивања која потпуно уклања tun чвор, а рестриктиван ProtectSystem може да учини путању конфигурације само за читање на начин који се чита као грешка дозвола. Оба производе лог линије које помињу тунел, зато се кривица приписује способностима. Прво потврдите да чвор постоји и да може да се отвори, па наставите.

Знајте који скуп способности гледате

Linux држи дозвољени, ефективни, наследни, ограничавајући и амбијентални скуп, а амбијентални скуп је онај који преживи exec од корисника који није root. Датотечне способности на бинарном фајлу могу да пренесу дозвољена и ефективна права при exec, али само док ништа у ланцу не блокира тај пренос.

Ту sudo заводи људе. Команда покренута кроз sudo -u започиње нови прелаз привилегија и амбијентални скуп нестаје, па иста провера која успева као root тамо пада. Управник сервиса је још један прелаз и не даје ништа амбијентално ако јединица то не каже.

Доделите способност у јединици, не у омоту

Минимални одељак сервиса за тунел који треба да створи уређај и инсталира руте изгледа овако.

[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 ставља право у амбијентални скуп пре него што процес почне, а CapabilityBoundingSet спречава процес да држи било шта изван тог списка. NoNewPrivileges=yes блокира стицање привилегија кроз setuid или датотечне способности, док се способност коју јединица изричито даје и даље примењује. Додајте CAP_NET_BIND_SERVICE само када сервис мора да веже низак порт, и никада не додајте CAP_SYS_ADMIN само зато што је то урадила нека форумска тема.

Ако јединица умотава бинарни фајл у sudo, уклоните омот. systemd већ примењује User=, и тај додатни слој је највероватнији разлог зашто је амбијентални скуп празан.

Проверавајте на живим процесу, не на датотеци јединице

Прочитајте шта је управник стварно применио, а затим прочитајте процес који је створио.

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

Ако јединица наводи способност а CapEff је још нема, неки drop-in преписује подешавање или корак ExecStartPre мења окружење. Претражите drop-in директоријуме за име јединице пре него што претпоставите да је главна датотека меродавна, јер каснија датотека тихо побеђује. Ако и јединица и процес показују способност а тунел и даље не ради, вратите се проверама уређаја и путање уместо да шири ограничавајући скуп. Његово ширење крије прави узрок и оставља сервис привилегованијим него што је био.

Радије спустите привилегије после покретања

OpenVPN може да почне са привилегијама и затим пређе на непривилеговани налог кроз сопствене опције user и group, док persist-key и persist-tun држе тунел употребљивим после тога. Такав распоред сужава прозор у ком процес држи права и често се боље уклапа од покретања целог демона без привилегија са трајним способностима.

Који год модел да изаберете, поново покрените јединицу и поновите провере после рестарта, јер сервис који ради из интерактивне root љуске а пада при подизању обично је разлика у способности, уређају или дозволама датотеке. Запишите подешавања јединице поред излаза способности процеса, како би следећи рецензент видео да ли је ажурирање пакета или drop-in померило границу.