Huwag pagpatungin ang hardening ng systemd sa user drop ng OpenVPN

Ang dalawang recipe ng pinakamababang pribilehiyo na pinagdikit ay hindi nagbubunga ng mas mahigpit na deployment. Hinahayaan ng isang modelo ang daemon na magsimula nang may pribilehiyo at bumaba sa account na walang pribilehiyo pagkatapos ng initialization; hinahayaan ng isa pa ang service manager na patakbuhin ito sa ilalim ng limitadong pagkakakilanlan mula sa unang utos. Gumagana ang bawat isa nang mag-isa, at ang kombinasyon ay madalas na nagbubunga ng serbisyo na hindi malinis na magawa ang alinman sa dalawang gawain. Ang natitira ay dumadaan sa desisyon nang sunud-sunod.

Dalawang modelo, isang may-ari ng pagpapalit

Ang unang modelo ay pag-aari ng daemon. Ang mga opsyon ng OpenVPN sa komunidad user at group ay nagpapalit ng pagkakakilanlan pagkatapos mai-set up ang tunnel at mga key, at persist-key kasama ng persist-tun ay pinananatiling magagamit ang mga resource na iyon pagkatapos.

Ang ikalawang modelo ay pag-aari ng service manager. Ang setting ng systemd User= o Group= ang nagpapasya sa pagkakakilanlang pinagsisimulan ng proseso, at ang mga direktiba ng kakayahan ang nagpapasya kung ano ang maaaring hawakan. Ang pagpili sa pagitan ng mga modelo ay isyu ng packaging bago maging isyu ng seguridad, at nasagot na ito ng tagapangalaga ng package. Ang trabaho mo ay hanapin ang sagot na iyon sa halip na mag-imbento ng ikatlong opsyon.

Parehong lehitimo. Ang pagkakamali ay ituring ang mga ito bilang mga layer ng isang disenyo, dahil ang ikalawang modelo ay maaaring gawing operasyon na hindi na pinapayagan sa proseso ang pagpapalit ng pagkakakilanlan ng una.

Magpasya kung saan nagbabago ang pagkakakilanlan

Kung ang unit ay nagsisimula na bilang dedikadong account, ang pagdaragdag ng utos sa daemon na maging ibang account ay nangangailangan ng setuid transition na hindi dapat gawin ng isang hardened na serbisyo. Lumilitaw ang pagpalya bilang error sa pahintulot sa pagsisimula sa halip na malinaw na mensahe ng patakaran. Ito ay binabasa na parang kulang na kakayahan, na nagtutulak sa mga tao patungo sa mas malawak na set ng hangganan sa halip na sa tanong ng pagkakakilanlan.

Basahin kung ano talaga ang ibinibigay ng naka-install na package bago baguhin ang anuman, kasama ang drop-in na direktoryo nito. Ang ilang unit ay sadyang iniiwan ang sariling pagbaba ng daemon dahil pinangangasiwaan na ito ng manager, at ang iba ay umaasa sa mga opsyon na iyon para sa pagpapalit pagkatapos ng initialization. Ang pag-alis ng alinman sa dalawa nang hindi alam kung aling modelo ang namana mo ay ang paraan kung paano tumitigil sa pagsisimula ang isang gumaganang serbisyo.

Isulat ang piniling modelo sa isang linya: pag-aari ng manager o pag-aari ng daemon. Ang bawat susunod na direktiba ay dapat na naaayon sa pangungusap na iyon, at ang halo-halong unit ay dapat ituring na depekto at hindi kompromiso.

Ang mga kakayahan ay hangganan, hindi bigay

Sinasabi ng set ng hangganan ng kakayahan kung ano ang pinakamaraming maaaring hawakan ng isang proseso. Ito ay isang kisame, at ang paglista ng kakayahan doon ay walang ibinibigay sa sarili nito, kaya ang isang unit na may bukas-palad na set ng hangganan ay maaari pa ring mabigong gumawa ng tunnel.

Ang tunay na naglalagay ng kakayahan sa ambient set ng isang serbisyo ay AmbientCapabilities=. Ang reference ng pagpapatupad ng systemd ay nagdodokumento ng dalawang direktiba nang hiwalay, at ipinapaliwanag ng pagkakaibang iyon ang karamihan ng nakakalitong payo tungkol sa kakayahan online.

Magdagdag ng kakayahan lamang pagkatapos na matukoy ito ng operasyong nabibigo. Ang mas malawak na set ng hangganan ay nagtatago ng tunay na dahilan at iniiwan ang serbisyo na mas may pribilehiyo kaysa sa nilayon ng disenyo. Pinapahirapan din nito ang pagrepaso ng unit, dahil hindi na inilalarawan ng kisame ang gawain. Alisin ang dagdag na kakayahan kapag naayos na ang tunay na depekto.

Imapa ang awtoridad sa buong ikot ng buhay

Ilahad kung ano ang dapat gawin ng proseso sa bawat yugto: pagsisimula, matatag na kalagayan, muling pagpapatunay at pagtatanggal. Ang paglikha ng interface, pagbabago ng ruta, pagbasa ng protektadong key at pagtawag ng katulong ay hindi lahat nangyayari sa parehong sandali o sa ilalim ng parehong mga kinakailangan. Ayusin ang listahan ayon sa yugto bago ito ayusin ayon sa kakayahan.

Pinapanatili ng mga opsyon ng pagtitiyaga ang mga resource sa muling pakikipagkasundo, at hindi nagbibigay ng mga pahintulot na hindi kailanman hinawakan. Ang key na hindi mabasa ng proseso sa pagsisimula ay mananatiling hindi mabasa mamaya, anuman ang sabihin ng mga flag ng pagtitiyaga. Pinapanatili ng mga flag ang gumagana na.

Gumamit ng dedikadong account sa halip na pinagsasaluhan. Nagbababala ang mga developer ng OpenVPN laban sa ugali ng paggamit ng nobody bilang pangkalahatang halimbawa, dahil ang ibang mga serbisyo sa host ay maaaring tumatakbo na sa account na iyon at ang paghihiwalay na inaakala mong mayroon ka ay wala doon.

Ang mga tampok na nagbabago ng lokal na karga, tulad ng offload ng data channel o build na naka-link nang iba, ay maaaring magpalipat ng kung anong mga operasyon ang kailangan. Repasuhin ang mapa kapag nagbago ang package, hindi lamang kapag may nasira.

Isulat ang plano at panatilihin ang access sa pagbawi

Dapat pangalanan ng rekord ng deployment ang manager, ang pagkakakilanlan sa pagsisimula, ang nilalayong matatag na pagkakakilanlan at bawat pagbibigay kasama ang operasyong nangangailangan nito. Ang rekord na iyon ang gumagawa sa susunod na pagbabago na masusuri sa halip na eksperimental.

Panatilihing available ang access sa console habang nag-edit, dahil ang unit na nabibigo sa pagsisimula ay mahirap ayusin mula sa malayo. Subukan ang restart at buong reboot bago ideklarang tapos ang pagbabago. Ang unit na nakakaligtas sa restart ay maaari pa ring mabigo bago umangat ang network.

Ang tagumpay ay isang naunawaang ikot ng buhay na may pinakamababang awtoridad, hindi isang prosesong nagkataong tumatakbo sa ilalim ng pangalang hindi root.