Palvelu käynnistyy, loki valittaa, ettei se voi avata tun-laitetta, eivätkä reitit koskaan ilmesty. Suorita capsh --print omassa kuoressasi, ja cap_net_admin on heti siinä, mikä saa virheen näyttämään mahdottomalta. Se, mikä eroaa kuoresi ja yksikön välillä, on etuoikeuksien siirtymä, ei ytimen halukkuus myöntää kyvykkyys. Käy alla olevat neljä tarkistusta järjestyksessä läpi ja pysähdy ensimmäiseen, joka selittää eron.

Erota puuttuva kyvykkyys piilotetusta laitteesta

Kaksi virhettä näyttävät lokiriviltä samalta. Prosessi ilman CAP_NET_ADMIN ei voi luoda tai määrittää tunneliliitäntää, eikä prosessi, jonka hiekkalaatikko piilottaa /dev/net/tun, voi avata sitä lainkaan. Kyvykkyyksien lisääminen ei korjaa toista tapausta.

Tarkista, onko laite palvelun nimiavaruudessa, ennen kuin muokkaat mitään. PrivateDevices=yes on yleinen koventamisrivi, joka poistaa tun-solmun kokonaan, ja rajoittava ProtectSystem voi tehdä asetustiestä vain luku -kelpoisen tavalla, joka luetaan käyttöoikeusvirheeksi. Molemmat tuottavat lokirivejä, jotka mainitsevat tunnelin, ja siksi kyvykkyyksiä syytetään. Vahvista ensin, että solmu on olemassa ja avattavissa, ja jatka sitten.

Tiedä, mitä kyvykkyysjoukkoa katsot

Linux pitää sallitun, tehokkaan, perittävän, rajaavan ja ympäristön joukon, ja ympäristön joukko on se, joka säilyy muun kuin root-käyttäjän execistä. Binäärin tiedostokyvykkyydet voivat luovuttaa sallitut ja tehokkaat oikeudet execissä, mutta vain niin kauan kuin mikään ketjussa ei estä siirtoa.

Tässä sudo johtaa ihmisiä harhaan. sudo -u:n kautta ajettu komento aloittaa uuden etuoikeuksien siirtymän ja ympäristön joukko katoaa, joten sama tarkistus, joka onnistuu rootina, epäonnistuu siellä. Palvelunhallinta on vielä yksi siirtymä, eikä se myönnä mitään ympäristön osalta, ellei yksikkö kerro sitä.

Myönnä kyvykkyys yksikössä, ei kääreessä

Minimaalinen palveluosio tunnelille, jonka täytyy luoda laite ja asentaa reitit, näyttää tältä.

[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 asettaa oikeuden ympäristön joukkoon ennen prosessin käynnistymistä, ja CapabilityBoundingSet estää prosessia pitämästä mitään tuon luettelon ulkopuolella. NoNewPrivileges=yes estää etuoikeuksien hankkimisen setuidin tai tiedostokyvykkyyksien kautta, kun taas kyvykkyys, jonka yksikkö nimenomaisesti myöntää, pätee edelleen. Lisää CAP_NET_BIND_SERVICE vain, kun palvelun on sidottava matala portti, äläkä koskaan lisää CAP_SYS_ADMIN vain siksi, että jokin foorumiketju teki niin.

Jos yksikkö käärii binäärin sudo:ään, poista kääre. systemd soveltaa jo User=:ttä, ja tuo ylimääräinen kerros on todennäköisin syy siihen, että ympäristön joukko on tyhjä.

Tarkista elävää prosessia vasten, ei yksikkötiedostoa

Lue, mitä hallinta todella sovelsi, ja lue sitten prosessi, jonka se synnytti.

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

Jos yksikkö luettelee kyvykkyyden ja CapEff:ltä se silti puuttuu, jokin drop-in ohittaa asetuksen tai ExecStartPre-vaihe muuttaa ympäristöä. Etsi yksikön nimi drop-in-hakemistoista ennen kuin oletat päätiedoston olevan määräävä, koska myöhempi tiedosto voittaa hiljaa. Jos sekä yksikkö että prosessi näyttävät kyvykkyyden ja tunneli silti epäonnistuu, palaa laite- ja polkutarkistuksiin sen sijaan, että laajennat rajaavaa joukkoa. Sen laajentaminen kätkee todellisen syyn ja jättää palvelun etuoikeutetummaksi kuin ennen.

Suosi etuoikeuksista luopumista käynnistyksen jälkeen

OpenVPN voi käynnistyä etuoikeutettuna ja laskeutua sitten omien user- ja group-valintojensa kautta vailla etuoikeuksia olevaan tiliin, kun persist-key ja persist-tun pitävät tunnelin sen jälkeen käyttökelpoisena. Tämä järjestely kaventaa ikkunaa, jossa prosessilla on oikeuksia, ja sopii usein paremmin kuin koko daemonin käynnistäminen ilman etuoikeuksia pysyvillä kyvykkyyksillä.

Minkä mallin valitsetkin, käynnistä yksikkö uudelleen ja toista tarkistukset uudelleenkäynnistyksen jälkeen, koska palvelu, joka toimii interaktiivisesta root-kuoresta ja epäonnistuu käynnistyksessä, on yleensä ero kyvykkyydessä, laitteessa tai tiedosto-oikeuksissa. Kirjaa yksikön asetukset prosessin kyvykkyystulosteen viereen, jotta seuraava arvioija näkee, siirsikö pakettipäivitys vai drop-in rajaa.

Aiheeseen liittyvät artikkelit