chroot inashindikana kwenye OpenVPN: kanuni ya AppArmor au uwezo?

Daemon huandika kushindikana kwa chroot na wasifu unaonekana tayari kuwa mpana, kwa hiyo suluhisho la kuvutia ni kupanua kanuni ya njia na kuwasha upya. Kwa kawaida hilo halibadilishi chochote, kwa sababu chroot imezungukwa na upendeleo ambao wasifu haukuweza kamwe kuutoa. Kuamua tabaka gani la kugusa kunahitaji ukaguzi tatu, na ni wa bei nafuu: mchakato unaruhusiwa kushikilia nini, sera inaruhusu nini, na kianzishi kiliondoa nini kabla ya yoyote ya hayo kuwa na maana.

Malango mawili tofauti, na moja tu ni ya AppArmor

chroot inahitaji CAP_SYS_CHROOT katika nafasi ya majina ya mtumiaji ambayo mchakato unaendeshwa. Hiyo ni haki ya kawaida ya Linux, inayokaguliwa na kerneli kabla ya wito kufanya chochote na njia. Kwa upande mwingine, wasifu wa AppArmor unaotekeleza unaweza kukataa uwezo huo hata mchakato ukiwa nao, kwa sababu sera ya lazima hushauriwa pamoja na vitambulisho na si badala yao. Tofauti hiyo ni muhimu kivitendo: tabaka mbili zinaishi katika faili tofauti na kwa kawaida huzingatiwa na watu tofauti.

Malango hayo mawili hushindikana kwa errno moja. Yote mawili hutoa EPERM, na yote mawili huonekana kama malalamiko ya jumla ya ruhusa katika kumbukumbu ya daemon, ndiyo sababu kubahatisha yaliyomo kwenye wasifu hupoteza muda mwingi. Kanuni ya njia uliyokuwa karibu kuongeza inadhibiti ufikiaji wa faili baada ya chroot kufanikiwa; haina uhusiano na kama operesheni inaruhusiwa kabisa.

Lango la tatu liko juu ya yote mawili. Kama meneja wa huduma au kifuniko kilianzisha mchakato bila uwezo huo katika kikundi chake cha mipaka, hakuna mabadiliko ya AppArmor yanayoweza kuurudisha, na kuongeza uwezo kwenye wasifu kunaeleza tu nia ambayo kerneli haitatimiza.

Soma hali ya upendeleo kabla ya kuhariri sera

Anza na mchakato unaoendesha, si na usanidi unaodhani unaotumika. Faili ya hali inaonyesha masks tano za uwezo na bendera ya no-new-privileges, na zinajibu maswali tofauti:

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

CapEff ni kikundi kinachohusika na wito: uwezo uliopo katika CapBnd lakini haupo CapEff unaruhusiwa na dari na haushikiliwi kwa wakati huo. CapAmb ni muhimu wakati binary haina upendeleo kwa maana ya kawaida ya setuid, kwa sababu uwezo wa mazingira ndiyo njia ambayo huduma huhifadhi upendeleo kupitia exec bila uwezo wa faili. CapInh hushikilia bits zinazoweza kurithiwa kupitia exec, lakini tu wakati kikundi cha urithi cha faili inayotekelezwa kinaruhusu, kwa hiyo bit pale haitoi chochote yenyewe.

Kisha thibitisha ni wasifu upi umeunganishwa kweli. Mchakato unaweza kuzuiwa na jina la wasifu usiolitarajia, hasa wakati usambazaji unasambaza unit yake na wasifu wake pamoja, na kusoma /proc/PID/attr/current hutatua hilo kwa mstari mmoja. Kulinganisha faili yako iliyohaririwa na wasifu ambao kerneli inaripoti ni tofauti kati ya kurekebisha sababu na kuhariri faili ambayo hakuna anayeipakia.

Ongeza kanuni ya uwezo tu wakati alama ya ukaguzi inasema hivyo

Kumbukumbu za kerneli na ukaguzi hutaja tabaka lililokataa. Tafuta kukataliwa kunachobeba operesheni capable na jina sys_chroot, pamoja na wasifu ulioizalisha. Kama kumbukumbu hiyo ipo, mchakato ulikuwa tayari na uwezo huo na AppArmor ilikataa, na mabadiliko lengwa ni kanuni ya uwezo ndani ya wasifu halisi:

capability sys_chroot,

