Hoe om te vind watter systemd-sandbox jou OpenVPN-haak geweier het

Die haak werk wanneer jy dit met die hand as root uitvoer en lewer Operation not permitted op die oomblik wanneer die diens dit begin. Die lêer het tussen daardie lopies nie verander nie; die omgewing het. systemd gee die proses ’n kleiner wêreld: minder vermoëns, ’n ander /dev, net-lees-lêerstelselpaaie en ’n taakplafon. Lees die mislukking as ’n grens wat een spesifieke bewerking geweier het, nie as ’n script wat gebreek het nie.

Begin by die bewerking wat geweier is

’n Logreël wat sê die eenheid het misluk, vertel jou byna niks. Die nuttige reël noem die oproep wat geweier is: ’n toestelknooppunt wat nie oopgemaak kon word nie, ’n gids wat nie geskryf kon word nie, ’n naamruimte wat nie geskep kon word nie. Vind daardie oproep voordat jy aan ’n enkele riglyn raak, want elkeen stem ooreen met ’n ander beperking. Lees dan die eenheid wat werklik geloop het, drop-ins ingesluit, eerder as die lêer wat die pakket verskaf het.

Die navraag hieronder druk die fragmentpad, die drop-in-gidse en die eienskappe wat saak maak vir ’n toestel- of lêerstelselweiering. Lees almal voordat jy besluit watter grens relevant is:

systemctl show "[email protected]" -p FragmentPath -p DropInPaths -p PrivateDevices -p DevicePolicy -p DeviceAllow -p ProtectHome -p ProtectSystem -p TasksMax
journalctl -u "[email protected]" -b --no-pager | grep -iE 'operation not permitted|permission denied|cannot open|failed'

Niks in daardie blok skryf nie. As die geweierde oproep in die joernaal ontbreek, verhoog die kliënt se breedsprakigheid vir een lopie eerder as om aan riglyne te raai. ’n Lopende proses bewys dat die eenheid begin het, nie dat die haak met die nodige voorregte geloop het nie.

’n Naamruimte benodig monteerregte wat ’n TUN-toestel nooit gebruik nie

Twee bewerkings wat binne een haak eenders lyk, het verskillende toestemmingsprofiele. Om /dev/net/tun oop te maak en die koppelvlak te skep, benodig netwerkadministrasie plus toegang tot daardie knooppunt. Om ’n benoemde netwerknaamruimte te skep, benodig ook monteerwerk, want die naamruimtegereedskap monteer ’n vars /sys aansig en bind ’n toestandgids op sy plek. Die stroomop-kliënteenheid laat monteeradministrasie doelbewus buite sy begrensingstel, so die naamruimtestap word geweier terwyl die tonnel self sou gewerk het.

Daarom red die toekenning van die toestelknooppunt nie die script nie. ’n Toesteltoelating beantwoord een vraag, of hierdie proses hierdie knooppunt mag oopmaak, en die naamruimtevraag is ’n ander een. Pas die mislukte oproep by sy vermoë voordat jy iets verbreed.

’n Toets in jou skulp erf elke vermoë wat ’n onbeperkte root het, en die eenheid erf wat sy begrensingstel behou het. Die twee lopies is verskillende eksperimente selfs wanneer die binêre lêer identies is.

Toestelle, beskermde paaie en taakplafonne

Sodra die geweierde bewerking bekend is, verduidelik drie groepe riglyne die meeste mislukkings. Toesteltoegang word beheer deur PrivateDevices, wat /dev met ’n minimale stel pseudo-toestelle vervang, en deur DevicePolicy met DeviceAllow, wat besluit wat die cgroup toelaat. /dev/net/tun is nie deel van daardie minimale stel nie, so ’n eenheid met PrivateDevices=yes kan dit nie oopmaak nie, wat die toestelbeleid ook sê.

Lêerstelselbeskerming beantwoord ’n tweede vraag. ProtectHome=yes maak /home, /root en /run/user ontoeganklik, en ProtectSystem=full maak /usr, /boot en /etc net-lees. ’n Haak wat langs sy eie konfigurasielêer skryf, werk dus in jou skulp en misluk onder die eenheid, met dieselfde toestemmingsvorm as ’n ontbrekende vermoë. Skuif die skryfbare invoer na ’n pad wat die beleid toelaat, of voeg ’n smal ReadWritePaths= inskrywing by.

Hulpbronbeperkings is die derde groep, en die minste duidelik. TasksMax= beperk hoeveel take die eenheid mag skep, en ’n lêerbeskrywer-plafon werk dieselfde vir snitte en handvatsels. ’n Ontplooiing wat verby die plafon gegroei het, misluk met ’n hulpbronfout eerder as ’n toestemmingsfout, en daarom maak die presiese boodskap steeds saak.

Skuif die naamruimtestap uit die haak

Voorbereiding wat ’n voorreg benodig wat die kliënt nie mag hê nie, hoort in sy eie eenheid. ’n Oneshot wat voor die kliënt loop, sy resultaat behou en voor die verbinding georden is, gee die naamruimtestap wat dit nodig het sonder om daardie regte aan die tonnelproses te gee. Die kliënt verwys dan na daardie eenheid eerder as om die script vanuit sy up-haak te roep.

Die sjabloon hieronder is ’n beginvorm, nie iets om ongelees toe te pas nie. Dit hou die voorbereiding waar die voorreg woon en laat die tonneleenheid ongemoeid:

# /etc/systemd/system/[email protected]
[Unit]
Description=Namespace preparation for %i
Before=openvpn-client@%i.service
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/local/sbin/netns-up.sh %i
CapabilityBoundingSet=CAP_NET_ADMIN CAP_SYS_ADMIN
[Install]
WantedBy=multi-user.target

Voeg die ordening by met ’n drop-in eerder as om die verpakte eenheid te wysig, sodat ’n opgradering jou verandering nie stilweg kan laat val nie. Die gids is aan die instansienaam gekoppel, so ’n tweede profiel benodig sy eie lêer:

sudo mkdir -p /etc/systemd/system/[email protected]
sudo tee /etc/systemd/system/[email protected]/10-namespace.conf >/dev/null <<'CONF'
[Unit]
[email protected]
[email protected]
CONF
sudo systemctl daemon-reload

Herhaal dieselfde aanroep ná die verandering

’n Herstel word slegs bevestig wanneer dieselfde aanroep ’n ander resultaat lewer. Herbegin beide eenhede, voer die bewerking uit wat misluk het, en vergelyk die uitkoms met die joernaalreël wat jy voor die verandering gestoor het. ’n Eenheid wat begin terwyl die haak nooit weer loop nie, is nie ’n herstel nie.

Die volgorde hieronder hou die vergelyking eerlik, want dit ondersoek die geweierde oproep eerder as die eenheid se kleur. Stoor sy uitset langs die joernaalreël wat jy voor die verandering vasgevang het:

sudo systemctl restart "[email protected]" "[email protected]"
systemctl status "[email protected]" --no-pager
journalctl -u "[email protected]" -b --no-pager | grep -c 'Operation not permitted'
ip -brief addr show tun0

Tel die weierings in plaas van om die laaste reël te lees, want ’n haak kan misluk, herprobeer en slaag, en net die telling wys of die grens geskuif het. Los ’n opmerking in die drop-in wat die riglyn noem wat jy verslap het en die rede, aangesien die volgende opgradering jou konfigurasie met die verpakte verstek vergelyk. ’n Eenheid wat net begin wanneer elke beskerming afgeskakel is, is nie reggemaak nie.