Dóna CAP_NET_ADMIN a OpenVPN sense donar-li root

El servei s'inicia, el registre es queixa que no pot obrir el dispositiu tun i les rutes no apareixen mai. Executeu capsh --print des de la vostra shell i cap_net_admin hi és just allà, cosa que fa que la fallada sembli impossible. El que difereix entre la vostra shell i la unitat és la transició de privilegis, no la voluntat del nucli de concedir la capacitat. Recorreu les quatre comprovacions següents en ordre i atureu-vos a la primera que expliqui la diferència.

Separeu una capacitat absent d'un dispositiu ocult

Dues fallades semblen iguals des de la línia de registre. Un procés sense CAP_NET_ADMIN no pot crear ni configurar la interfície del túnel, i un procés la sandbox del qual amaga /dev/net/tun no pot obrir-lo d'entrada. Afegir capacitats no arreglarà el segon cas.

Comproveu si el dispositiu existeix dins de l'espai de noms del servei abans d'editar res. PrivateDevices=yes és una línia d'enduriment habitual que elimina del tot el node tun, i un ProtectSystem restrictiu pot fer que el camí de configuració sigui només de lectura d'una manera que es llegeix com un error de permisos. Tots dos produeixen línies de registre que esmenten el túnel, i per això es culpa les capacitats. Confirmeu primer que el node hi és i que es pot obrir, i després continueu.

Sabu quin conjunt de capacitats esteu mirant

Linux manté els conjunts permès, efectiu, heretable, limit i ambient, i el conjunt ambient és el que sobreviu a un exec per part d'un usuari que no és root. Les capacitats de fitxer al binari poden transferir drets permesos i efectius en l'exec, però només mentre res de la cadena no bloquegi aquesta transferència.

Aquí és on sudo enganya la gent. Una ordre executada amb sudo -u inicia una transició de privilegis nova i el conjunt ambient desapareix, així que la mateixa comprovació que té èxit com a root falla allà. El gestor de serveis és encara una altra transició, i no concedeix res ambient si la unitat no ho diu.

Concediu la capacitat a la unitat, no en un embolcall

Una secció de servei mínima per a un túnel que ha de crear un dispositiu i instal·lar rutes es llegeix així.

[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 posa el dret al conjunt ambient abans que el procés s'iniciï, i CapabilityBoundingSet impedeix que el procés tingui res fora d'aquesta llista. NoNewPrivileges=yes bloqueja l'obtenció de privilegis mitjançant setuid o capacitats de fitxer, mentre que la capacitat que la unitat concedeix explícitament encara s'aplica. Afegiu CAP_NET_BIND_SERVICE només quan el servei hagi d'enllaçar un port baix, i no afegiu mai CAP_SYS_ADMIN només perquè un fil de fòrum ho va fer.

Si la unitat embolcalla el binari en sudo, traieu l'embolcall. systemd ja aplica User=, i aquesta capa extra és el motiu més probable que el conjunt ambient sigui buit.

Verifiqueu contra el procés viu, no contra el fitxer de la unitat

Llegiu què ha aplicat realment el gestor i després llegiu el procés que ha engendrat.

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

Si la unitat llista la capacitat i CapEff encara no la té, algun drop-in està sobreescrivint la configuració o algun pas ExecStartPre està canviant l'entorn. Cerqueu el nom de la unitat als directoris drop-in abans de suposar que el fitxer principal és l'autoritatiu, perquè un fitxer posterior guanya en silenci. Si tant la unitat com el procés mostren la capacitat i el túnel encara falla, torneu a les comprovacions de dispositiu i de camí en lloc d'ampliar el conjunt limit. Ampliar-lo amaga la causa real i deixa el servei més privilegiat del que era.

Preferiu deixar anar els privilegis després de l'arrencada

OpenVPN pot començar amb privilegis i després baixar a un compte sense privilegis mitjançant les seves pròpies opcions user i group, amb persist-key i persist-tun mantenint el túnel utilitzable després. Aquesta disposició estreta la finestra en què el procés té drets i sovint encaixa millor que iniciar tot el dimoni sense privilegis amb capacitats permanents.

Sigui quin sigui el model triat, reinicieu la unitat i repetiu les comprovacions després d'un reinici del sistema, perquè un servei que funciona des d'una shell root interactiva i falla a l'arrencada sol ser una diferència de capacitat, dispositiu o permisos de fitxer. Anoteu la configuració de la unitat al costat de la sortida de capacitats del procés perquè el proper revisor vegi si una actualització de paquet o un drop-in ha mogut la frontera.