Suteikti OpenVPN CAP_NET_ADMIN be root teisių

Paslauga paleidžiama, žurnalas skundžiasi, kad negali atidaryti tun įrenginio, o maršrutai niekada neatsiranda. Paleiskite capsh --print savo shell'e ir cap_net_admin yra čia pat, todėl gedimas atrodo neįmanomas. Tai, kas skiriasi tarp jūsų shell'o ir unit, yra privilegijų perėjimas, o ne branduolio noras suteikti gebėjimą. Atlikite keturis patikrinimus žemiau iš eilės ir sustokite ties pirmuoju, kuris paaiškina skirtumą.

Atskirkite trūkstamą gebėjimą nuo paslėpto įrenginio

Du gedimai iš žurnalo eilutės atrodo vienodai. Procesas be CAP_NET_ADMIN negali sukurti ar sukonfigūruoti tunelio sąsajos, o procesas, kurio smėlio dėžė slepia /dev/net/tun, jo iš viso negali atidaryti. Gebėjimų pridėjimas antrojo atvejo nepataisys.

Prieš ką nors redaguodami patikrinkite, ar įrenginys egzistuoja paslaugos vardų erdvėje. PrivateDevices=yes yra įprasta grūdinimo eilutė, visiškai pašalinanti tun mazgą, o ribojantis ProtectSystem gali padaryti konfigūracijos kelią tik skaitomu taip, kad tai skaitosi kaip leidimų klaida. Abu sukuria žurnalo eilutes, kuriose minimas tunelis, todėl kaltė verčiama gebėjimams. Pirmiausia patvirtinkite, kad mazgas yra ir jį galima atidaryti, tada eikite toliau.

Žinokite, į kurį gebėjimų rinkinį žiūrite

Linux laiko leidžiamų, efektyviųjų, paveldimųjų, ribojančių ir aplinkos rinkinius, o aplinkos rinkinys yra tas, kuris išlieka po ne root naudotojo exec. Byla susieti gebėjimai binariniame faile gali perduoti leidžiamas ir efektyviąsias teises exec metu, bet tik tol, kol niekas grandinėje netrukdo tam perdavimui.

Čia sudo klaidina žmones. Komanda, paleista per sudo -u, pradeda naują privilegijų perėjimą ir aplinkos rinkinys dingsta, todėl ta pati patikra, kuri pavyksta kaip root, ten nepavyksta. Paslaugų tvarkyklė yra dar kitas perėjimas, ir ji nieko aplinkos nesuteikia, nebent unit taip sako.

Suteikite gebėjimą unite, o ne apvalkale

Minimali paslaugos sekcija tuneliui, kuriam reikia sukurti įrenginį ir įdiegti maršrutus, atrodo taip.

[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 įdeda teisę į aplinkos rinkinį prieš procesui prasidedant, o CapabilityBoundingSet neleidžia procesui turėti ko nors už to sąrašo ribų. NoNewPrivileges=yes blokuoja privilegijų įgijimą per setuid arba failo gebėjimus, o unite aiškiai suteiktas gebėjimas vis tiek galioja. Pridėkite CAP_NET_BIND_SERVICE tik kai paslauga turi susieti žemą prievadą, ir niekada nepridėkite CAP_SYS_ADMIN vien todėl, kad forumo gija taip padarė.

Jei unit apvynioja binarinį failą į sudo, pašalinkite apvalkalą. systemd jau taiko User=, ir tas papildomas sluoksnis yra labiausiai tikėtina priežastis, kodėl aplinkos rinkinys tuščias.

Tikrinkite pagal veikiantį procesą, o ne unit failą

Perskaitykite, ką tvarkyklė iš tikrųjų pritaikė, tada perskaitykite procesą, kurį ji sukūrė.

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

Jei unit išvardija gebėjimą, o CapEff jo vis dar neturi, kažkoks drop-in nepaiso nustatymo arba ExecStartPre žingsnis keičia aplinką. Prieš laikydami pagrindinį failą autoritetingu, ieškokite unit pavadinimo drop-in kataloguose, nes vėlesnis failas tyliai laimi. Jei ir unit, ir procesas rodo gebėjimą, o tunelis vis tiek nepavyksta, grįžkite prie įrenginio ir kelio patikrinimų, o ne plėskite ribojantį rinkinį. Jo plėtimas paslepia tikrąją priežastį ir palieka paslaugą privilegijuotesnę nei buvo.

Pageidautina atsisakyti privilegijų po paleidimo

OpenVPN gali pradėti su privilegijomis ir tada per savo user bei group parinktis pereiti prie neprivilegijuotos paskyros, o persist-key ir persist-tun palaiko tunelį tinkamu naudoti vėliau. Tokia tvarka susiaurina langą, kuriame procesas turi teises, ir dažnai labiau tinka nei paleisti visą tarnybą be privilegijų su nuolatiniais gebėjimais.

Kad ir kokį modelį pasirinktumėte, paleiskite unit iš naujo ir pakartokite patikrinimus po perkrovimo, nes paslauga, kuri veikia iš interaktyvaus root shell'o ir nepavyksta įkrovimo metu, paprastai yra gebėjimo, įrenginio ar failo leidimų skirtumas. Užrašykite unit nustatymus prie proceso gebėjimų išvesties, kad kitas recenzentas matytų, ar paketo atnaujinimas ar drop-in pajudino ribą.