T'i japësh OpenVPN CAP_NET_ADMIN pa i dhënë root

Shërbimi niset, regjistri ankohet se nuk mund të hapë pajisjen tun, dhe rrugët nuk shfaqen kurrë. Ekzekutoni capsh --print në shell-in tuaj dhe cap_net_admin është pikërisht aty, gjë që e bën dështimin të pamundur. Ajo që ndryshon midis shell-it tuaj dhe unitit është kalimi i privilegjeve, jo gatishmëria e kernelit për të dhënë aftësinë. Kaloni nëpër katër kontrollet më poshtë me radhë dhe ndaloni tek i pari që shpjegon hendekun.

Ndani një aftësi që mungon nga një pajisje e fshehur

Dy dështime duken njësoj nga rreshti i regjistrit. Një proces pa CAP_NET_ADMIN nuk mund të krijojë ose konfigurojë ndërfaqen e tunelit, dhe një proces, sandbox-i i të cilit fsheh /dev/net/tun, nuk mund ta hapë fare. Shtimi i aftësive nuk do ta rregullojë rastin e dytë.

Kontrolloni nëse pajisja ekziston brenda hapësirës së emrave të shërbimit përpara se të ndryshoni çdo gjë. PrivateDevices=yes është një rresht i zakonshëm forcimi që heq plotësisht nyjen tun, dhe një ProtectSystem kufizues mund ta bëjë rrugën e konfigurimit vetëm-lexim në një mënyrë që lexohet si gabim lejeje. Të dyja prodhojnë rreshta regjistri që përmendin tunelin, prandaj fajësohen aftësitë. Konfirmoni së pari se nyja është e pranishme dhe e hapshme, pastaj vazhdoni.

Dijeni se cilën grup aftësish po shikoni

Linux mban grupet e lejuara, efektive, të trashëguara, kufizuese dhe mjedisore, dhe grupi mjedisor është ai që i mbijeton një exec nga një përdorues që nuk është root. Aftësitë e skedarit në binar mund të transferojnë të drejta të lejuara dhe efektive në exec, por vetëm për sa kohë që asgjë në zinxhir nuk e bllokon atë transferim.

Këtu sudo i çorienton njerëzit. Një komandë e ekzekutuar përmes sudo -u fillon një kalim të ri privilegjesh dhe grupi mjedisor zhduket, kështu që i njëjti kontroll që ka sukses si root dështon atje. Menaxheri i shërbimeve është edhe një kalim tjetër dhe nuk jep asgjë mjedisore nëse uniti nuk e thotë.

Jepeni aftësinë në unit, jo në një mbështjellës

Një seksion minimal shërbimi për një tunel që duhet të krijojë një pajisje dhe të instalojë rrugë lexohet kështu.

[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 e vendos të drejtën në grupin mjedisor përpara se procesi të niset, dhe CapabilityBoundingSet e pengon procesin të mbajë diçka jashtë atij listi. NoNewPrivileges=yes bllokon fitimin e privilegjeve përmes setuid ose aftësive të skedarit, ndërsa aftësia që uniti jep në mënyrë eksplicite vazhdon të zbatohet. Shtoni CAP_NET_BIND_SERVICE vetëm kur shërbimi duhet të lidhë një port të ulët, dhe mos shtoni kurrë CAP_SYS_ADMIN vetëm sepse një temë forumi e bëri.

Nëse uniti e mbështjell binarin në sudo, hiqni mbështjellësin. systemd tashmë zbaton User=, dhe ai shtresë shtesë është arsyeja më e mundshme që grupi mjedisor është bosh.

Verifikoni ndaj procesit të gjallë, jo ndaj skedarit të unitit

Lexoni çfarë ka zbatuar vërtet menaxheri, pastaj lexoni procesin që ka krijuar.

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

Nëse uniti liston aftësinë dhe CapEff ende nuk e ka, një drop-in po anashkalon cilësimin ose një hap ExecStartPre po ndryshon mjedisin. Kërkoni emrin e unitit në drejtoritë drop-in përpara se të supozoni se skedari kryesor është autoritar, sepse një skedar më i vonë fiton në heshtje. Nëse edhe uniti edhe procesi e shfaqin aftësinë dhe tuneli ende dështon, kthehuni te kontrollet e pajisjes dhe të rrugës në vend që të zgjeroni grupin kufizues. Zgjerimi i tij e fsheh shkakun e vërtetë dhe e lë shërbimin më të privilegjuar se më parë.

Preferoni të hiqni dorë nga privilegjet pas nisjes

OpenVPN mund të niset me privilegje dhe pastaj të zbresë në një llogari pa privilegje përmes opsioneve të veta user dhe group, ndërsa persist-key dhe persist-tun e mbajnë tunelin të përdorshëm më pas. Kjo rregullim e ngushton dritaren në të cilën procesi mban të drejta, dhe shpesh përshtatet më mirë sesa nisja e të gjithë demonit pa privilegje me aftësi të përhershme.

Cilindo model që zgjidhni, rinisni unitin dhe përsëritni kontrollet pas një rinisjeje, sepse një shërbim që funksionon nga një shell root interaktiv dhe dështon në nisje është zakonisht një ndryshim në aftësi, pajisje ose leje skedari. Shënoni cilësimet e unitit pranë daljes së aftësive të procesit, që rishikuesi i radhës të shohë nëse një përditësim pakete ose një drop-in e ka zhvendosur kufirin.