Matapos ibaba ang mga pribilehiyo: aling mga file ng OpenVPN ang gumagana pa?

Ang mahabang uptime ay nagpapatunay lamang na nagtagumpay ang pagsisimula sa mga pribilehiyong mayroon ang daemon sa sandaling iyon. Ang mga pagkabigo na mahalaga dito ay dumarating mamaya: may kumokonek na bagong kliyente, pinapalitan ang listahan ng pagbawi, kailangang magsulat ng file ang isang katulong na script. Bawat isa sa mga ito ay bagong pagbukas na ginagawa ng account na walang pribilehiyo, kasama ang sarili nitong tanong sa pahintulot at sarili nitong mensahe ng error. Tatlong desisyon ang naghihiwalay sa setup na patuloy na gumagana mula sa isa na bigo sa susunod na pangyayari.

Ihiwalay ang na-load nang maaga sa binubuksan mamaya

Ang deskriptor ay isang hawakan sa bukas na paglalarawan ng file, at ang paraan ng pag-access ay itinakda nang ginawa ang paglalarawang iyon. Ang pagpalit ng user ng proseso mamaya ay hindi nagsasara ng hawakan, kaya ang key file na binasa bilang root ay patuloy na gumagana pagkatapos ng pagbaba. Hindi rin nagbabago ang mode: ang hawakang binuksan para sa pagbasa ay hindi nagiging maisusulat, at ang maisusulat na hawakan ay hindi binawi dahil lamang nawala ang mga karapatan ng account sa landas. Ang dalawang katotohanang ito ang nagpapaliwanag sa halos lahat ng nakakagulat na pag-uugali sa mga ulat na ito.

Ang kabilang kalahati ay memorya. Maaaring suriin ng daemon ang isang sertipiko, itago ang nasuring materyal at isara ang file; ang nananatili sa paggamit ay data, hindi bukas na file. Kaya ang patuloy na trapiko ay hindi nagpapatunay na bukas ang isang deskriptor o na naaabot ang pangalan ng landas. Nagpapatunay lamang ito na ang materyal na kailangan para sa kasalukuyang sesyon ay nakuha noong una.

Ang pagbukas mamaya ay ibang transaksyon. Tumatakbo ito sa ilalim ng kasalukuyang mga kredensyal, kasalukuyang konteksto ng seguridad at kasalukuyang tanawin ng pag-mount, kaya ang landas na nababasa sa pagsisimula ay maaaring tanggihan sa susunod na koneksyon. Nagdaragdag ng bitag ang pag-ikot: ang pagsulat ng bagong file sa parehong pangalan ng landas ay nag-iiwan ng umiiral na deskriptor na nakakabit sa lumang bagay, kaya ang muling pag-load ay maaaring magmukhang matagumpay habang ginagamit pa rin ng daemon ang dating nilalaman. Ihambing ang inode na hawak ng proseso sa nasa disk bago maniwala sa isang pag-ikot.

Pangalanan ang tatlong pagbasa sa runtime at kung kailan nangyayari ang bawat isa

Tatlong mapagkukunan ang karaniwang binubuksan nang matagal pagkatapos ng initialization, at nabibigo sila sa magkaibang sandali. Ang configuration file ng isang partikular na kliyente ay binabasa kapag kumokonek ang kliyenteng iyon, kaya maaari itong masira para sa isang user habang nagpapatuloy ang iba. Ang data ng pagbawi ay tinitingnan sa panahon ng pagpapatunay ng kapares at muli kapag pinapalitan ang file. Ang pansamantalang direktoryo ay hinahawakan lamang kapag may isinulat ang script o plugin.

Wala sa tatlo ang kabilang sa landas ng pagsisimula, kaya ang server na malusog nang ilang linggo ay maaaring mabigo sa susunod na koneksyon. Pinangalanan din ng kategorya ang may-ari ng pagwawasto: ang unang dalawa ay mga pahintulot sa pagbasa sa configuration sa ilalim ng account ng daemon, at ang pangatlo ay isang lugar na maisusulat na may makitid na layunin.

persist-key sumasagot sa mas makitid na tanong kaysa inaakala ng karamihan. Pinapanatili nitong bukas ang key file sa mga dokumentadong reset ng SIGUSR1 at ping-restart, at wala itong ginagawa para sa mga CCD file, data ng pagbawi, katulong na executable o buong muling pagsisimula ng proseso. Ang mga iyon ay sumusunod pa rin sa kanilang sariling mga landas ng pagbukas, sa ilalim ng alinmang account na tumatakbo sa sandaling iyon.

