Nabibigo ang chroot sa OpenVPN: panuntunan ng AppArmor o kakayahan?

Nag-log ang daemon ng kabiguan sa chroot at mukhang mapagbigay na ang profile, kaya ang nakakaakit na pagwawasto ay palawakin ang isang panuntunan sa landas at i-restart. Karaniwang wala itong binabago, dahil ang chroot ay pinaghahawakan ng pribilehiyong hindi kailanman naibigay ng profile. Upang magpasya kung aling antas ang hahawakan, kailangan ng tatlong pagsusuri, at mura ang mga ito: ano ang pinapayagang hawakan ng proseso, ano ang pinapayagan ng patakaran, at ano ang inalis ng tagapagpatakbo bago pa naging mahalaga ang alinman sa dalawa.

Dalawang magkahiwalay na tarangkahan, at isa lamang ang pag-aari ng AppArmor

Ang chroot ay nangangailangan ng CAP_SYS_CHROOT sa user namespace kung saan tumatakbo ang proseso. Iyon ay karaniwang pribilehiyo ng Linux, sinusuri ng kernel bago pa gumawa ng anuman ang tawag sa mga landas. Hiwalay doon, ang isang AppArmor profile na nagpapatupad ay maaaring tumanggi sa kakayahan kahit hawak ito ng proseso, dahil ang sapilitang patakaran ay isinasaalang-alang bukod pa sa mga kredensyal at hindi kapalit ng mga ito. Mahalaga ang pagkakaiba sa praktika: ang dalawang antas ay nakatira sa magkaibang file at karaniwang pinapanatili ng magkaibang tao.

Parehong errno ang ikinabibigo ng dalawang tarangkahang iyon. Pareho silang gumagawa ng EPERM, at pareho silang lumilitaw bilang pangkalahatang reklamo sa pahintulot sa log ng daemon, kaya napakaraming oras ang nasasayang sa paghula sa nilalaman ng profile. Ang panuntunan sa landas na malapit mo nang idagdag ay kumokontrol sa pag-access sa file pagkatapos magtagumpay ang chroot; wala itong kaugnayan sa kung pinapayagan man ang operasyon.

May ikatlong tarangkahan sa itaas ng dalawa. Kung sinimulan ng tagapamahala ng serbisyo o ng isang wrapper ang proseso nang walang kakayahang iyon sa hangganang set nito, walang pagbabago sa AppArmor ang makapagbabalik nito, at ang pagdaragdag ng mga kakayahan sa profile ay nagdodokumento lamang ng layuning hindi tutuparin ng kernel.

Basahin ang kalagayan ng pribilehiyo bago baguhin ang patakaran

Magsimula sa tumatakbong proseso, hindi sa configuration na inaakala mong aktibo. Ipinapakita ng status file ang limang mask ng kakayahan at ang flag na no-new-privileges, at magkaibang tanong ang sinasagot nila:

grep -E '^(CapInh|CapPrm|CapEff|CapBnd|CapAmb|NoNewPrivs):' /proc/$(pidof openvpn)/status
sudo aa-status | grep -i openvpn

Ang CapEff ang set na mahalaga sa tawag: ang kakayahang nasa CapBnd ngunit wala sa CapEff ay pinapayagan ng kisame at hindi hawak sa sandaling iyon. Mahalaga ang CapAmb kapag ang binary ay hindi pribilehiyado sa karaniwang diwa ng setuid, dahil ang mga ambient na kakayahan ang paraan ng serbisyo upang mapanatili ang pribilehiyo sa exec nang walang mga kakayahan ng file. Ang CapInh ay may mga bit na maaaring manahin sa exec, ngunit kung pinapayagan lamang ng namamanang set ng file na isinasagawa, kaya ang isang bit doon ay walang ibinibigay nang mag-isa.

Pagkatapos ay tiyakin kung aling profile ang tunay na nakakabit. Maaaring makulong ang isang proseso ng pangalang hindi mo inaasahan, lalo na kapag ang isang distribusyon ay naghahatid ng sarili nitong unit at profile nang magkasama, at nilulutas ng pagbasa ng /proc/PID/attr/current iyon sa isang linya. Ang paghahambing ng binago mong file sa profile na iniuulat ng kernel ay ang pagkakaiba ng pag-aayos sa sanhi at pag-edit ng file na walang naglo-load.

Idagdag ang panuntunan sa kakayahan lamang kapag sinasabi ng trail ng audit

Pinangalanan ng mga talaan ng kernel at audit ang antas na tumanggi. Hanapin ang pagtanggi na may dalang operation capable at ng pangalang sys_chroot, kasama ang profile na gumawa nito. Kung may ganoong talaan, hawak na ng proseso ang kakayahan at tinanggihan ito ng AppArmor, at ang naka-target na pagbabago ay isang panuntunan sa kakayahan sa loob ng tunay na profile:

