Dot OpenVPN CAP_NET_ADMIN, nepiešķirot tam root

Pakalpojums startē, žurnāls sūdzas, ka nevar atvērt tun ierīci, un maršruti nekad neparādās. Palaidiet capsh --print savā čaulā, un cap_net_admin ir tepat, kas padara kļūdu šķietami neiespējamu. Tas, kas atšķiras starp jūsu čaulu un vienību, ir privilēģiju pāreja, nevis kodola gatavība piešķirt spēju. Iziet četras pārbaudes zemāk pēc kārtas un apstājieties pie pirmās, kas izskaidro starpību.

Atdaliet trūkstošo spēju no apslēptas ierīces

Divi defekti žurnāla rindā izskatās vienādi. Process bez CAP_NET_ADMIN nevar izveidot vai konfigurēt tuneļa saskarni, un process, kura smilškaste slēpj /dev/net/tun, to nemaz nevar atvērt. Spēju pievienošana otro gadījumu neizlabos.

Pirms kaut ko rediģējat, pārbaudiet, vai ierīce pastāv pakalpojuma nosaukumtelpā. PrivateDevices=yes ir izplatīta nocietināšanas rinda, kas pilnībā noņem tun mezglu, un ierobežojošs ProtectSystem var padarīt konfigurācijas ceļu tikai lasāmu tā, ka tas lasās kā atļauju kļūda. Abi rada žurnāla rindas, kas piemin tuneli, tāpēc vaina tiek uzlikta spējām. Vispirms apstipriniet, ka mezgls ir un to var atvērt, pēc tam ejiet tālāk.

Ziniet, uz kuru spēju kopu jūs skatāties

Linux uztur atļauto, efektīvo, mantojamo, ierobežojošo un apkārtējo kopu, un apkārtējā kopa ir tā, kas pārdzīvo ne root lietotāja exec. Faila spējas uz binārā faila var nodot atļautās un efektīvās tiesības exec laikā, bet tikai tik ilgi, kamēr nekas ķēdē nebloķē šo nodošanu.

Šeit sudo maldina cilvēkus. Komanda, kas palaista caur sudo -u, sāk jaunu privilēģiju pāreju un apkārtējā kopa pazūd, tāpēc tā pati pārbaude, kas izdodas kā root, tur neizdodas. Pakalpojumu pārvaldnieks ir vēl cita pāreja, un tas nepiešķir neko apkārtēju, ja vien vienība tā nesaka.

Piešķiriet spēju vienībā, nevis ietvarā

Minimāla pakalpojuma sadaļa tunelim, kuram jāizveido ierīce un jāinstalē maršruti, izskatās šādi.

[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 ievieto tiesības apkārtējā kopā pirms procesa starta, un CapabilityBoundingSet neļauj procesam turēt kaut ko ārpus šī saraksta. NoNewPrivileges=yes bloķē privilēģiju iegūšanu caur setuid vai faila spējām, kamēr vienības skaidri piešķirtā spēja joprojām darbojas. Pievienojiet CAP_NET_BIND_SERVICE tikai tad, kad pakalpojumam jāsaista zems ports, un nekad nepievienojiet CAP_SYS_ADMIN tikai tāpēc, ka kāda foruma tēma tā izdarīja.

Ja vienība ietin bināro failu sudo, noņemiet ietvaru. systemd jau piemēro User=, un šis papildu slānis ir visticamākais iemesls, kāpēc apkārtējā kopa ir tukša.

Pārbaudiet pret dzīvo procesu, nevis vienības failu

Izlasi, ko pārvaldnieks faktiski piemēroja, tad izlasi procesu, ko tas radīja.

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

Ja vienība uzskaita spēju un CapEff tās joprojām nav, kāds drop-in ignorē iestatījumu vai ExecStartPre solis maina vidi. Pirms uzskatīt galveno failu par autoritatīvu, meklējiet vienības nosaukumu drop-in mapēs, jo vēlāks fails klusi uzvar. Ja gan vienība, gan process rāda spēju un tunelis joprojām nedarbojas, atgriezieties pie ierīces un ceļa pārbaudēm, nevis paplašiniet ierobežojošo kopu. Tās paplašināšana slēpj īsto iemeslu un atstāj pakalpojumu privilēģētāku nekā tas bija.

Labāk atsakieties no privilēģijām pēc starta

OpenVPN var startēt ar privilēģijām un pēc tam pāriet uz neprivileģētu kontu, izmantojot savas user un group opcijas, kamēr persist-key un persist-tun uztur tuneli lietojamu arī pēc tam. Šāda kārtība sašaurina logu, kurā procesam ir tiesības, un tā bieži ir piemērotāka nekā visas dēmona palaišana bez privilēģijām ar pastāvīgām spējām.

Lai kādu modeli izvēlētos, restartējiet vienību un atkārtojiet pārbaudes pēc pārstartēšanas, jo pakalpojums, kas darbojas no interaktīvas root čaulas un neizdodas palaišanas laikā, parasti ir spējas, ierīces vai faila atļauju atšķirība. Pierakstiet vienības iestatījumus blakus procesa spēju izvadei, lai nākamais recenzents redzētu, vai pakotnes atjauninājums vai drop-in ir pārvietojis robežu.