VPN சான்றிதழை நகர்த்துவது அதன் SELinux லேபிளை ஏன் உடைக்கிறது

சான்றிதழ்கள் சரியான அடைவில் படிக்கக்கூடிய பயன்முறை மற்றும் root உரிமையுடன் இருக்கலாம், மேலும் சேவை கோப்பைத் திறக்க முடியாது என்று இன்னும் தெரிவிக்கலாம். SELinux அமைப்பில் அந்தக் கலவை அனுமதிகளை அல்ல, ஒரு குறிப்பிட்ட பொறிமுறையைச் சுட்டுகிறது. லேபிள் கோப்புடன் பயணித்தது, ஏனெனில் மறுபெயரிடல் புதிய பொருளை உருவாக்காது. inode பழைய பாதையில் இருந்த பாதுகாப்பு சூழலைத் தக்கவைத்தது, புதிய பாதையின் கொள்கைக்கு தனது சொந்த சூழலை ஒதுக்கும் வாய்ப்பு ஒருபோதும் கிடைக்கவில்லை.

மறுபெயரிடல் ஒரு லேபிளுக்கு உண்மையில் என்ன செய்கிறது

ஒரு கோப்பு தனது SELinux சூழலை inode உடன் இணைந்த பண்பு தரவாகக் கொண்டுள்ளது. ஒரே கோப்பு முறைமையில் மறுபெயரிடல் அடைவுப் பதிவை மட்டும் மாற்றுகிறது, வேறு எதையும் அல்ல, இது விரைவானது மற்றும் அணுவியல், சூழல் நகர்த்தலுக்குப் பிறகும் நீடிப்பதற்கான காரணமும் இதுவே. எந்தக் கொள்கையும் கேட்கப்படுவதில்லை, எந்த இயல்புநிலையும் பயன்படுத்தப்படுவதில்லை, எந்த எச்சரிக்கையும் அச்சிடப்படுவதில்லை.

நகலெடுத்தல் வேறு விதமாக நடந்துகொள்கிறது. ஒரு நகல் இலக்கு அடைவில் புதிய inode உருவாக்குகிறது, கொள்கை அந்த அடைவின் வகையிலிருந்து சூழலை ஒதுக்குகிறது, எனவே நகலெடுக்கப்பட்ட சான்றிதழ் பொதுவாக சரியான லேபிளைப் பெறுகிறது, நகர்த்தப்பட்டது தவறாகவே இருக்கும். அந்த ஒரே வேறுபாடு இந்த வகை டிக்கெட்டுகளில் பெரும்பாலான குழப்பத்தை விளக்குகிறது.

கோப்பு முறைமைகளுக்கு இடையேயான நகர்த்தல் நகலெடுத்தல் பொருளாதாரத்திற்குத் திரும்புகிறது, எனவே அதே கட்டளை /etc தனி தொகுதியில் உள்ளதா என்பதைப் பொறுத்து இரு இயந்திரங்களில் வேறு விதமாக நடந்துகொள்ளலாம். கருவி நம்பகமற்றது என்று முடிவெடுப்பதற்கு முன் இதைச் சரிபார்க்கவும். mount அட்டவணையில் ஒரு பார்வை நீங்கள் எந்த வகை நகர்த்தலைச் செய்தீர்கள் என்பதைச் சொல்லும்.

தற்போதைய லேபிளை எதிர்பார்க்கப்பட்டதற்கு எதிராகப் படிக்கவும்

படிக்க-மட்டும் மூன்று கட்டளைகள் எதையும் மாற்றாமல் கேள்விக்குப் பதிலளிக்கின்றன. முதலாவது கோப்பில் இப்போது என்ன இருக்கிறது என்பதைக் காட்டுகிறது, இரண்டாவது அந்தத் துல்லியமான பாதைக்கு கொள்கை என்ன எதிர்பார்க்கிறது என்பதைத் தெரிவிக்கிறது, மூன்றாவது அடைவின் கீழ் லேபிள் வேறுபடும் ஒவ்வொரு கோப்பையும் பட்டியலிடுகிறது.

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 ஐ முடக்க வேண்டாம். இரண்டு குறுக்குவழிகளும் வேலை செய்வது போல் தெரியும் அமைப்பையும் யாரும் விவரிக்க முடியாத பாதுகாப்பு நிலையையும் தருகின்றன. ஒரு சிறிய விசாரணை இரண்டையும் விட மேலானது.