capability sys_chroot,

Panatilihin itong fragment sa profile na tunay na nakakabit, at suriin ang keyword laban sa sanggunian ng profile ng apparmor.d sa halip na kopyahin ang panuntunan mula sa walang kaugnayang tutorial. Ang paglalagay nito sa isang pinagsasaluhang include ay nagbibigay nito sa bawat nakakulong na programa na naglo-load ng file na iyon, at ang paglilipat ng profile sa complain mode ay nagtatago ng susunod na pagtanggi sa halip na lutasin ito. Ang panuntunan sa profile ay nag-aalis ng pagtanggi ng patakaran; hindi ito gumagawa ng pribilehiyo, kaya ang prosesong kailanman ay walang CAP_SYS_CHROOT sa epektibong set nito ay mabibigo pa rin kahit may panuntunan.

Kung ang talaan ng audit ay walang ipinapakitang pagtanggi ng AppArmor, itigil ang pag-edit ng profile. Nakikipag-usap ka sa problemang kredensyal, at ang natitirang trabaho ay nasa unit o sa magulang na proseso, hindi sa wikang patakaran.

May sariling kisame ang tagapamahala ng serbisyo

Nagtakda ang systemd ng hangganang set ng kakayahan para sa bawat serbisyo, at bilang default ay makitid ang set na iyon. Anumang ibinukod doon ay hindi magagamit ng proseso anuman ang sabihin ng profile, kaya maaaring mabigo ang matigas na unit sa operasyong gumana noong manu-manong sinimulan ang daemon. Ang mga kaugnay na direktiba ay madaling basahin sa unit at madaling makaligtaan kapag ang aplikasyon mismo ang nag-uulat ng kabiguan. Ang mga drop-in na hatid ng pakete ng distribusyon ang karaniwang pinagmumulan ng kisame na walang naaalalang nag-configure.

Dalawang pagbabago, hindi isa, ang pagtataas ng kisame at pagbibigay ng kakayahan. Sinasabi ng tala sa hangganang set na maaaring hawakan ng proseso ang kakayahan; hindi nito ito idinadagdag sa epektibong set, at maaaring pigilan ng NoNewPrivs na magtagumpay ang susunod na pagtataas kahit tumutugma ang lahat ng iba. Idagdag lamang ang kailangan ng operasyon, panatilihing buo ang natitirang pagpapatibay, at labanan ang shortcut ng pagbibigay ng lahat ng kakayahan upang makalusot ang isang tawag.

Mahalaga rin ang pagkakasunod-sunod dito. Unahin ang kisame ng unit, tiyakin na nasa CapEff na ang bit, at saka lamang magpasya kung tumatanggi pa ang AppArmor. Ang paggawa ng dalawang pagbabago nang sabay ay mag-iiwan sa iyo na nanghuhula muli kung magpatuloy ang kabiguan.

Kapag nawala ang pagtanggi, siyasatin ang kulungan mismo

Inililipat ng matagumpay na chroot ang ugat, kaya ang bawat landas na hahawakan ng daemon pagkatapos ay nireresolba sa loob ng bagong puno. Ang nawawalang configuration, ang wala na device node o ang direktoryo ng sertipiko na hindi naikopya ay lilitaw na bilang error sa file, at ang error na iyon ay problema sa layout, hindi sa kakayahan. Basahin ang susunod na pangyayari sa halip na magdagdag ng panibagong malawak na pahintulot. Binabago rin ng paglipat ang ibig sabihin ng relatibong landas, kaya iginiit ng mga gabay sa pagpapatibay ang ganap na landas sa configuration ng daemon.

Nakakatulong ding tandaan ang hindi ginagawa ng chroot. Ito ay hangganan ng landas, hindi sandbox: ang prosesong nagpapanatili ng pribilehiyo ay makakatakas, kaya karaniwang ibinabagsak ang kakayahan pagkatapos ng tawag at kaya dapat manatili ang pagkakulong sa paligid ng daemon. Ang pagpapanatiling magkasama ng AppArmor profile, hangganang set ng kakayahan at mga paghihigpit sa filesystem ang punto ng pagsasanay, hindi labis na aalisin kapag nagsimula ang serbisyo.

Maikli ang panuntunan sa desisyon. Kung pinangalanan ng talaan ng audit ang AppArmor, magdagdag ng isang panuntunan sa kakayahan sa nakakabit na profile. Kung walang laman ang epektibong set, ayusin ang kisame ng unit at ang pagkakasunod-sunod ng pagbaba ng pribilehiyo. Kung ang profile ay hindi ang in-edit mo, itigil ang pag-edit at hanapin ang tunay.