ટર્મિનલમાં રૂટ, SELinux હેઠળ નકારાયેલ: હૂક કેમ નિષ્ફળ જાય છે
હાથે સંપૂર્ણ રીતે ચાલતો હૂક સેવાની અંદર નકારી શકાય છે. સંપાદન પહેલાં પ્રક્રિયાનું ડોમેન, ફાઇલનું લેબલ અને નકારાયેલ પરવાનગી સરખાવો.
તમે રૂટ તરીકે up સ્ક્રિપ્ટ ચલાવો છો, તે પૂર્ણ થાય છે, અને સેવા તેને બોલાવે ત્યારે એ જ સ્ક્રિપ્ટ નિષ્ફળ જાય છે. ફાઇલની પરવાનગીઓમાં કંઈ બદલાયું નથી, તેથી સ્વાભાવિક આગલું પગલું તેમને ફરી ઢીલી કરવાનું છે, જે કંઈ સુધારતું નથી. SELinux હોસ્ટ પર નિર્ણાયક પરિબળ ઘણી વાર એ નથી હોતું કે પ્રક્રિયા કોણ છે, પરંતુ તે કયા ડોમેનમાં ચાલે છે, અને મર્યાદિત ડોમેનની અંદરનો રૂટ પણ મર્યાદિત જ રહે છે.
એ જ આદેશ, બે જુદાં સુરક્ષા ડોમેન
ટાઇપ એન્ફોર્સમેન્ટ સ્રોત ડોમેન, લક્ષ્ય લેબલ અને વિનંતી કરેલી ક્રિયાનું એકસાથે મૂલ્યાંકન કરે છે. તમારું ટર્મિનલ સત્ર અમર્યાદિત અથવા વહીવટી ડોમેનમાં ચાલે છે, અને ડેમન તેના યુનિટને ફાળવેલા ડોમેનમાં ચાલે છે. તેથી સમાન આદેશો જુદા જુદા નિર્ણયો આપે છે, અને આ તફાવત નીતિમાંની ભૂલ નહીં પરંતુ ઇરાદાપૂર્વકનો છે.
તેથી જ બે રનની સરખામણી ત્યારે જ ઉપયોગી છે જ્યારે તમે તેમના સંદર્ભોની સરખામણી કરો. એ જ આદેશ શેલમાંથી અને હૂકમાંથી ચલાવો; શેલ આવૃત્તિ સાબિત કરે છે કે બાઇનરી અસ્તિત્વમાં છે અને દલીલો સાચી છે, પરંતુ સેવાને તેને ચલાવવાની પરવાનગી છે કે નહીં તે વિશે કંઈ સાબિત કરતું નથી. બંને રીતે ચલાવો અને ડોમેનની સરખામણી કરો, માત્ર એક્ઝિટ કોડની નહીં. એ સરખામણી જ અસ્પષ્ટ પરવાનગી ફરિયાદને એક ડોમેન અને એક લેબલ વિશેના ચોક્કસ પ્રશ્નમાં ફેરવે છે.
આ ખામીનું પરંપરાગત સ્વરૂપ એવો હેલ્પર છે જે બાહ્ય સાધનને બોલાવે છે. હૂક પોતે મંજૂર હોઈ શકે છે, જ્યારે તે જે સાધનને બોલાવે છે તે એવું લેબલ ધરાવે છે જે સેવા ડોમેન ચલાવી શકતું નથી, અથવા એવી ડિરેક્ટરીમાં લખે છે જેનું લેબલ તેને મનાઈ કરે છે.
હૂક ભૂલની બાજુમાં AVC રેકોર્ડ વાંચો
AVC નકાર તે ક્ષેત્રોના નામ આપે છે જે કેસ નક્કી કરે છે: પ્રક્રિયાનો સ્રોત સંદર્ભ, ઑબ્જેક્ટનો લક્ષ્ય સંદર્ભ, ઑબ્જેક્ટ વર્ગ અને તે ચોક્કસ પરવાનગી જે નકારાઈ. સિદ્ધાંત રચતા પહેલાં ચારેય વાંચો, કારણ કે એક્ઝિક્યુટ પરનો નકાર અને રાઇટ પરનો નકાર સંપૂર્ણપણે જુદા સુધારા ધરાવે છે.
ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn
સ્રોત સંદર્ભ સેવા ખરેખર જે ડોમેનમાં ચાલે છે તેની સાથે મેળ ખાવો જોઈએ, અને લક્ષ્ય સંદર્ભ ક્રિયાએ સ્પર્શેલી ફાઇલ કે ડિરેક્ટરીના લેબલ સાથે મેળ ખાવો જોઈએ. જો તેમાંથી કોઈ એક તમે પકડી રહ્યા હો તે ભૂલ સાથે મેળ ન ખાય, તો તમે બીજી ઘટના વાંચી રહ્યા છો.
રેકોર્ડની બાજુમાં નીતિની આવૃત્તિ અને એક્ઝિક્યુટેબલનો ચોક્કસ પાથ નોંધો. એક ડિસ્ટ્રિબ્યુશનની નીતિમાં દેખાતું ડોમેન નામ તે ઇન્સ્ટોલેશન વિશેનો પુરાવો છે, બીજું બિલ્ડ એ જ નિયમો પૂરા પાડે તેની ખાતરી નહીં. એ સંદર્ભ જ બીજા કોઈને તેમના પોતાના હોસ્ટ પર તમારા તારણને પુનરાવર્તિત કરવા દે છે. તેના વિના, રેકોર્ડ પુરાવાને બદલે કિસ્સા જેવો વંચાય છે.
લેબલ, રૂપરેખાંકન કે નીતિ: ત્રણ સુધારા
પ્રથમ સુધારો એવું લેબલ છે જે ફાઇલના ઇન્સ્ટોલ થયેલા સ્થાન સાથે મેળ ખાતું નથી. cp વડે જગ્યાએ કૉપી કરેલી અથવા એડિટર દ્વારા લખાયેલી સ્ક્રિપ્ટ એવું ડિફૉલ્ટ લેબલ ધરાવી શકે છે જે સેવા ડોમેન વાપરી શકતું નથી, અને અપેક્ષિત સંદર્ભ પુનઃસ્થાપિત કરવાથી નીતિને સ્પર્શ કર્યા વિના તે સુધરી જાય છે.
બીજું રૂપરેખાંકન છે. ડિસ્ટ્રિબ્યુશન ક્રિયા ચલાવવાની સમર્થિત રીત, હેલ્પર માટે દસ્તાવેજીકૃત ડિરેક્ટરી, અથવા પહેલેથી જ મંજૂરી આપતું અદ્યતન નીતિ પેકેજ પ્રદાન કરી શકે છે. તમારું લેઆઉટ સમર્થિત એકમાં બદલવું નીતિ લખવા કરતાં સસ્તું છે અને અપડેટ્સમાં ટકી રહે છે.
ત્રીજો ખરેખર ખૂટતો નિયમ છે, અને તે છેલ્લો ઉપાય હોવો જોઈએ. ઑડિટ ટૂલિંગ વડે ઉમેદવાર બનાવો, તે ખરેખર શું મંજૂરી આપે છે તે વાંચો, તમે જોયેલી ક્રિયા અને ડોમેન સુધી તેને મર્યાદિત કરો, અને ઉત્પાદનની નજીક જાય તે પહેલાં બીજા કોઈને તેની સમીક્ષા કરાવો.
જૂનું allow મોડ્યુલ જવાબ કેમ નથી
આ ખામી માટેના શોધ પરિણામો તૈયાર મોડ્યુલોથી ભરેલા છે, ઘણી વાર એવા સાધન માટે જેને હૂક હવે બોલાવતું નથી. એક ઇન્સ્ટોલ કરવાથી એવી પરવાનગીઓ મળે છે જેનો તમારા નકાર સાથે કોઈ સંબંધ ન પણ હોય, અને તે કાયમી છિદ્ર ઉમેરતા વાસ્તવિક અસંગતિને યથાવત્ રાખે છે.
તે આગલી નિષ્ફળતાને પણ છુપાવે છે. વિશાળ વર્ગની ક્રિયાઓને મંજૂરી આપતું મોડ્યુલ આ ભૂલને અદૃશ્ય કરી દેશે અને આગલીને એવી વસ્તુમાં ફેરવશે જેને આરોપી ઠેરવવી ઘણી વધુ મુશ્કેલ છે. પછી મોડ્યુલ દૂર કરવું પણ એવો ફેરફાર છે જે કોઈ આયોજિત કરવા માંગતું નથી, તેથી ટૂંકો રસ્તો કાયમી બનવાની વૃત્તિ ધરાવે છે.
શિસ્તબદ્ધ સરખામણી તમે વાંચી શકો તે નકાર અને તમે સૂચવો છો તે ફેરફાર વચ્ચેની છે. Red Hat ની SELinux સમસ્યા નિવારણ માર્ગદર્શિકા લેબલિંગ અને રૂપરેખાંકન તપાસને ઉત્પન્ન નીતિ પહેલાં મૂકે છે, તે પણ આ જ કારણસર. જો રેકોર્ડમાં અનુરૂપ નકાર ન હોય, તો SELinux સંભવતઃ તમારી સમસ્યા નથી, અને પાથ, સેન્ડબોક્સ કે પરવાનગીની સમસ્યાઓ હજુ ખુલ્લી છે.