Gi OpenVPN CAP_NET_ADMIN utan å gi det root

Tenesta startar, loggen klagar på at han ikkje kan opne tun-eininga, og ruter dukkar aldri opp. Køyr capsh --print i skalet ditt, og cap_net_admin er rett der, noko som gjer feilen umogeleg å forklare. Det som skil skalet ditt frå uniten er privilegieovergangen, ikkje viljen til kjernen til å gi kapabiliteten. Gå gjennom dei fire kontrollane nedanfor i rekkjefølgje og stopp ved den første som forklarer skilnaden.

Skil ein manglande kapabilitet frå ei skjult eining

To feil ser like ut i logglinja. Ein prosess utan CAP_NET_ADMIN kan ikkje opprette eller konfigurere tunellgrensesnittet, og ein prosess der sandkassa skjuler /dev/net/tun kan ikkje opne det i det heile. Å leggje til kapabilitetar rettar ikkje det andre tilfellet.

Kontroller om eininga finst inne i namnerommet til tenesta før du endrar noko. PrivateDevices=yes er ei vanleg herdingslinje som fjernar tun-noden heilt, og ein restriktiv ProtectSystem kan gjere konfigurasjonsstien skriveverna på ein måte som blir lesen som ein tilgangsfeil. Begge gir logglinjer som nemner tunnelen, og difor får kapabilitetane skulda. Stadfest først at noden finst og kan opnast, og gå så vidare.

Vit kva kapabilitetssett du ser på

Linux held permiterte, effektive, arvbake, avgrensande og ambiente sett, og det ambiente settet er det som overlever ein exec frå ein brukar som ikkje er root. Filkapabilitetar på binæra kan overlevere permiterte og effektive rettar ved exec, men berre så lenge ingenting i kjeda blokkerer den overføringa.

Det er her sudo villeder folk. Ein kommando som blir køyrd gjennom sudo -u, startar ein ny privilegieovergang og det ambiente settet er borte, så den same kontrollen som lukkast som root feilar der. Tenestebehandsamaren er nok ein overgang, og han gir ingenting ambient med mindre uniten seier det.

Gi kapabiliteten i uniten, ikkje i ein wrapper

Ein minimal tenesteseksjon for ein tunell som må opprette ei eining og installere ruter ser slik ut.

[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 set retten i det ambiente settet før prosessen startar, og CapabilityBoundingSet hindrar prosessen i å halde noko utanfor den lista. NoNewPrivileges=yes blokkerer privilegieoppnåing gjennom setuid eller filkapabilitetar, medan kapabiliteten uniten gir uttrykkeleg, framleis gjeld. Legg berre til CAP_NET_BIND_SERVICE når tenesta må binde ein låg port, og legg aldri til CAP_SYS_ADMIN berre fordi ein forumtråd gjorde det.

Viss uniten pakkar binæra inn i sudo, fjern wrapperen. systemd brukar allereie User=, og det ekstra laget er den mest sannsynlege grunnen til at det ambiente settet er tomt.

Verifiser mot den levande prosessen, ikkje unitfila

Les kva handsamaren faktisk brukte, og les deretter prosessen han starta.

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

Viss uniten listar kapabiliteten og CapEff framleis manglar han, overstyrer ein drop-in innstillinga eller eit ExecStartPre-steg endrar miljøet. Søk i drop-in-katalogane etter unitnamnet før du går ut frå at hovudfila er autoritativ, fordi ei seinare fil vinn i stillheit. Viss både uniten og prosessen viser kapabiliteten og tunnelen framleis feilar, gå tilbake til eining- og stikontrollane i staden for å utvide det avgrensande settet. Å utvide det skjuler den eigentlege årsaka og lèt tenesta stå att med meir privilegium enn ho hadde.

Føretrekk å sleppe privilegia etter oppstart

OpenVPN kan starte med privilegium og deretter gå over til ein uprivilegert konto via sine eigne user- og group-val, medan persist-key og persist-tun held tunnelen brukbar etterpå. Den ordninga snevrar inn vindauget der prosessen har rettar, og ho passar ofte betre enn å starte heile daemonen uprivilegert med permanente kapabilitetar.

Uansett kva modell du vel, start uniten på nytt og gjer kontrollane om att etter ein omstart, fordi ei teneste som verkar frå eit interaktivt root-skal og feilar ved oppstart, vanlegvis er ein skilnad i kapabilitet, eining eller filrettar. Noter unitinnstillingane ved sida av kapabilitetsutdata frå prosessen, slik at neste gjennomgåar ser om ei pakkeoppdatering eller ein drop-in har flytta grensa.