Dajte OpenVPN CAP_NET_ADMIN bez davanja roota

Servis se pokreće, log se žali da ne može otvoriti tun uređaj, a rute se nikad ne pojave. Pokrenite capsh --print u svom shellu i cap_net_admin je odmah tu, zbog čega kvar izgleda nemoguć. Ono što se razlikuje između vašeg shella i unita jest prijelaz privilegija, a ne spremnost kernela da dodijeli sposobnost. Prođite kroz četiri provjere ispod redom i zaustavite se na prvoj koja objašnjava razliku.

Odvojite nedostajuću sposobnost od skrivenog uređaja

Dva kvara izgledaju isto iz log linije. Proces bez CAP_NET_ADMIN ne može stvoriti ni konfigurirati sučelje tunela, a proces čiji sandbox skriva /dev/net/tun ne može ga otvoriti od samog početka. Dodavanje sposobnosti neće popraviti drugi slučaj.

Provjerite postoji li uređaj unutar namespacea servisa prije nego bilo što uredite. PrivateDevices=yes je uobičajena linija očvršćivanja koja potpuno uklanja tun čvor, a restriktivni ProtectSystem može putanju konfiguracije učiniti samo za čitanje na način koji se čita kao greška dopuštenja. Oboje daje log linije koje spominju tunel, zbog čega se krivnja pripisuje sposobnostima. Prvo potvrdite da je čvor prisutan i da se može otvoriti, pa nastavite.

Znajte koji skup sposobnosti gledate

Linux drži dopušteni, efektivni, nasljedni, granični i ambijentalni skup, a ambijentalni skup je onaj koji preživi exec od strane korisnika koji nije root. Datotečne sposobnosti na binarnoj datoteci mogu predati dopuštena i efektivna prava pri exec, ali samo dok ništa u lancu ne blokira taj prijenos.

Tu sudo zavodi ljude. Naredba pokrenuta kroz sudo -u započinje novi prijelaz privilegija i ambijentalni skup nestaje, pa ista provjera koja uspijeva kao root tamo pada. Upravitelj servisa je opet drugi prijelaz i ne daje ništa ambijentalno ako unit to ne kaže.

Dajte sposobnost u unitu, ne u omotaču

Minimalni odjeljak servisa za tunel koji treba stvoriti uređaj i instalirati rute izgleda ovako.

[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 stavlja pravo u ambijentalni skup prije nego se proces pokrene, a CapabilityBoundingSet sprječava proces da drži bilo što izvan tog popisa. NoNewPrivileges=yes blokira stjecanje privilegija kroz setuid ili datotečne sposobnosti, dok se sposobnost koju unit izričito daje i dalje primjenjuje. Dodajte CAP_NET_BIND_SERVICE samo kad servis mora vezati nizak port, i nikad ne dodajte CAP_SYS_ADMIN samo zato što je neka forumska tema to učinila.

Ako unit zamotava binarnu datoteku u sudo, uklonite omotač. systemd već primjenjuje User=, a taj dodatni sloj je najvjerojatniji razlog zašto je ambijentalni skup prazan.

Provjeravajte prema živom procesu, ne prema datoteci unita

Pročitajte što je upravitelj stvarno primijenio, pa pročitajte proces koji je pokrenuo.

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

Ako unit navodi sposobnost a CapEff je još nema, neki drop-in nadjačava postavku ili korak ExecStartPre mijenja okruženje. Pretražite drop-in direktorije za ime unita prije nego pretpostavite da je glavna datoteka mjerodavna, jer kasnija datoteka tiho pobjeđuje. Ako i unit i proces pokazuju sposobnost a tunel i dalje pada, vratite se provjerama uređaja i putanje umjesto da širite granični skup. Njegovo širenje skriva pravi uzrok i ostavlja servis privilegiranijim nego što je bio.

Radije spustite privilegije nakon pokretanja

OpenVPN može krenuti s privilegijama i zatim se spustiti na neprivilegovani račun kroz vlastite opcije user i group, dok persist-key i persist-tun zadržavaju tunel upotrebljivim nakon toga. Takav raspored sužava prozor u kojem proces drži prava i često je bolji od pokretanja cijelog daemona neprivilegirano s trajnim sposobnostima.

Koji god model odabrali, ponovno pokrenite unit i ponovite provjere nakon ponovnog podizanja sustava, jer servis koji radi iz interaktivnog root shella a pada pri podizanju obično je razlika u sposobnosti, uređaju ili dopuštenjima datoteke. Zapišite postavke unita uz izlaz sposobnosti procesa kako bi sljedeći recenzent vidio je li ažuriranje paketa ili drop-in pomaknulo granicu.