OpenVPN CAP_NET_ADMIN jaan sûnder root te jaan

De tsjinst start, it loch klaget dat it it tun-apparaat net iepenje kin, en rûtes ferskine nea. Rin capsh --print yn jo shell en cap_net_admin is der fuort, wat de flater ûnmooglik liket. Wat ferskilt tusken jo shell en de unit is de privileezje-oergong, net de reeheid fan de kernel om de kapabiliteit te jaan. Gean de fjouwer kontrôles hjirûnder yn folchoarder troch en stop by de earste dy't de kleau ferklaart.

Skied in ûntbrekkende kapabiliteit fan in ferburgen apparaat

Twa flaters lykje itselde fan de lochrigel. In proses sûnder CAP_NET_ADMIN kin de tunnel-ynterface net oanmeitsje of konfigurearje, en in proses waans sandbox /dev/net/tun ferberget kin it hielendal net iepenje. Kapabiliteiten tafoegje sil it twadde gefal net reparearje.

Kontrolearje oft it apparaat yn de nammeromte fan de tsjinst bestiet foardat jo wat bewurkje. PrivateDevices=yes is in gewoane hurdensrigel dy't de tun-knoop folslein fuorthellet, en in beheinende ProtectSystem kin it konfiguraasjepaad allinnich-lêzen meitsje op in manier dy't as in tasteanflater lêst. Beide meitsje lochrigels dy't de tunnel neame, en dêrom krije de kapabiliteiten de skuld. Befêstigje earst dat de knoop oanwêzich en iepenber is, en gean dan fierder.

Wit hokker kapabiliteitsset jo besjogge

Linux hâldt tastiene, effektive, erflike, beheinende en omjouwingssets by, en de omjouwingsset is dejinge dy't in exec troch in net-root brûker oerlibbet. Bestânskapabiliteiten op it binêre bestân kinne by exec tastiene en effektive rjochten oerdrage, mar allinnich salang't neat yn 'e keatling dy oerdracht blokkearret.

Hjir misliedt sudo minsken. In opdracht dy't fia sudo -u rint begjint in nije privileezje-oergong en de omjouwingsset is fuort, dat deselde kontrôle dy't as root slagget mislearret dêr. De tsjinstbehearder is wer in oare oergong, en hy jout neat omjouwings as de unit dat net seit.

Jou de kapabiliteit yn 'e unit, net yn in wrapper

In minimale tsjinstseksje foar in tunnel dy't in apparaat oanmeitsje en rûtes ynstallearje moat, lêst sa.

[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 it rjocht yn 'e omjouwingsset foardat it proses start, en CapabilityBoundingSet hâldt it proses tsjin om wat bûten dy list te hâlden. NoNewPrivileges=yes blokkearret privileezje-winst fia setuid of bestânskapabiliteiten, wylst de kapabiliteit dy't de unit eksplisyt jout noch jildt. Foegje CAP_NET_BIND_SERVICE allinnich ta as de tsjinst in lege poarte bine moat, en foegje nea CAP_SYS_ADMIN ta krekt om't in forumtried it die.

As de unit it binêre bestân yn sudo wikkelet, ferwiderje de wrapper. systemd past User= al ta, en dy ekstra laach is de wierskynlikste reden dat de omjouwingsset leech is.

Ferifiearje tsjin it libjende proses, net it unit-bestân

Lês wat de behearder eins tapast hat, en lês dan it proses dat er makke hat.

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

As de unit de kapabiliteit listet en CapEff mist him noch, dan oerhearsket in drop-in de ynstelling of in ExecStartPre-stap feroaret de omjouwing. Sykje de unitnamme yn 'e drop-in-mappen foardat jo oannimme dat it haadbestân gesachhawwend is, want in letter bestân wint stil. As sawol de unit as it proses de kapabiliteit sjen litte en de tunnel noch mislearret, gean dan werom nei de apparaat- en paadkontrôles ynstee fan de beheinende set te ferbreedzjen. Ferbreedzjen ferberget de echte oarsaak en lit de tsjinst privilezjearder efter as earder.

Ferkenne privileezjes nei it opstarten leaver ôf

OpenVPN kin mei privileezjes starte en dan fia syn eigen user- en group-opsjes oergean nei in net-privilezjeare akkount, wylst persist-key en persist-tun de tunnel dêrnei brûkber hâlde. Dy regeling fersmalt it finster wêryn't it proses rjochten hâldt, en it past faak better as de hiele daemon net-privilezjeare mei permaninte kapabiliteiten starte.

Hokker model jo ek kieze, start de unit opnij en werhelje de kontrôles nei in reboot, want in tsjinst dy't fan in ynteraktive root-shell wurket en by it opstarten mislearret is meastentiids in ferskil yn kapabiliteit, apparaat of bestânstastimming. Skriuw de unit-ynstellingen njonken de kapabiliteitsútfier fan it proses, sadat de folgjende beoardieler sjen kin oft in pakketfernijing of in drop-in de grins ferpleatst hat.