Kwa nini kuhamisha cheti cha VPN huvunja lebo yake ya SELinux

Vyeti vinaweza kuwa katika saraka sahihi na hali inayosomeka na umiliki wa root, na huduma bado inaweza kuripoti kwamba haiwezi kufungua faili. Katika mfumo wa SELinux mchanganyiko huo unaonyesha utaratibu mmoja maalum na si ruhusa. Lebo ilisafiri na faili, kwa sababu kubadilisha jina hakuundi kitu kipya. inode ilihifadhi muktadha wa usalama iliokuwa nao kwenye njia ya zamani, na sera ya njia mpya haikupata nafasi ya kugawa yake.

Kubadilisha jina hufanya nini kwa lebo

Faili hubeba muktadha wake wa SELinux kama data ya sifa iliyounganishwa na inode. Kubadilisha jina ndani ya mfumo mmoja wa faili hubadilisha ingizo la saraka na hakuna kingine, jambo ambalo ni la haraka na la atomiki, na ndilo sababu muktadha huishi baada ya kuhamishwa. Hakuna sera inayoulizwa, hakuna chaguo-msingi linalotumika, na hakuna onyo linalochapishwa.

Kunakili hufanya kwa namna tofauti. Nakala huunda inode mpya katika saraka lengwa, na sera hutoa muktadha kutoka aina ya saraka hiyo, kwa hiyo cheti kilichonakiliwa kwa kawaida huishia na lebo sahihi wakati kilichohamishwa kinabaki si sahihi. Tofauti hiyo moja inaeleza sehemu kubwa ya mkanganyiko katika aina hii ya tiketi.

Kuhamisha kati ya mifumo ya faili hurudi kwenye maana ya kunakili, kwa hiyo amri hiyo hiyo inaweza kujiendesha tofauti kwenye mashine mbili kulingana na kama /etc iko kwenye ujazo wake mwenyewe. Hakikisha hilo kabla ya kuhitimisha kuwa chombo hicho hakiaminiki. Mtazamo mmoja kwenye jedwali la mount unakuambia ni aina gani ya kuhamisha uliofanya.

Soma lebo ya sasa dhidi ya inayotarajiwa

Amri tatu za kusoma tu hujibu swali bila kubadilisha chochote. Ya kwanza inaonyesha kile faili inacho sasa, ya pili inaripoti kile sera inatarajia kwa njia hiyo kamili, na ya tatu inaorodhesha kila faili chini ya saraka ambayo lebo yake inatofautiana.

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

Inayostahili kuaminiwa ni mbio kavu, kwa sababu hutaja kila faili ambayo muktadha wake unatoka nje ya sera na bado huacha mfumo bila kuguswa. Ikiwa cheti kitaonekana kwenye orodha hiyo, umepata tofauti kati ya kile njia inamaanisha na kile faili inadai. Ikiwa hakitaonekana, lebo tayari ni kile sera inataka na muda wako ni wa mahali pengine.

Kisha unganisha tofauti na kataa halisi. Kutofautiana ni ushahidi wa lebo isiyo sahihi, si uthibitisho kwamba huduma ilishindwa kwa sababu yake, na marekebisho yaliyotumika bila kataa linalolingana kwenye kumbukumbu ni dhana yenye hatua za ziada.

Rejesha ramani badala ya kubuni ubaguzi

Kwa eneo la kawaida sera tayari inaweka ramani ya njia, kwa hiyo restorecon inaitumia na kazi imekamilika. Weka wigo kwenye saraka unayorekebisha; kuweka lebo upya mfumo wote wa faili ni polepole, kunasumbua, na huzika kosa la awali chini ya mabadiliko makubwa sana.

Kwa saraka maalum mpangilio ni muhimu, na kuubadilisha kinyume hutoa amri inayoripoti mafanikio bila kubadilisha chochote. Ramani ni ya sera, uwekaji lebo upya ni wa mwisho, na mbio kavu ni ya kabla ya zote mbili. Kuruka sehemu hiyo ya mwisho ndiyo njia ambayo njia ambayo haikuwa na makosa kamwe bado inawekwa lebo upya.

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

restorecon inatumia ramani; haiwezi kubuni moja. Ikiwa hakuna kanuni inayoeleza njia, hakuna cha kurejesha, ndiyo sababu ramani ya kudumu lazima iwepo kabla ya uwekaji lebo upya. Andika ni usanidi upi unaomiliki ramani hiyo, kwa sababu vinginevyo kuhamisha baadaye, kusasisha kifurushi au kuweka lebo upya huunda kasoro tena na mtu anayefuata huanza kutoka sifuri.

Kwa nini chcon si suluhisho

chcon huandika muktadha moja kwa moja kwenye faili. Hufanya kazi mara moja na ni chaguo lisilodumu zaidi linalopatikana, kwa sababu uwekaji lebo upya wa mfumo wa faili hutumia sera tena na hutupa mabadiliko ya mkono bila kuuliza. Faili inaonekana imerekebishwa na marekebisho yana tarehe ya mwisho ambayo hakuna aliyoiandika. Unachotaka badala yake ni kanuni inayoeleza njia, ili kila faili inayofika hapo ipate matibabu sawa kiotomatiki.

Mbaya zaidi, inafundisha somo lisilo sahihi: ramani ya msingi bado haipo, kwa hiyo kasoro inarudi baada ya wiki bila kichocheo cha wazi na bila kumbukumbu ya njia hiyo ya kuzunguka. Tumia chcon tu kama jaribio la muda la kuthibitisha dhana, kisha ibadilishe na ramani inayostahimili uwekaji lebo upya unaofuata, na hakikisha kwamba mbadala uko mahali pake.

Wakati lebo ni sahihi na ufikiaji bado unashindwa

Anza na saraka wazazi. Ruhusa ya kupita hukaguliwa kwenye kila sehemu ya njia, kwa hiyo cheti kilichowekwa lebo kwa usahihi ndani ya saraka ambayo huduma haiwezi kuingia bado hakisomeki. SELinux na ruhusa ya kawaida zote lazima ziruhusu kila hatua, na kurekebisha moja hakurekebishi nyingine.

Kisha angalia utambulisho wa mchakato na sandbox ya huduma yenyewe. Kitengo chenye sandbox yenye vikwazo kinaweza kukataa ufikiaji wa faili ambayo sera ingeiruhusu kwa furaha, na kutoka kwenye mstari wa kumbukumbu sababu hizo mbili zinaonekana sawa. Thibitisha ni mchakato upi unaouliza kwa kweli, si ule unaodhani unauliza.

Kumbuka kwamba kanuni za dontaudit zinaweza kukandamiza ujumbe wa kukataa, kwa hiyo kumbukumbu tupu ya ukaguzi ni ushahidi hafifu na si uthibitisho. Ikiwa sera inaonekana sahihi na ufikiaji bado unashindwa, chunguza kabla ya kuzalisha moduli pana ya ruhusa, na usizime SELinux ili dalili itoweke. Njia zote mbili fupi hutoa mfumo unaoonekana kufanya kazi na msimamo wa usalama ambao hakuna anayeweza kuueleza. Uchunguzi mfupi ni bora kuliko zote mbili.