VPN પ્રમાણપત્ર ખસેડવાથી તેનું SELinux લેબલ કેમ તૂટે છે

પ્રમાણપત્રો યોગ્ય ડિરેક્ટરીમાં વાંચી શકાય તેવા મોડ અને root માલિકી સાથે રહી શકે છે, અને સેવા તોપણ જણાવી શકે છે કે તે ફાઇલ ખોલી શકતી નથી. SELinux સિસ્ટમમાં તે સંયોજન પરવાનગીઓ તરફ નહીં, પરંતુ એક ચોક્કસ પદ્ધતિ તરફ ઇશારો કરે છે. લેબલ ફાઇલ સાથે ગયું, કારણ કે નામ બદલવાથી નવી વસ્તુ બનતી નથી. inode એ જૂના માર્ગ પર જે સુરક્ષા સંદર્ભ હતો તે જાળવી રાખ્યો, અને નવા માર્ગની નીતિને કદી પોતાનો સંદર્ભ સોંપવાની તક મળી નહીં.

નામ બદલવાથી લેબલ પર ખરેખર શું થાય છે

ફાઇલ પોતાનો SELinux સંદર્ભ inode સાથે જોડાયેલા લક્ષણ-ડેટા તરીકે ધરાવે છે. એક જ ફાઇલસિસ્ટમમાં નામ બદલવાથી ડિરેક્ટરી એન્ટ્રી બદલાય છે અને બીજું કંઈ નહીં, જે ઝડપી અને પરમાણુ છે, અને એ જ કારણ છે કે સંદર્ભ ખસેડવા પછી ટકી રહે છે. કોઈ નીતિ પૂછવામાં આવતી નથી, કોઈ ડિફોલ્ટ લાગુ થતો નથી, અને કોઈ ચેતવણી છપાતી નથી.

નકલ કરવું અલગ રીતે વર્તે છે. નકલ લક્ષ્ય ડિરેક્ટરીમાં નવો inode બનાવે છે, અને નીતિ તે ડિરેક્ટરીના પ્રકાર પરથી સંદર્ભ સોંપે છે, તેથી નકલ કરેલું પ્રમાણપત્ર સામાન્ય રીતે યોગ્ય લેબલ સાથે પૂરું થાય છે, જ્યારે ખસેડેલું ખોટું જ રહે છે. એ એક જ તફાવત આ પ્રકારની ટિકિટમાં મોટા ભાગની ગૂંચવણ સમજાવે છે.

ફાઇલસિસ્ટમ વચ્ચેના ખસેડવા નકલ-અર્થશાસ્ત્ર પર પાછા આવે છે, તેથી એ જ આદેશ બે મશીનો પર અલગ વર્તી શકે છે, તેના પર આધાર રાખે છે કે /etc પોતાના વોલ્યુમ પર રહે છે કે નહીં. સાધન અવિશ્વસનીય છે એવા નિષ્કર્ષ પર આવતા પહેલાં આ તપાસો. માઉન્ટ કોષ્ટક પર એક નજર તમને કહી દેશે કે તમે કયા પ્રકારનું ખસેડવું કર્યું.

વર્તમાન લેબલને અપેક્ષિત લેબલ સામે વાંચો

ત્રણ ફક્ત-વાંચન આદેશો કંઈપણ બદલ્યા વિના પ્રશ્નનો જવાબ આપે છે. પ્રથમ ફાઇલમાં અત્યારે શું છે તે દર્શાવે છે, બીજો તે ચોક્કસ માર્ગ માટે નીતિ શું અપેક્ષા રાખે છે તે જણાવે છે, અને ત્રીજો ડિરેક્ટરી હેઠળની દરેક એવી ફાઇલની યાદી આપે છે જેનું લેબલ અલગ છે.

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

જેના પર ભરોસો કરવો તે ડ્રાય રન છે, કારણ કે તે દરેક એવી ફાઇલનું નામ આપે છે જેનો સંદર્ભ નીતિથી દૂર જાય છે અને સિસ્ટમને અડ્યા વિના રાખે છે. જો પ્રમાણપત્ર તે યાદીમાં દેખાય, તો માર્ગ જે અર્થ ધરાવે છે અને ફાઇલ જે દાવો કરે છે તે વચ્ચેની અસંગતિ તમે શોધી કાઢી છે. જો ન દેખાય, તો લેબલ પહેલેથી જ નીતિ જે ઇચ્છે છે તે છે, અને તમારો સમય બીજે ક્યાંક આવે છે.

પછી તફાવતને વાસ્તવિક નકાર સાથે સાંકળો. અસંગતિ ખોટા લેબલનો પુરાવો છે, એ પુરાવો નહીં કે સેવા તેના કારણે નિષ્ફળ ગઈ, અને લોગમાં અનુરૂપ નકાર વિના લાગુ કરાયેલો સુધારો વધારાના પગલાં સાથેનું અનુમાન છે.

અપવાદ શોધવાને બદલે મેપિંગ પુનઃસ્થાપિત કરો

પ્રમાણભૂત સ્થાન માટે નીતિ પહેલેથી જ માર્ગનું મેપિંગ કરે છે, તેથી restorecon તેને લાગુ કરે છે અને કામ પૂરું થાય છે. અવકાશને તમે સુધારી રહ્યા છો તે ડિરેક્ટરી સુધી જ રાખો; આખી ફાઇલસિસ્ટમ ફરી લેબલ કરવી ધીમી, વિક્ષેપકારક છે, અને તે મૂળ ભૂલને ખૂબ મોટા ફેરફાર નીચે દફનાવે છે.

