Root sa terminal, tinanggihan sa ilalim ng SELinux: bakit nabigo ang hook

Pinapatakbo mo ang up script bilang root, natatapos ito, at ang parehong script ay nabigo kapag tinatawag ito ng serbisyo. Walang nagbago sa mga pahintulot ng file, kaya ang natural na susunod na hakbang ay luwagan muli ang mga ito, na walang inaayos. Sa isang host na SELinux ang mapagpasyang salik ay madalas hindi kung sino ang proseso kundi sa aling domain ito tumatakbo, at ang root sa loob ng isang limitadong domain ay nananatiling limitado.

Parehong utos, dalawang magkaibang domain ng seguridad

Sinusuri ng pagpapatupad ng uri ang source domain, target label at ang hiniling na operasyon nang sabay. Ang iyong terminal session ay tumatakbo sa isang domain na walang limitasyon o administratibo, at ang daemon ay tumatakbo sa domain na itinalaga sa unit nito. Kaya ang magkatulad na utos ay nagbibigay ng magkaibang desisyon, at ang pagkakaiba ay sinadya at hindi isang bug sa patakaran.

Iyon ang dahilan kung bakit ang paghahambing ng dalawang pagtakbo ay kapaki-pakinabang lamang kung ihahambing mo ang kanilang mga konteksto. Patakbuhin ang parehong utos mula sa shell at mula sa hook, at ang bersyon mula sa shell ay nagpapatunay na umiiral ang binary at tama ang mga argumento; hindi nito pinapatunayan ang anuman tungkol sa kung pinapayagan ang serbisyo na patakbuhin ito. Patakbuhin ito sa dalawang paraan at ihambing ang mga domain, hindi lamang ang mga exit code. Ang paghahambing na iyon ang nagpapalit ng malabong reklamo tungkol sa pahintulot sa isang tiyak na tanong tungkol sa isang domain at isang label.

Ang klasikong anyo ng depektong ito ay isang helper na tumatawag ng panlabas na tool. Maaaring pinapayagan ang hook mismo, habang ang tool na tinatawag nito ay may label na hindi maaaring patakbuhin ng domain ng serbisyo, o nagsusulat sa isang direktoryo na ipinagbabawal ng label nito.

Basahin ang AVC record sa tabi ng error ng hook

Pinapangalanan ng AVC denial ang mga field na nagpapasya sa kaso: ang source context ng proseso, ang target context ng object, ang object class at ang tiyak na pahintulot na tinanggihan. Basahin ang lahat ng apat bago bumuo ng teorya, dahil ang pagtanggi sa execute at pagtanggi sa write ay may ganap na magkaibang mga pag-aayos.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Dapat tumugma ang source context sa domain kung saan talaga tumatakbo ang serbisyo, at ang target context sa label ng file o direktoryo na nahawakan ng operasyon. Kung ang isa sa kanila ay hindi tumutugma sa error na hinahabol mo, ibang kaganapan ang binabasa mo.

Itala sa tabi ng record ang bersyon ng patakaran at ang eksaktong landas ng executable. Ang pangalan ng domain na lumilitaw sa patakaran ng isang distribusyon ay ebidensya tungkol sa pag-install na iyon, hindi garantiya na ang ibang build ay naghahatid ng parehong mga tuntunin. Ang kontekstong iyon ang nagbibigay-daan sa iba na muling gawin ang iyong konklusyon sa sarili nilang host. Kung wala ito, ang record ay binabasa bilang anekdota at hindi bilang ebidensya.

Label, konfigurasyon o patakaran: tatlong pag-aayos

Ang unang pag-aayos ay isang label na hindi tumutugma sa naka-install na lokasyon ng file. Ang script na kinopya sa puwesto gamit ang cp o isinulat ng editor ay maaaring may default na label na hindi magagamit ng domain ng serbisyo, at ang pagbabalik ng inaasahang konteksto ay nag-aayos nito nang hindi hinahawakan ang patakaran.

Ang pangalawa ay konfigurasyon. Maaaring magbigay ang distribusyon ng sinusuportahang paraan upang patakbuhin ang operasyon, isang dokumentadong direktoryo para sa helper, o isang na-update na pakete ng patakaran na pinapayagan na ito. Ang pagbabago ng iyong layout patungo sa sinusuportahan ay mas mura kaysa sa pagsulat ng patakaran at nakakaligtas sa mga update.

Ang pangatlo ay isang tuntuning talagang kulang, at dapat itong maging huling paraan. Bumuo ng kandidato gamit ang mga tool sa audit, basahin kung ano talaga ang pinapayagan nito, bawasan ito sa operasyon at domain na naobserbahan mo, at ipasuri ito sa iba bago ito lumapit sa produksyon.

Bakit ang lumang allow module ay hindi ang sagot

Ang mga resulta ng paghahanap para sa depektong ito ay puno ng mga ready-made na module, madalas para sa tool na hindi na tinatawag ng hook. Ang pag-install ng isa ay nagbibigay ng mga pahintulot na maaaring walang kinalaman sa iyong pagtanggi, at iniiwan ang tunay na hindi pagkakatugma sa puwesto habang nagdadagdag ng permanenteng butas.

Itinatago rin nito ang susunod na kabiguan. Ang module na nagpapahintulot ng malawak na klase ng mga operasyon ay magpapawala sa error na ito at gagawing mas mahirap iugnay ang susunod. Ang pag-alis ng module sa ibang pagkakataon ay isa ring pagbabagong walang gustong iiskedyul, kaya ang shortcut ay may tendensiyang maging permanente.

Ang disiplinadong paghahambing ay nasa pagitan ng pagtanggi na mababasa mo at ng pagbabagong iminumungkahi mo. Ang gabay ng Red Hat sa pag-troubleshoot ng SELinux ay naglalagay ng mga pagsusuri sa label at konfigurasyon bago ang nabuong patakaran dahil mismo sa dahilang ito. Kung walang katumbas na pagtanggi sa record, malamang na hindi SELinux ang problema mo, at bukas pa rin ang mga isyu sa landas, sandbox o pahintulot.