Bakit Sinisira ng Paglipat ng VPN Certificate ang SELinux Label Nito

Ang mga certificate ay maaaring nasa tamang direktoryo na may nababasang mode at pagmamay-ari ng root, at maaari pa ring iulat ng serbisyo na hindi nito mabuksan ang file. Sa isang SELinux system, ang kombinasyong iyon ay tumutukoy sa isang partikular na mekanismo at hindi sa mga pahintulot. Naglakbay ang label kasama ng file, dahil ang pagpapalit ng pangalan ay hindi lumilikha ng bagong object. Pinanatili ng inode ang security context na mayroon ito sa lumang path, at ang patakaran para sa bagong path ay hindi kailanman nagkaroon ng pagkakataong magtalaga ng sarili nito.

Ano ang talagang ginagawa ng pagpapalit ng pangalan sa isang label

Dinadala ng file ang SELinux context nito bilang attribute data na nakakabit sa inode. Ang pagpapalit ng pangalan sa loob ng isang filesystem ay nagbabago ng directory entry at wala nang iba, na mabilis at atomiko, at iyon ang dahilan kung bakit nabubuhay ang konteksto sa paglipat. Walang patakarang kinukonsulta, walang default na inilalapat, at walang babalang nakalimbag.

Iba ang inaasal ng pagkopya. Ang kopya ay lumilikha ng bagong inode sa destinasyong direktoryo, at ang patakaran ay nagtatalaga ng konteksto mula sa uri ng direktoryong iyon, kaya ang nakopyang certificate ay karaniwang nagtatapos sa tamang label habang ang inilipat ay nananatiling mali. Ang nag-iisang pagkakaibang iyon ang nagpapaliwanag sa karamihan ng kalituhan sa ganitong uri ng ticket.

Ang paglipat sa pagitan ng mga filesystem ay bumabalik sa semantika ng pagkopya, kaya ang parehong command ay maaaring kumilos nang iba sa dalawang makina depende sa kung ang /etc ay nasa sariling volume nito. Suriin iyon bago ka maghinuha na hindi mapagkakatiwalaan ang tool. Isang sulyap sa mount table ang magsasabi sa iyo kung anong uri ng paglipat ang ginawa mo.

Basahin ang kasalukuyang label laban sa inaasahan

Tatlong read-only na command ang sumasagot sa tanong nang walang binabago. Ipinapakita ng una kung ano ang mayroon ang file ngayon, iniuulat ng ikalawa kung ano ang inaasahan ng patakaran para sa eksaktong path na iyon, at inililista ng ikatlo ang bawat file sa ilalim ng direktoryo na naiiba ang label.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Ang dapat pagkatiwalaan ay ang dry run, dahil pinapangalanan nito ang bawat file na ang konteksto ay lumilihis sa patakaran at hinahayaan pa ring hindi magalaw ang system. Kung lumitaw ang certificate sa listahang iyon, natagpuan mo ang pagkakaiba sa pagitan ng ibig sabihin ng path at ng sinasabi ng file. Kung hindi ito lumitaw, ang label ay kung ano na ang gusto ng patakaran, at ang oras mo ay pag-aari ng ibang lugar.

Pagkatapos ay iugnay ang pagkakaiba sa isang tunay na pagtanggi. Ang hindi pagtutugma ay ebidensya ng maling label, hindi patunay na nabigo ang serbisyo dahil doon, at ang pagbabagong inilapat nang walang katumbas na pagtanggi sa log ay isang hula na may dagdag na hakbang.

Ibalik ang mapping sa halip na mag-imbento ng eksepsyon

Para sa karaniwang lokasyon, ang patakaran ay nagmamapa na ng path, kaya inilalapat ito ng restorecon at tapos na ang trabaho. Itago ang saklaw sa direktoryong kinukumpuni mo; ang muling pag-label ng buong filesystem ay mabagal, nakakaabala, at inililibing nito ang orihinal na pagkakamali sa ilalim ng napakalaking pagbabago.

Para sa custom na direktoryo, mahalaga ang pagkakasunod-sunod, at ang baliktarin ito ay gumagawa ng command na nag-uulat ng tagumpay habang walang binabago. Ang mapping ay kabilang sa patakaran, ang muling pag-label ay kabilang sa dulo, at ang dry run ay kabilang bago ang dalawa. Ang laktawan ang huling bahaging iyon ang paraan kung paano ang isang path na hindi kailanman naging mali ay muling nalalagyan pa rin ng label.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon ay naglalapat ng mapping; hindi ito makakaimbento ng isa. Kung walang tuntuning naglalarawan sa path, walang maibabalik, kaya dapat na umiiral ang permanenteng mapping bago ang muling pag-label. Itala kung aling configuration ang nagmamay-ari ng mapping na iyon, dahil kung hindi, ang susunod na paglipat, pag-update ng package o muling pag-label ay muling lumilikha ng depekto at ang susunod na tao ay magsisimula sa zero.

Bakit hindi ang chcon ang solusyon

chcon ay nagsusulat ng konteksto nang direkta sa file. May epekto ito agad at ito ang pinakamababang matibay na opsyon na available, dahil ang muling pag-label ng filesystem ay naglalapat muli ng patakaran at itinatapon ang manu-manong pagbabago nang hindi nagtatanong. Mukhang naayos ang file at ang pagkukumpuni ay may petsa ng pag-expire na walang nakasulat. Ang gusto mo sa halip ay isang tuntuning naglalarawan sa path, upang ang bawat file na dumarating doon ay awtomatikong makatanggap ng parehong pagtrato.

Mas masahol pa, nagtuturo ito ng maling aral: kulang pa rin ang pinagbabatayang mapping, kaya bumabalik ang depekto pagkalipas ng mga linggo nang walang malinaw na trigger at walang alaala ng workaround. Gamitin ang chcon bilang pansamantalang eksperimento lamang upang kumpirmahin ang isang hypothesis, pagkatapos ay palitan ito ng mapping na nakakaligtas sa susunod na muling pag-label, at tiyakin na ang kapalit ay talagang nasa lugar.

Kapag tama ang label at nabibigo pa rin ang access

Magsimula sa mga parent directory. Sinusuri ang traversal permission sa bawat bahagi ng path, kaya ang tamang naka-label na certificate sa loob ng direktoryong hindi kayang pasukin ng serbisyo ay nananatiling hindi mabasa. Parehong kailangang pumayag ang SELinux at ang ordinaryong pahintulot sa bawat hakbang, at ang pag-aayos ng isa ay hindi nag-aayos ng isa.

Pagkatapos ay suriin ang identity ng process at ang sariling sandbox ng serbisyo. Ang isang unit na may mahigpit na sandbox ay maaaring tumanggi sa access sa file na pahihintulutan sana ng patakaran, at mula sa log line ang dalawang dahilan ay magkatulad. Tiyakin kung aling process ang talagang nagtatanong, hindi kung alin ang ipinapalagay mong nagtatanong.

Tandaan na ang mga tuntunin ng dontaudit ay maaaring magpigil sa mga mensahe ng pagtanggi, kaya ang walang laman na audit log ay mahinang ebidensya at hindi patunay. Kung mukhang tama ang patakaran at nabibigo pa rin ang access, mag-imbestiga bago gumawa ng malawak na allow module, at huwag i-disable ang SELinux upang mawala ang sintomas. Ang parehong shortcut ay gumagawa ng system na mukhang gumagana at isang postura ng seguridad na walang makapaglalarawan. Ang maikling imbestigasyon ay mas mabuti kaysa sa alinman sa dalawa.