Gee OpenVPN CAP_NET_ADMIN sonder om wortel daarvoor te gee

Die diens begin, die log kla dat dit nie die tun-toestel kan oopmaak nie, en roetes verskyn nooit. Voer capsh --print in jou skulp uit en cap_net_admin is daar reg voor jou, wat die fout onmoontlik laat lyk. Wat tussen jou skulp en die eenheid verskil, is die oorgang van voorregte, nie die kern se bereidheid om die vermoë toe te ken nie. Werk die vier kontroles hieronder in volgorde deur en stop by die eerste een wat die gaping verklaar.

Skei 'n ontbrekende vermoë van 'n verborge toestel

Twee foute lyk dieselfde uit die logreël. 'n Proses sonder CAP_NET_ADMIN kan nie die tonnelkoppelvlak skep of opstel nie, en 'n proses wie se sandput /dev/net/tun wegsteek, kan dit in die eerste plek nie oopmaak nie. Bykomende vermoëns sal nie die tweede een regstel nie.

Kontroleer of die toestel binne die diens se naamruimte bestaan voordat jy enigiets wysig. PrivateDevices=yes is 'n algemene verskerpingsreël wat die tun-nodus heeltemal verwyder, en 'n beperkende ProtectSystem kan die konfigurasiepad leesalleen maak op 'n manier wat soos 'n toestemmingsfout lees. Albei lewer logreëls wat die tonnel noem, en daarom kry vermoëns die skuld. Bevestig eers dat die nodus teenwoordig en oopmaakbaar is, en gaan dan aan.

Weet na watter vermoënstel jy kyk

Linux hou toegelate, effektiewe, oorerflike, begrensende en omgewingsstelle by, en die omgewingsstel is die een wat 'n exec deur 'n nie-wortelgebruiker oorleef. Lêervermoëns op die binêre lêer kan toegelate en effektiewe regte by exec oorhandig, maar net solank niks in die ketting daardie oordrag blokkeer nie.

Dit is waar sudo mense mislei. 'n Opdrag wat deur sudo -u loop, begin 'n nuwe oorgang van voorregte en die omgewingsstel is weg, so dieselfde kontrole wat as wortel slaag, misluk daar. Die diensbestuurder is weer 'n ander oorgang, en dit ken niks omgewings toe tensy die eenheid dit sê nie.

Ken die vermoë in die eenheid toe, nie in 'n omhulsel nie

'n Minimale diensafdeling vir 'n tonnel wat 'n toestel moet skep en roetes moet installeer, lyk so.

[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 plaas die reg in die omgewingsstel voordat die proses begin, en CapabilityBoundingSet verhoed dat die proses enigiets buite daardie lys hou. NoNewPrivileges=yes blokkeer voorregwins deur setuid of lêervermoëns, terwyl die vermoë wat die eenheid uitdruklik toeken, steeds geld. Voeg CAP_NET_BIND_SERVICE net by wanneer die diens 'n lae poort moet bind, en voeg nooit CAP_SYS_ADMIN by net omdat 'n forumdraad dit gedoen het nie.

As die eenheid die binêre lêer in sudo toedraai, verwyder die omhulsel. systemd pas reeds User= toe, en daardie ekstra laag is die waarskynlikste rede waarom die omgewingsstel leeg is.

Verifieer teen die lewende proses, nie die eenheidlêer nie

Lees wat die bestuurder werklik toegepas het, en lees dan die proses wat dit geskep het.

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

As die eenheid die vermoë lys en CapEff kort dit steeds, dan oorheers 'n drop-in die instelling of 'n ExecStartPre-stap verander die omgewing. Soek die drop-in-gidse vir die eenheidnaam voordat jy aanvaar die hoofleêr is gesaghebbend, want 'n latere lêer wen stilweg. As beide die eenheid en die proses die vermoë wys en die tonnel steeds misluk, gaan terug na die toestel- en padkontroles eerder as om die begrensende stel te verbreed. Om dit te verbreed verberg die werklike oorsaak en laat die diens meer bevoorreg as tevore.

Verkies om voorregte ná die opstart te laat val

OpenVPN kan met voorregte begin en dan na 'n onbevoorregte rekening oorskakel deur sy eie user- en group-opsies, terwyl persist-key en persist-tun die tonnel daarna bruikbaar hou. Daardie reëling vernou die venster waarin die proses regte hou, en dit pas dikwels beter as om die hele daemon onbevoorreg met permanente vermoëns te begin.

Watter model jy ook kies, herbegin die eenheid en herhaal die kontroles ná 'n herbegin, want 'n diens wat uit 'n interaktiewe wortelskulp werk en by die opstart misluk, is gewoonlik 'n verskil in vermoë, toestel of lêertoestemming. Teken die eenheidinstellings langs die proses se vermoë-uitvoer aan, sodat die volgende keurder kan sien of 'n pakketopdatering of 'n drop-in die grens verskuif het.