Ibakie kama kipande katika wasifu uliounganishwa kweli, na kagua neno muhimu katika marejeleo ya wasifu wa apparmor.d badala ya kunakili kanuni kutoka mwongozo usiohusiana. Kuiweka katika include inayoshirikiwa kunawapa kila programu iliyozuiliwa inayopakia faili hiyo, na kubadilisha wasifu kwenda hali ya complain kunaficha kukataliwa kwingine badala ya kutatua huku. Kanuni ya wasifu huondoa kukataliwa kwa sera; haitengenezi upendeleo, kwa hiyo mchakato ambao hakuwa na CAP_SYS_CHROOT katika kikundi chake tendaji bado utashindikana hata kanuni ikiwa imewekwa.

Kama kumbukumbu ya ukaguzi haionyeshi kukataliwa kwa AppArmor hata kidogo, acha kuhariri wasifu. Unakabiliana na tatizo la vitambulisho, na kazi iliyobaki iko kwenye unit au kwenye mchakato mzazi, si katika lugha ya sera.

Meneja wa huduma anahifadhi dari yake mwenyewe

systemd huweka kikundi cha mipaka ya uwezo kwa kila huduma, na kwa chaguo-msingi kikundi hicho ni chembamba. Chochote kilichotengwa hapo hakipatikani kwa mchakato bila kujali wasifu unasema nini, ndiyo sababu units zilizoimarishwa zinaweza kushindikana kwenye operesheni iliyofanya kazi wakati daemon ilianzishwa kwa mkono. Maagizo husika ni rahisi kusoma kwenye unit na rahisi kupuuzwa wakati programu yenyewe inaripoti hitilafu. Drop-in zinazotolewa na kifurushi cha usambazaji ni chanzo cha kawaida cha dari ambayo hakuna anayekumbuka aliiweka.

Kuinua dari na kutoa uwezo ni mabadiliko mawili, si moja. Kipengele katika kikundi cha mipaka kinasema mchakato anaweza kushikilia uwezo huo; hakiongezi kwenye kikundi tendaji, na NoNewPrivs inaweza kuzuia upandishaji wa baadaye kufanikiwa hata kila kitu kingine kikilingana. Ongeza tu kile operesheni inahitaji, huhifadhi uimarishaji uliobaki, na pinga njia ya mkato ya kutoa uwezo wote ili wito mmoja upite.

Mpangilio ni muhimu hapa pia. Badilisha kwanza dari ya unit, thibitisha kwamba CapEff sasa ina bit hiyo, na kisha tu amua kama AppArmor bado inakataa. Kufanya mabadiliko yote mawili kwa wakati mmoja kunakuacha ukibahatisha tena kama hitilafu itaendelea.

Baada ya kukataliwa kuondoka, kagua gereza lenyewe

chroot iliyofanikiwa huhamisha mzizi, kwa hiyo kila njia ambayo daemon inagusa baadaye hutatuliwa ndani ya mti mpya. Usanidi unaokosekana, nodi ya kifaa isiyopo au saraka ya vyeti ambayo haikunakiliwa sasa itaonekana kama hitilafu ya faili, na hitilafu hiyo ni tatizo la mpangilio, si la uwezo. Soma tukio lifuatalo badala ya kuongeza ruhusa nyingine pana. Uhamisho pia hubadilisha maana ya njia linganifu, ndiyo sababu miongozo ya uimarishaji inasisitiza njia kamili katika usanidi wa daemon.

Inasaidia pia kukumbuka kile chroot haifanyi. Ni mpaka wa njia, si sandbox: mchakato unaohifadhi upendeleo unaweza kutoroka, ndiyo sababu uwezo kwa kawaida hutupwa baada ya wito na kwa nini uzuiaji unapaswa kubaki kuzunguka daemon. Kuhifadhi pamoja wasifu wa AppArmor, kikundi cha mipaka ya uwezo na vizuizi vya mfumo wa faili ndio lengo la zoezi, si mabaki ya kuondoa baada ya huduma kuanza.

Kanuni ya uamuzi ni fupi. Kama kumbukumbu ya ukaguzi inataja AppArmor, ongeza kanuni moja ya uwezo kwenye wasifu uliounganishwa. Kama kikundi tendaji ni tupu, rekebisha dari ya unit na mpangilio wa kutupa upendeleo. Kama wasifu si ule uliouhariri, acha kuhariri na utafute ule halisi.