કસ્ટમ ડિરેક્ટરી માટે ક્રમ મહત્વનો છે, અને તેને ઉલટાવવાથી એવો આદેશ બને છે જે કંઈ બદલ્યા વિના સફળતા જણાવે છે. મેપિંગ નીતિમાં આવે છે, ફરી લેબલિંગ અંતે આવે છે, અને ડ્રાય રન બંને પહેલાં આવે છે. તે છેલ્લો ભાગ છોડી દેવો એ જ રીત છે જેનાથી કદી ખોટો ન હોય તેવો માર્ગ પણ ફરી લેબલ થઈ જાય છે.

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

restorecon મેપિંગ લાગુ કરે છે; તે એક શોધી શકતું નથી. જો કોઈ નિયમ માર્ગનું વર્ણન ન કરે, તો પુનઃસ્થાપિત કરવા માટે કંઈ નથી, અને એટલે જ ફરી લેબલિંગ પહેલાં ચાલુ રહેતું મેપિંગ અસ્તિત્વમાં હોવું જોઈએ. કઈ રૂપરેખા તે મેપિંગની માલિક છે તે નોંધો, કારણ કે નહીં તો પછીનું ખસેડવું, પેકેજ અપડેટ કે ફરી લેબલિંગ ખામીને ફરી ઊભી કરે છે અને આગલી વ્યક્તિ શૂન્યથી શરૂ કરે છે.

chcon જ ઉપાય કેમ નથી

chcon સીધો ફાઇલ પર સંદર્ભ લખે છે. તે તરત જ અસર કરે છે અને તે ઉપલબ્ધ સૌથી ઓછું ટકતું વિકલ્પ છે, કારણ કે ફાઇલસિસ્ટમ ફરી લેબલિંગ નીતિને ફરી લાગુ કરે છે અને પૂછ્યા વિના જાતે કરેલા ફેરફારો ફેંકી દે છે. ફાઇલ સુધારેલી લાગે છે અને સુધારાની એક સમાપ્તિ તારીખ છે જે કોઈએ લખી નથી. તમે તેના બદલે માર્ગનું વર્ણન કરતો નિયમ ઇચ્છો છો, જેથી ત્યાં આવતી દરેક ફાઇલને આપોઆપ એ જ વર્તન મળે.

વધુ ખરાબ, તે ખોટો પાઠ શીખવે છે: અંતર્ગત મેપિંગ હજી પણ ગુમ છે, તેથી ખામી અઠવાડિયાં પછી સ્પષ્ટ ટ્રિગર અને તે ઉપાયની યાદ વિના પાછી આવે છે. chcon નો ઉપયોગ ફક્ત પરિકલ્પના ચકાસવા માટે કામચલાઉ પ્રયોગ તરીકે કરો, પછી તેને એવા મેપિંગથી બદલો જે આગલી ફરી લેબલિંગ ટકી રહે, અને તપાસો કે બદલી ખરેખર જગ્યાએ છે.

જ્યારે લેબલ યોગ્ય હોય અને પ્રવેશ તોપણ નિષ્ફળ જાય

પિતૃ ડિરેક્ટરીઓથી શરૂ કરો. માર્ગના દરેક ઘટક પર ટ્રાવર્સલ પરવાનગી તપાસાય છે, તેથી જે ડિરેક્ટરીમાં સેવા પ્રવેશી શકતી નથી તેમાં યોગ્ય રીતે લેબલ કરેલું પ્રમાણપત્ર પણ અવાંચ્યું જ રહે છે. SELinux અને સામાન્ય પરવાનગી બંનેએ દરેક પગલાને મંજૂરી આપવી પડે, અને એકને સુધારવાથી બીજું સુધરતું નથી.

પછી પ્રક્રિયા ઓળખ અને સેવાના પોતાના સેન્ડબોક્સિંગને તપાસો. પ્રતિબંધક સેન્ડબોક્સ ધરાવતું યુનિટ એવી ફાઇલમાં પ્રવેશ નકારી શકે છે જેને નીતિ ખુશીથી મંજૂરી આપે, અને લોગ લાઇન પરથી બંને કારણો એકસરખા લાગે છે. કઈ પ્રક્રિયા ખરેખર પૂછે છે તે નિશ્ચિત કરો, તમે જે ધારો છો તે નહીં.

યાદ રાખો કે dontaudit નિયમો નકાર સંદેશાઓને દબાવી શકે છે, તેથી ખાલી ઓડિટ લોગ પુરાવો નહીં, નબળો પુરાવો છે. જો નીતિ યોગ્ય લાગે અને પ્રવેશ તોપણ નિષ્ફળ જાય, તો વિશાળ પરવાનગી મોડ્યુલ બનાવતા પહેલાં તપાસ કરો, અને લક્ષણ અદૃશ્ય કરવા SELinux બંધ કરશો નહીં. બંને ટૂંકા રસ્તા એવી સિસ્ટમ આપે છે જે કામ કરતી લાગે અને એવું સુરક્ષા વલણ જે કોઈ વર્ણવી શકે નહીં. ટૂંકી તપાસ બંનેમાંથી કોઈપણ કરતાં સારી છે.