Kumpirmahin ang account at ang tanawin na talagang mayroon ito

Tanungin ang tumatakbong daemon kung aling account ang ginagamit nito sa halip na magtiwala sa unit file, pagkatapos ay ihambing ang sagot sa itinatakda ng unit. Ang pagkakaiba ang unang dapat lutasin, dahil ang bawat susunod na pagsusuri ng pahintulot ay tumatakbo bilang kung sino talaga ang proseso. Pagkatapos ay lakarin ang landas komponente bawat komponente; ang pagtawid ay sinusuri sa bawat antas, kaya ang nababasang file sa loob ng direktoryong hindi matawid ay nananatiling hindi nababasa. Ang huling mode ng file ay ang huling tanong, hindi ang una.

Ang mga namespace at service sandbox ay nagdaragdag ng mga hangganan na hindi inilalarawan ng pagmamay-ari at mga bit ng mode. Ang landas na nakikita sa iyong shell ay maaaring wala o basahin lamang sa loob ng chroot, mount namespace o unit na nagtatago ng mga home directory. Ang mga module ng seguridad ay nagdaragdag ng isa pang patong, kaya ang file na mukhang nababasa ay maaari pa ring tanggihan kapag binuksan.

ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/alice

Ang matagumpay na pagbasa sa shell ng administrator ay hindi sumusubok sa alinman sa mga pinagsamang kondisyong iyon. Patakbuhin ang pagsusuri bilang account ng daemon, kasama ang parehong namespace at sandbox, o tanggapin na inilalarawan ng resulta ang iyong shell at hindi ang server. Ang ikatlong utos ay ang murang bersyon ng pagsubok na iyon: ipinapakita nito ang mode ng bawat komponente at nabibigo sa unang hindi kayang tawirin ng account ng daemon.

Bigyan ng sariling direktoryo ang pagsulat sa runtime

Ang pagbasa ay kalahati lamang ng imbentaryo. Maaaring kailangan ng katulong na script na lumikha ng status file, maaaring kailangan ng plugin na magsulat ng estado sa tabi ng configuration nito, at ang mga pagsusulat na iyon ay hindi sakop ng paggawa sa puno ng configuration na maisusulat. Bigyan ang partikular na direktoryo ng pahintulot sa pagsulat na kailangan ng tungkulin nito, kasama ang may-ari at mode na maipapaliwanag mo. Piliin ang pag-access na basahin lamang para sa lahat ng binabasa lamang.

Panatilihing hiwalay ang mga pahintulot ng pribadong key sa mga patakaran file. Ang key na dapat muling basahin pagkatapos ng reset ay may ibang pangangailangan kaysa sa client file na binabasa sa bawat koneksyon, at ang isang maluwag na mode para sa dalawa ay nagbibigay ng higit na pag-access kaysa hinihingi ng problema. Ang dedikadong account ng daemon na may makitid na pagmamay-ari ay mas madaling i-audit kaysa malawak na grupo. Kapag ang key ay kailangang mabuhay sa mga reset, persist-key inatatanggal nito ang muling pagbasa sa halip na palawakin ang direktoryo.

Magpasya mula sa pangyayaring kaya mong ulitin

Ang buhay na tunnel ay nagpapatunay ng isang landas sa code. Ang pangyayaring nangangailangan ng file ang tanging pagsubok na sumasaklaw sa pagbukas na mahalaga sa iyo, maging ito ay bagong koneksyon ng kliyente, pinalitang file ng pagbawi, pinahintulutang malambot na reset o planadong muling pagsisimula. Piliin ang pangyayari, patakbuhin ito, at itago ang unang error sa halip na ang huli.

Para sa malambot na reset, isang senyales at ang log ng unit ang nagpapakita kung muling binasa ang key. Ipadala ang senyales, pagkatapos ay basahin ang mga huling linyang isinulat ng unit:

systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pager

Huwag tapusin na ang komprometidong daemon ay hindi na makakapagbago ng mga file dahil lamang ibinaba ang mga pribilehiyo. Ang kaya pa nitong gawin ay nakasalalay sa natitirang mga kredensyal, kakayahan nito, mga direktoryong maisusulat nito at anumang maisusulat na deskriptor na hawak pa nito. Ang pagbaba ng pribilehiyo ay nagpapakitid ng awtoridad, at ang imbentaryo ng mga pagbukas sa runtime ang nagpapakita kung gaano. Isulat ang hangganang iyon sa tabi ng configuration upang hindi na kailangang muling tuklasin ito ng susunod na tao.